Как диагностировать и исправить ошибку «Аварийно завершился рабочий процесс» при синхронизации БП 3.0 и ЗУП 3.1

← На главную

Синхронизация данных между конфигурациями 1С:Бухгалтерия предприятия 3.0 и 1С:Зарплата и управление персоналом 3.1 — это стандартная, но технически сложная процедура. Ошибка «Аварийно завершился рабочий процесс фонового задания» является одной из самых труднодиагностируемых, так как она указывает не на логическую ошибку в коде, а на критический сбой процесса rphost.exe. Давайте вместе разберем причины этой проблемы и пошагово пройдем по методам ее решения.

Метод 1: Настройка COM+ приложения для 64-битных систем

Одной из наиболее частых причин «падения» рабочего процесса на 64-битных серверах является некорректная работа компоненты comcntr.dll. Даже если вы зарегистрировали библиотеку через regsvr32, этого может быть недостаточно для стабильной работы под нагрузкой. Рассмотрим, как вынести работу COM-соединения в отдельный системный процесс.

Проанализируем последовательность действий в оснастке «Службы компонентов» (Component Services):

Откроем Панель управления — Администрирование — Службы компонентов.
Перейдем в ветку Компьютеры — Мой компьютер — Приложения COM+.
Создадим новое приложение (правой кнопкой — Создать — Приложение). В мастере выберем «Создать новое приложение», укажем имя (например, 1C_COM_Connector) и выберем тип «Серверное приложение».
На вкладке Удостоверение (Identity) крайне важно указать данные конкретного пользователя. Рекомендуем использовать ту же учетную запись, под которой запущена служба Агент сервера 1С:Предприятия (обычно это USR1CV8). Это исключит конфликты прав доступа.
В созданном приложении перейдем в папку Компоненты и добавим новую компоненту V83.COMConnector. Нам нужно выбрать «Установка новых компонентов» и указать путь к файлу comcntr.dll, который находится в папке установленной платформы (например, C:\Program Files\1cv8\8.3.16.1063\bin\comcntr.dll).

После этой настройки COM-соединение будет создаваться в отдельном процессе dllhost.exe. Если произойдет сбой, он не «уронит» основной рабочий процесс 1С rphost.exe, и мы сможем увидеть более детальную ошибку в системном журнале Windows.

Метод 2: Переход на синхронизацию через Web-сервисы

Как отмечают многие специалисты, использование COM-технологии постепенно уходит в прошлое. Более современным и стабильным способом является обмен через Web-сервисы. Этот метод не требует регистрации библиотек и настройки прав на реестр.

Рассмотрим, как настроить такой обмен без доработки конфигурации:

Выберем одну из баз (например, БП 3.0) и опубликуем её на веб-сервере (IIS или Apache). Нам необходимо убедиться, что при публикации установлена галочка для стандартного интерфейса EnterpriseData.
В базе ЗУП 3.1 при настройке синхронизации выберем вариант подключения «Через веб-сервис».
Укажем адрес опубликованной базы, имя пользователя и пароль.

Преимущество этого метода в том, что обмен происходит по протоколу HTTP/HTTPS, что гораздо надежнее в условиях клиент-серверной архитектуры. Web-сервисы позволяют избежать проблем с разрядностью систем и специфическими настройками Windows Server.

Метод 3: Использование Технологического журнала для глубокой диагностики

Если стандартный Журнал регистрации пишет лишь общую фразу об аварийном завершении, нам необходимо заглянуть «под капот» системы с помощью Технологического журнала (ТЖ). Это позволит выяснить, на каком именно объекте или программном событии происходит крах.

Для сбора логов создадим в папке conf (на сервере 1С) файл logcfg.xml со следующим содержимым:


<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\LOGS\SYNC_ERROR" history="2">
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="PROC"/>
    </event>
    <property name="all"/>
  </log>
</config>

Разберем, что мы здесь настроили. Мы собираем события EXCP (исключения) и PROC (процессы). После запуска синхронизации и возникновения ошибки, проанализируем файлы в папке C:\LOGS\SYNC_ERROR. Ищите строки, содержащие описание критических ошибок доступа к памяти или нарушения прав. Часто там можно увидеть конкретный метод модуля, на котором всё ломается.

Метод 4: Проверка прав и очистка временных файлов

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

Очистим папку Temp для пользователя USR1CV8. Путь обычно выглядит так: C:\Users\USR1CV8\AppData\Local\Temp. Скопление тысяч мелких файлов может приводить к сбоям при создании временных файлов выгрузки.
Убедимся, что у пользователя USR1CV8 есть полные права на папку с установленной платформой и на каталоги, куда может производиться выгрузка (если используются промежуточные файлы).
Проверим настройки DEP (Data Execution Prevention). В некоторых случаях система безопасности Windows блокирует выполнение кода COM-объекта внутри процесса 1С. Попробуем добавить rphost.exe в список исключений DEP.

Метод 5: Тестирование через файловый обмен

Чтобы понять, виноваты ли настройки сервера или сами данные/правила обмена, выполним простой тест — попробуем сделать выгрузку через файл. Посмотрим на ситуацию поэтапно:

В настройках синхронизации временно сменим способ подключения на «Синхронизация через файл».
Выполним выгрузку из ЗУП 3.1. Если выгрузка в файл прошла успешно, значит проблема 100% в COM-соединении или правах доступа к памяти процесса.
Если же и выгрузка в файл завершается «аварийно», значит проблема в данных или правилах обмена. В этом случае проверьте, не используются ли в настройках «правила из файла». После обновления конфигурации старые правила могут стать невалидными. Рекомендуем всегда использовать «типовые правила из конфигурации».

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