Почему падает RPHost при синхронизации ЗУП и БП через COM-соединение и как это исправить?

← На главную

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

Анализируем симптомы и системные ошибки

Первым делом проанализируем записи в журнале событий Windows (Event Viewer). Чаще всего падение сопровождается кодом исключения 0xc0000005. Это классическая ошибка нарушения прав доступа к памяти (Access Violation). В нашем случае сбой происходит в модуле core83.dll. Давайте посмотрим, как выглядит типичное описание ошибки в журнале:


Имя сбойного приложения: rphost.exe, версия: 8.3.16.1063
Имя сбойного модуля: core83.dll, версия: 8.3.16.1063
Код исключения: 0xc0000005
Смещение ошибки: 0x0000000000207499
Путь сбойного модуля: C:\Program Files\1cv8\8.3.16.1063\bin\core83.dll

Такая ошибка говорит о том, что рабочий процесс попытался обратиться к адресу памяти, который ему не принадлежит или уже был освобожден. В контексте синхронизации это часто происходит в момент завершения COM-сессии, когда объекты 1С уничтожаются некорректно.

Изучаем данные технологического журнала

Для более глубокого понимания ситуации разберем выдержки из технологического журнала (ТЖ). Проанализируем события EXCP (исключения) и PROC (процессы). Рассмотрим фрагмент лога, описывающий момент падения:


22:09.123015-0,EXCP,1,process=ragent,OSThread=3040,ClientID=36,Exception=NetDataExchangeException,
Descr='server_addr=tcp://DB:1560 descr=10054(0x00002746): 
Удаленный хост принудительно разорвал существующее подключение. 
line=1465 file=src\DataExchangeTcpClientImpl.cpp'

Здесь мы видим ошибку 10054. Это означает, что rphost.exe аварийно завершился, и сетевое соединение с ним было разорвано операционной системой. Также обратим внимание на сообщение Рабочий процесс не найден в контексте ClusterLocksImpl.cpp. Это подтверждает, что менеджер кластера (rmngr) потерял связь с рабочим процессом, который «упал» из-за внутренней ошибки в core83.dll. Для включения сбора и автоматизированного анализа логов можно применить инструмент для сбора и разбора технологического журнала 1С.

Причина №1: Баг платформы 8.3.16.1063 (Ошибка 30171159)

Выясним основную причину. В ветке платформы 8.3.16 была официально зарегистрирована ошибка под номером 30171159. Ее суть заключается в том, что процесс фонового задания, использующий COM-соединение, аварийно завершает работу при определенных условиях взаимодействия с памятью.

Решение: Единственным надежным способом устранения этой конкретной ошибки является обновление платформы. Фикс данной проблемы был включен в релиз 8.3.16.1296 и более поздние версии. Если вы используете версию 1063, вам необходимо запланировать переход на исправленную сборку.

Причина №2: Параметры потребления памяти в кластере

Иногда падение rphost провоцируется механизмами самоконтроля кластера 1С. Рассмотрим настройки параметров «Безопасный расход памяти за один вызов» и «Предел объема памяти рабочих процессов». Если при выгрузке большого объема данных (например, при синхронизации ЗУП и БП за долгий период) процесс превышает установленный лимит, менеджер кластера может принудительно завершить его (Kill), что в системном журнале также может отразиться как ошибка модуля core83.dll. Для быстрой проверки и оценки текущих параметров сервера можно использовать обработку для чек-апа настроек кластера и рабочих процессов 1С.

Для диагностики выполним следующие действия:

Откроем консоль администрирования кластеров 1С.
Перейдем в свойства нашего центрального сервера.
Проверим значение параметра «Безопасный расход памяти за один вызов».
Попробуем временно установить его в значение 0 (без ограничений) и повторить попытку обмена.

Причина №3: Проблемы разрядности и настройки COM+

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

Разберем, как правильно настроить компоненту V83.COMConnector через службу компонентов Windows:

Запустим dcomcnfg (Службы компонентов).
Создадим новое приложение COM+ (например, с именем "1C_COM_Connector").
В ветке «Компоненты» добавим comcntr.dll из каталога bin вашей платформы.
В свойствах созданного приложения на вкладке «Удостоверение» (Identity) укажем пользователя, под которым запускается служба 1С (это критически важно для прав доступа к памяти и временным файлам).
На вкладке «Библиотека» установим переключатель в положение «Приложение сервера» (Server application), чтобы COM-объект запускался в отдельном процессе dllhost.exe, а не внутри rphost.exe. Это изолирует ошибки COM от основного рабочего процесса.

Альтернативный подход: Переход на Enterprise Data

Проанализируем архитектуру обмена. Технология COM-соединения считается устаревшей и довольно нестабильной в сложных доменных инфраструктурах. Если ошибки в core83.dll продолжаются даже после обновления платформы, рассмотрим переход на современный механизм обмена — Enterprise Data через Web-сервисы или файловый обмен.

Преимущества этого метода:

Изоляция: Обмен происходит через HTTP/HTTPS, что исключает прямую загрузку библиотек 1С в память другого процесса.
Стабильность: Падение одного сеанса Web-сервиса не приводит к краху всего рабочего процесса rphost.
Прозрачность: Ошибки в формате XML/JSON гораздо проще диагностировать, чем дампы памяти 0xc0000005.