Почему после обновления платформы 1С до версии 8.3.15 пропадает обмен и аварийно завершается рабочий процесс?

Переход с проверенной временем платформы 8.3.13.1513 на более свежую 8.3.15.1830 (и выше) часто сопровождается неприятным сюрпризом: настроенные обмены между конфигурациями «Бухгалтерия предприятия» (БП) и «Управление торговлей» (УТ) перестают работать. В журнале регистрации при этом фиксируется критическая ошибка: «Аварийно завершился рабочий процесс фонового задания». Рассмотрим подробно, почему это происходит и как восстановить работоспособность системы, не возвращаясь на старую платформу.

Разберем основную причину: лицензионные ограничения и количество rphost

Проанализируем изменения, которые произошли в ядре платформы, начиная с версии 8.3.15. Ранее, на платформе 8.3.13, администраторы могли гибко настраивать параметры рабочего сервера 1С:Предприятие, распределяя нагрузку между несколькими рабочими процессами rphost. Даже при использовании лицензии уровня ПРОФ можно было создать, например, 4 или 8 процессов, что позволяло системе стабильно работать на 32-битных серверах, распределяя потребление памяти.

Однако в версии 8.3.15 компания «1С» ужесточила контроль. Теперь при использовании лицензии уровня ПРОФ сервер позволяет запускать только один рабочий процесс на один компьютер (кластер). Все сеансы пользователей, фоновые задания и COM-соединения теперь «свалены в одну кучу» внутри одного единственного rphost. Выясним, почему это критично для 32-битных систем:

• Лимит адресного пространства: 32-битный процесс в операционной системе Windows может адресовать не более 2–3 Гб оперативной памяти.
• Фрагментация памяти: Когда один процесс обслуживает и пользователей, и тяжелую выгрузку данных, память фрагментируется. При попытке обмена система запрашивает непрерывный блок памяти для формирования XML-пакета, не находит его и процесс «падает».
• Концентрация нагрузки: Если раньше обмен выполнялся в отдельном процессе, то теперь он конкурирует за ресурсы с активными пользователями внутри одного процесса.

Проанализируем работу COM-соединения и регистрацию компонентов

Обмен через прямое подключение использует библиотеку comcntr.dll (V83.COMConnector). При установке новой платформы система не всегда корректно перерегистрирует этот компонент в реестре Windows. Проверим правильность регистрации. Если в системе остались следы от версии 8.3.13, а сервер пытается вызвать компоненту от 8.3.15, возникнет конфликт версий.

Для исправления этой ситуации выполним принудительную регистрацию библиотеки. Рассмотрим пошаговый алгоритм действий в командной строке от имени администратора:

cd "C:\Program Files (x86)\1cv8\8.3.15.1830\bin"
regsvr32 comcntr.dll

Если вы используете 64-битную операционную систему, но сервер 1С у вас 32-битный, рекомендуется также проверить настройки в Службах компонентов (DCOM). Иногда требуется вынести COM-соединитель в отдельное приложение COM+, чтобы он работал в собственном процессе dllhost.exe, не нагружая основной рабочий процесс 1С.

Очистка кэша и профилактика сервера

Часто после обновления платформы в кэше сервера и пользователей остаются «хвосты» метаданных старой версии, которые мешают корректному выполнению фоновых заданий обмена. Разберем, как правильно провести очистку, не удалив лишнего. Посмотрим на список папок, которые необходимо очистить на сервере:

1. Остановим службу 1C:Enterprise 8.3 Server Agent.
2. Перейдем в каталог данных сервера (обычно это C:\Program Files\1cv8\srvinfo или C:\Program Data\1cv8).
3. Найдем папки с именами вида snccntx... (кэш сеансовых данных) и reg_1541.
4. Внутри папок информационных баз удалим содержимое папки ConfigSave, если она присутствует и обмен завис на этапе обновления метаданных.
5. Важно: Не удаляйте файлы журналов регистрации (.lgp или .lgf), если они вам дороги.

Оптимизация параметров рабочего сервера

Посмотрим на настройки в консоли администрирования серверов 1С. Поскольку на платформе 8.3.15 (ПРОФ) мы ограничены одним рабочим процессом, нам нужно настроить его так, чтобы он не «умирал» при малейшем скачке нагрузки. Проанализируем следующие параметры сервера:

• Безопасный расход памяти за один вызов: Если здесь стоит небольшое значение (например, 500 Мб), то тяжелая выгрузка из Бухгалтерии будет прерываться менеджером кластера. Попробуем установить значение 0 (без ограничений) для тестирования.
• Критический объем памяти процессов: Для 32-битного сервера это значение не должно превышать 2000000 (около 2 Гб), иначе ОС сама принудительно завершит процесс.
• Период выключения: Установим разумный интервал, чтобы «протухшие» и зависшие COM-соединения вовремя закрывались и высвобождали память.

Переход на 64-битную платформу как радикальное решение

Если вышеуказанные меры помогают лишь временно, и обмен продолжает падать с ошибкой «Аварийное завершение», необходимо признать: современная конфигурация «Бухгалтерия предприятия 3.0» на платформе версии 8.3.15 и выше физически не может стабильно работать в рамках 32-битного процесса. Выясним преимущества перехода на 64-битный сервер 1С:

1. Снятие ограничений по памяти: Один рабочий процесс сможет использовать всю доступную оперативную память сервера (в вашем случае — все 8 Гб), что исключит падения при формировании больших пакетов данных.
2. Стабильность фоновых заданий: Даже если вы останетесь на лицензии ПРОФ с одним рабочим процессом, его «живучесть» вырастет в разы.
3. Совместимость: Современные релизы конфигураций разрабатываются и тестируются преимущественно на 64-битных средах.

Подведем итог: Обновление платформы до 8.3.15 — это не просто смена цифр, а изменение логики работы сервера. Если вы столкнулись с падением обмена, в первую очередь проверьте количество рабочих процессов. Если он стал один — вы стали заложником ограничений лицензии ПРОФ и 32-битной архитектуры. Рекомендуется либо оптимизировать объемы передаваемых данных, либо (что более правильно) осуществить переход на 64-битный сервер 1С:Предприятия.