В крупных и средних инфраструктурах 1С часто возникает ситуация, когда на рабочих местах пользователей установлены разные версии платформы 1С:Предприятие 8.3. Например, одна база («1С:Управление торговлей») работает на сервере под управлением релиза 8.3.12.1616 и больше не планирует обновляться, а вторая («1С:Бухгалтерия предприятия») функционирует на сервере с релизом 8.3.13.1644 и регулярно получает обновления. При этом на компьютерах пользователей установлены оба клиента.
В идеальном мире штатный загрузчик 1cestart.exe должен автоматически определять версию сервера и запускать нужного клиента. Однако на практике администраторы сталкиваются с тем, что система игнорирует прописанные настройки версии в файле ibases.v8i (параметры Version или DefaultVersion) и упорно пытается запустить базу под последней установленной версией платформы. Это приводит к ошибкам несовместимости версий клиента и сервера.
В этой статье мы подробно разберем, как устроен механизм автоопределения версий в 1С, выясним неочевидные причины сбоев (включая влияние сетевого стека операционной системы) и дадим пошаговую инструкцию по настройке стабильной работы разных версий платформ.
Для того чтобы эффективно диагностировать проблемы запуска, проанализируем алгоритм работы программы 1cestart.exe при выборе базы из списка. Когда пользователь запускает ярлык 1С, управление передается общему стартеру, который считывает параметры подключения к выбранной информационной базе.
Если база является клиент-серверной (в строке соединения указаны параметры Srvr и Ref), стартер действует по следующему строгому алгоритму:
1cv8c.exe или 1cv8.exe), стартер выполняет быстрый сетевой запрос к менеджеру кластера 1С (по умолчанию используются порты 1540 и 1541) того сервера, который прописан в настройках базы.8.3.12.1616).C:\Program Files\1cv8\ или C:\Program Files (x86)\1cv8\). Если нужная версия найдена, запускается исполняемый файл именно из этой папки.8.3.13.1644). Соответственно, клиент запускается под этой версией, пытается подключиться к серверу 8.3.12.1616 напрямую и выдает пользователю критическую ошибку о несовпадении версий клиента и сервера.Рассмотрим ситуацию, когда администратор вручную пытается прописать параметры запуска в файле списка баз ibases.v8i, указывая строки вида Version=8.3.12.1616 или DefaultVersion=8.3.12.1616, но система все равно запускает последнюю версию платформы. Выясним основные причины такого поведения:
%ProgramData%\1C\1CEStart\1CEStart.cfg, затем пользовательский файл %APPDATA%\1C\1CEStart\1CEStart.cfg, и только в самую последнюю очередь — параметры конкретной базы в файле ibases.v8i. Если в одном из глобальных файлов 1CEStart.cfg жестко прописан параметр DefaultVersion, он переопределит индивидуальные настройки базы.8.3.12 была 32-битной, а новую версию 8.3.13 установили как 64-битную), стартер при анализе параметра DefaultVersion без явного указания разрядности может проигнорировать младшую версию платформы. Программа отдает безусловный приоритет более новой 64-битной архитектуре.1cv8s.exe или 1cv8.exe внутри папки конкретного релиза (например, из каталога bin версии 8.3.13), то программа запуска вообще не будет обращаться к файлу баз ibases.v8i для фильтрации версий. Она принудительно запустит именно ту версию, исполняемый файл которой был вызван.Проанализируем крайне интересный случай из практики администраторов: почему сбои на одном физическом сервере (где установлена версия 8.3.13) мешают клиентам корректно определять версию и подключаться к совершенно другому физическому серверу (где крутится версия 8.3.12).
С точки зрения работы сетевого стека операционной системы Windows Server и протоколов TCP/IP, физическая перезагрузка сервера решает несколько критических проблем, которые напрямую влияли на процесс согласования версий (Handshake):
ragent.exe и rmngr.exe) активно используют пул динамических портов (по умолчанию диапазон от 1560 до 1591). При некорректном завершении сеансов пользователей или микросбоях сети порты могут зависать в состоянии TIME_WAIT или CLOSE_WAIT на уровне ОС. Когда лимит сокетов исчерпан, новые сетевые запросы от стартеров клиентов отбрасываются или уходят по таймауту. В результате клиентский стартер не получает ответа от сервера и активирует резервный сценарий запуска старшей версии. Перезагрузка сервера полностью очищает таблицы сетевых сокетов.8.3.12 ошибочно перенаправляются или блокируются на уровне коммутаторов. Физическая перезагрузка сбрасывает сетевые таблицы маршрутизации и принудительно обновляет ARP-таблицы на сетевом оборудовании.Разберем практические шаги, которые позволят раз и навсегда решить проблемы с запуском разных версий платформ 1С на одном компьютере.
Шаг 1. Настройка параметров базы в файле списка баз (ibases.v8i)
Для того чтобы принудительно заставить стартер запускать конкретную версию платформы для конкретной базы, откройте файл ibases.v8i (он обычно располагается в папке %APPDATA%\1C\1CEStart\) текстовым редактором и найдите нужную базу. Нам необходимо явно указать полный релиз платформы.
Рассмотрим пример правильной конфигурации файла для базы, которая должна работать строго на версии 8.3.12.1616:
[Торговля]
Connect=Srvr="server12";Ref="trade";
ID=12345678-1234-1234-1234-1234567890ab
OrderInList=1
Folder=/
OrderInFolder=1
Version=8.3.12.1616
DefaultVersion=8.3.12.1616
App=Auto
AppArch=32
Обратите внимание на параметр AppArch=32. Он явно указывает стартеру использовать 32-разрядное клиентское приложение. Это исключает ситуации, когда стартер пытается запустить 64-битного клиента более новой версии в обход указанного релиза.
Шаг 2. Проверка конфигурационных файлов 1CEStart.cfg
Убедимся, что глобальные настройки не переопределяют наши параметры. Проанализируем содержимое файлов 1CEStart.cfg в папках %ProgramData%\1C\1CEStart\ и %APPDATA%\1C\1CEStart\. Откройте их и проверьте наличие параметров DefaultVersion. Если там жестко прописана конкретная версия, например DefaultVersion=8.3.13.1644, удалите эту строку или закомментируйте её символом двойного слэша.
Пример корректного содержимого файла 1CEStart.cfg:
InstalledLocation=C:\Program Files\1cv8
InstalledLocation=C:\Program Files (x86)\1cv8
UseAppHighterVersion=RunMethod
Параметр UseAppHighterVersion=RunMethod управляет тем, как запускается приложение. Значение RunMethod указывает использовать метод запуска, согласованный с сервером.
Шаг 3. Очистка локального кэша и сброс сетевых параметров
Если после настройки файлов конфигурации система продолжает вести себя некорректно, выполним очистку кэша стартера и сброс сетевого стека на клиентском компьютере. Разберем этот процесс по шагам:
%APPDATA%\1C\1CEStart\ и удалите все временные файлы, кроме файла списка баз ibases.v8i (его предварительно рекомендуется скопировать в безопасное место).
ipconfig /flushdns
netsh winsock reset
Шаг 4. Настройка сетевых параметров службы сервера 1С
Для предотвращения зависания сетевых портов на серверах 1С рекомендуется оптимизировать параметры реестра Windows, отвечающие за освобождение портов TCP. Откройте редактор реестра regedit на сервере 1С и перейдите по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Создайте или измените следующие параметры типа DWORD (32 бита):
TcpTimedWaitDelay со значением 30 (это уменьшит время ожидания закрытия портов в состоянии TIME_WAIT с дефолтных 240 секунд до 30 секунд).MaxUserPort со значением 65534 в десятичной системе (это расширит диапазон динамических портов, доступных для подключений).После внесения этих изменений в реестр необходимо перезагрузить физический сервер для их применения.
Применяя данные рекомендации и понимая логику работы сетевого взаимодействия стартера 1С с серверами приложений, вы сможете обеспечить стабильную и предсказуемую работу пользователей в мультиплатформенной среде без необходимости создания неудобных ручных ярлыков под каждую базу.