При переходе с конфигурации 1С:ERP Управление предприятием версии 2.4 на 2.5 многие специалисты сталкиваются с критической ошибкой: «Аварийно завершился рабочий процесс фонового задания». Эта проблема особенно неприятна тем, что она прерывает процесс обновления информационной базы на этапе регистрации данных, когда база уже находится в монопольном режиме, а стандартные средства отладки не всегда дают прямой ответ. Рассмотрим подробно, почему это происходит и как довести обновление до конца.
Ошибка, указанная в стеке вызовов ОбщийМодуль.ДлительныеОперации.Модуль(672), чаще всего сигнализирует о том, что рабочий процесс сервера 1С (rphost.exe), в котором выполнялось фоновое задание по обновлению, был принудительно завершен операционной системой или самим кластером 1С. Разберем основные причины такого поведения:
Прежде чем переходить к радикальным техническим мерам, попробуем использовать штатный механизм довыполнения процедур обновления. Если фоновое задание «вылетело», система может позволить перезапустить его из специальной формы.
Рассмотрим порядок действий:
Если этот метод не помогает и процесс снова завершается аварийно, переходим к следующему шагу.
Иногда фоновые задания блокируются из-за конфликтов сеансов. В этом случае эффективно запустить обновление напрямую из конфигуратора с использованием специального ключа. Это заставляет систему запустить обработчики в текущем сеансе, что упрощает диагностику.
Проанализируем алгоритм запуска:
/C ЗапуститьОбновлениеИнформационнойБазы
После этого запустим отладку или просто режим «Предприятие» из конфигуратора (F5 или Ctrl+F5). Система начнет выполнение процедур обновления в приоритетном режиме. Если ошибка повторится, мы сможем увидеть более детальное сообщение в Журнале регистрации.
Если мы выяснили, что причиной падения является нехватка ресурсов, нам необходимо временно «расслабить» ограничения сервера 1С. Проанализируем настройки в консоли администрирования кластера:
0 (без ограничений) или значительно увеличить его (например, до 80-90% физической памяти сервера).1. Это заставит систему создавать под каждое тяжелое задание отдельный процесс rphost, что предотвратит влияние утечек памяти в одном задании на другие сеансы.Важно: После успешного завершения обновления не забудьте вернуть эти параметры в исходное состояние, оптимальное для повседневной работы.
При глобальном переходе с версии 2.4 на 2.5 структура метаданных меняется кардинально. Старый скомпилированный код в серверном кеше может конфликтовать с новыми модулями, вызывая падение rphost. Обычная очистка клиентского кеша здесь не поможет.
Разберем процедуру полной очистки кеша на сервере:
C:\Program Files\1cv8\srvinfo).reg_1541).snacc и configsave. Также можно удалить временные файлы в корне srvinfo.Если никакие настройки не помогают, нам придется посмотреть «под капот» процесса. Для этого нужно настроить сбор Технологического журнала, чтобы поймать событие PROC или EXCP в момент падения процесса.
Создадим файл logcfg.xml в папке conf сервера 1С со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
<log location="C:\LOGS\v8" history="2">
<event>
<eq property="Name" value="PROC"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем лог после очередного падения. Ищите записи, предшествующие завершению процесса. Часто там можно обнаружить конкретный объект или таблицу базы данных, на которой происходит сбой. Например, если падение происходит при обращении к РегистрНакопления.ВыручкаИСебестоимостьПродаж, стоит выполнить Тестирование и исправление именно для этого объекта.
Рассмотрим еще несколько важных моментов, которые помогают решить проблему:
.ldf файлы). При обновлении ERP они могут вырастать в несколько раз.EXCEPTION_ACCESS_VIOLATION и падению процесса.Подведем итог: обновление ERP — это ресурсоемкая операция. Большинство ошибок «Аварийного завершения» лечатся увеличением лимитов памяти на сервере, использованием ключа /C ЗапуститьОбновлениеИнформационнойБазы и своевременной очисткой серверного кеша.