Как решить проблемы с зависанием пользователей и падением процессов при обновлении платформы 1С до версии 8.3.16?

Переход на новые версии технологической платформы 1С:Предприятие — это всегда ответственный шаг, который нередко преподносит неприятные сюрпризы системным администраторам и разработчикам. Особенно остро проблемы проявляются при обновлении крупных инфраструктурных узлов, например, при переходе с проверенной временем ветки 8.3.13 на более современные релизы семейства 8.3.16.

Типичный сценарий, с которым сталкиваются многие специалисты, выглядит следующим образом: после развертывания платформы версии 8.3.16.1063 штатно заходит работать только первый пользователь. Все последующие подключения зависают на этапе выбора информационной базы из списка или непосредственно при инициализации сеанса. При этом на сервере приложений начинает лавинообразно падать процесс dbda.exe, непрерывно генерируя аварийные дампы памяти на жесткий диск, а сессии синхронизации между базами 1С:Зарплата и Управление Персоналом (ЗУП) и 1С:Бухгалтерия Предприятия (БП) по COM-соединению завершаются аварийно.

Давайте подробно разберем природу этих неполадок, выясним их истинные технические причины и пошагово рассмотрим проверенные практикой методы их решения.

---

Причина №1: Циклический краш процесса dbda (Дата акселератор)

Начиная с версий 8.3.14 и 8.3.15, разработчики платформы внедрили встроенную СУБД в оперативной памяти — Дата акселератор (процесс dbda.exe). Эта служба предназначена для ускорения сложных аналитических расчетов в связке с системой «1С:Аналитика». По умолчанию в платформе 8.3.16 служба DataAcceleratorService активируется автоматически на уровне кластера серверов 1С.

Выясним причину, почему она начинает аварийно завершать работу:

1. Несовместимость с инструкциями процессора. Процесс dbda.exe критически требователен к аппаратному обеспечению и набору инструкций процессора. Он в обязательном порядке требует поддержки инструкций AVX (Advanced Vector Extensions). Если ваш сервер 1С развернут в виртуальной среде (VMware, Hyper-V, Proxmox) со стандартным или эмулируемым типом процессора без проброса физических инструкций хоста (Host-Passthrough), процесс dbda.exe падает с ошибкой недопустимой инструкции (invalid opcode).
2. Дефицит оперативной памяти. Дата акселератор хранит обрабатываемые данные непосредственно в ОЗУ. На серверах с небольшим объемом памяти (например, до 32 ГБ) совместный запуск СУБД, службы сервера 1С rphost и прожорливого акселератора быстро приводит к исчерпанию лимитов памяти, вызывая аварийное завершение процессов операционной системой.

Поскольку для работы стандартных конфигураций БП и ЗУП этот функционал не требуется, мы можем безопасно и полностью отключить его.

Шаг 1. Физическое отключение исполняемого файла (наиболее надежный способ)

Если нам не нужна аналитика в оперативной памяти, самый простой способ прекратить краши — предотвратить запуск самого исполняемого файла:

1. Остановим службу агента сервера 1С:Предприятие (ragent) через консоль служб Windows.
2. Перейдем в каталог установки двоичных файлов платформы. Обычно он расположен по пути: C:\Program Files\1cv8\8.3.16.1063\bin\ (или C:\Program Files (x86)\1cv8\... для 32-разрядной версии сервера).
3. Найдем файл dbda.exe и переименуем его, изменив расширение, например, в dbda.exe.bak или _dbda.exe.
4. Снова запустим службу агента сервера 1С. Менеджер кластера не сможет инициализировать акселератор, проигнорирует его запуск, и генерация аварийных дампов мгновенно прекратится.

Шаг 2. Настройка требований назначения функциональности в консоли администрирования

Для того чтобы решить проблему корректно на уровне настроек самого кластера, выполним следующие действия:

1. Откроем утилиту «Администрирование серверов 1С Предприятия».
2. Перейдем к ветке нашего центрального сервера и откроем раздел «Требования назначения функциональности».
3. Создадим новое правило со следующими параметрами:
   • Объект требования: Сервис дата-акселератора (или DataAcceleratorService).
   • Тип требования: Использовать.
   • Способ применения: Не назначать.
4. Применим изменения. Теперь кластер не будет пытаться запустить этот сервис на данном рабочем сервере.

---

Причина №2: Зависание пользователей при подключении с терминального сервера

Рассмотрим ситуацию, когда при запуске 1С через терминальный сервер (в нашем примере — 32-битный Windows Server с 16 Гб памяти) сеансы зависают, в то время как локальное подключение к первому серверу 1С работает исправно.

Проанализируем сетевую структуру взаимодействия между сервером терминалов и сервером приложений 1С. При обновлении на 8.3.16 меняются внутренние алгоритмы взаимодействия между процессами, а также требования к лицензированию:

1. Блокировка динамических портов брандмауэром. По умолчанию сервер 1С общается по портам 1540 и 1541. Однако рабочие процессы rphost динамически занимают диапазон портов от 1560 до 1591. Если между терминальным сервером и основным сервером 1С работает сетевой экран (Firewall), блокирующий этот диапазон, клиентское приложение на терминале не сможет установить стабильное соединение и зависнет на этапе инициализации интерфейса.
2. Задержки при поиске программных и аппаратных лицензий. Платформа 8.3.16 опрашивает ключи защиты более строго. Если на терминальном сервере включен многопоточный поиск HASP-ключей по всей сети, клиент зависает в бесконечных сетевых таймаутах.

Для решения этой проблемы выполним комплекс мер:

Шаг 1. Настройка сетевых правил брандмауэра

На сервере приложений 1С необходимо открыть входящие порты для терминального сервера. Убедимся, что открыт весь необходимый диапазон:

• Порт главного менеджера кластера: 1541 (TCP).
• Порт агента сервера: 1540 (TCP).
• Диапазон портов рабочих процессов: 1560-1591 (TCP).

Шаг 2. Оптимизация поиска лицензий через NetHASP.ini

Чтобы клиентские приложения на терминальном сервере не тратили время на широковещательный опрос сети в поисках аппаратного ключа, мы должны жестко ограничить адреса поиска. Отредактируем файл конфигурации лицензирования nethasp.ini, который обычно находится в каталоге C:\Program Files (x86)\1cv8\conf\ или в папке пользователя:

[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Укажите здесь точный IP-адрес сервера с HASP-ключом
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = UDP
NH_USE_BROADCAST = Disabled

Это отключит бесконечный поиск лицензий по всей локальной сети и ускорит запуск программы в несколько раз, предотвращая «застывание» стартового окна.

Шаг 3. Очистка локального кэша конфигураций

Старые версии временных файлов платформы 8.3.13 могут конфликтовать со структурами данных 8.3.16. Выполним полную очистку кэша на терминальном сервере для всех пользователей. Сделать это можно вручную, удалив содержимое каталогов:

• %userprofile%\AppData\Local\1C\1cv8\
• %userprofile%\AppData\Roaming\1C\1cv8\

---

Причина №3: Аварийное завершение рабочих процессов при COM-обмене (ЗУП - БП)

Еще одна крайне распространенная проблема релизов 8.3.15 и 8.3.16 — это нестабильная работа внешней компоненты COM-соединения. Во время выполнения фонового задания синхронизации данных (например, при передаче проводок из ЗУП в БП) происходит внезапное падение рабочего процесса rphost, после чего сеансы всех пользователей аварийно обрываются.

Выясним причину: в библиотеке comcntr.dll данных релизов платформы содержится критическая ошибка работы с памятью при многопоточном обращении. Решим эту проблему двумя основными способами.

Способ 1. Перерегистрация библиотеки COM-соединения

Зачастую в операционной системе остается зарегистрированной старая версия библиотеки comcntr.dll от предыдущей платформы 8.3.13, либо регистрация новой библиотеки выполнена некорректно. Нам необходимо принудительно перерегистрировать актуальный COM-коннектор.

Откроем командную строку от имени администратора и выполним последовательно следующие команды (для 64-битной операционной системы Windows):

C:\Windows\SySWOW64\regsvr32.exe /u "C:\Program Files\1cv8\8.3.16.1063\bin\comcntr.dll"
C:\Windows\SySWOW64\regsvr32.exe "C:\Program Files\1cv8\8.3.16.1063\bin\comcntr.dll"

Первая команда отменяет регистрацию старой библиотеки, вторая — регистрирует актуальную версию компоненты в системном реестре.

Способ 2. Изоляция COM-процессов через Службу компонентов Windows (COM+)

Для того чтобы сбои в работе библиотеки comcntr.dll не приводили к падению всего сервера 1С, мы можем изолировать выполнение COM-соединений в отдельном выделенном процессе операционной системы (dllhost.exe). Настроим это по шагам:

1. Откроем оснастку «Службы компонентов» (выполнить команду dcomcnfg).
2. Перейдем в ветку: Консоль корня -> Службы компонентов -> Компьютеры -> Мой компьютер -> Приложения COM+.
3. Нажмем правой кнопкой мыши на раздел «Приложения COM+» и выберем Создать -> Приложение.
4. В мастере создания выберем «Создать новое приложение», укажем имя (например, 1C_COM_Connector) и установим способ активации — Серверное приложение.
5. В качестве учетной записи для запуска укажем системного пользователя, от имени которого работает служба сервера 1С.
6. В созданном приложении перейдем в ветку Компоненты. Нажмем правой кнопкой мыши, выберем Создать -> Компонент.
7. Укажем «Установка новых компонентов» и выберем файл comcntr.dll из каталога установленной платформы 8.3.16.1063\bin\.

Теперь все обращения к базам данных по технологии COM будут выполняться в изолированном пространстве. Если библиотека вызовет сбой, операционная система просто перезапустит процесс dllhost.exe, а пользователи баз 1С даже не заметят краша.

Способ 3. Перевод обмена на альтернативные технологии

Фирма 1С официально рекомендует постепенно отказываться от COM-соединений в пользу более гибких и надежных механизмов обмена данными, таких как:

• Обмен данными через веб-сервисы (HTTP или SOAP).
• Использование синхронизации через формат EnterpriseData с передачей файлов через общие сетевые папки или FTP.

Это полностью избавит вашу систему от привязки к платформенным библиотекам Windows и обеспечит стабильную работу синхронизации вне зависимости от версии установленной платформы 1С.