При администрировании и разработке в среде «1С:Предприятие» технические специалисты нередко сталкиваются с ситуациями, когда стандартные, годами отработанные операции внезапно начинают давать системные сбои. Одной из таких крайне неприятных проблем является аварийное завершение рабочего процесса сервера (rphost) или аварийное закрытие клиентского приложения при попытке выполнить тривиальное удаление помеченных объектов. Особенно остро эта проблема проявила себя на платформе версий 8.3.12.1469 и 8.3.12.1529 в клиент-серверных базах под управлением СУБД MS SQL Server, а также в файловых вариантах работы.
В этой статье мы подробно разберем, почему возникает ошибка «Аварийно завершился рабочий процесс фонового задания», проанализируем внутренние механизмы платформы, приводящие к этому сбою, и рассмотрим пошаговые практические методы ее обхода и полного устранения.
Давайте проанализируем типичную ситуацию, с которой сталкивается администратор базы данных или разработчик при возникновении этой ошибки:
ЖР) не фиксирует никаких подробных технических деталей сбоя и «молчит как рыба», поскольку рабочий процесс rphost завершается операционной системой аварийно до того, как успевает записать лог.1cv8.exe).Рассмотрим подробнее техническую подоплеку этого явления, чтобы понять, какие именно механизмы внутри платформы вызывают столь разрушительное поведение.
Для того чтобы понять природу ошибки, нам необходимо заглянуть под капот механизма взаимодействия платформы 1С с СУБД при использовании расширений конфигурации. Начиная с версии платформы 8.3.12, разработчики фирмы «1С» активно внедряли новые возможности расширения метаданных. Появилась возможность заимствовать сложные объекты, изменять их структуру и добавлять новые реквизиты в таблицы базы данных.
Однако в релизах 8.3.12.1469 и 8.3.12.1529 была допущена критическая ошибка в ядре платформы, связанная с динамическим анализом метаданных. При запуске процедуры удаления помеченных объектов система выполняет колоссальный объем работы: фоновое задание опрашивает абсолютно все таблицы базы данных на предмет наличия ссылок на удаляемые элементы. Это необходимо для обеспечения ссылочной целостности.
Если в активном расширении конфигурации содержатся заимствованные сложные объекты метаданных, такие как:
То в этот момент фоновое задание не может корректно сопоставить физическую структуру таблиц СУБД (MS SQL, PostgreSQL и др.) с логической структурой метаданных, которая была модифицирована расширением. Происходит обращение к неинициализированным или несуществующим адресам в оперативной памяти процесса (так называемый Null Pointer Dereference или Segmentation Fault). Операционная система мгновенно принудительно завершает процесс rphost (на сервере) или 1cv8.exe (на клиенте) для предотвращения порчи данных.
Именно поэтому блокировка регламентных заданий в консоли администрирования кластера серверов 1С не дает никакого эффекта — ведь падает само фоновое задание, запущенное пользователем для удаления объектов, а не сторонние фоновые процессы.
Существует несколько способов преодоления этой критической ошибки: от оперативных обходных путей («костылей») до фундаментального исправления на уровне инфраструктуры. Рассмотрим каждый из них.
Если вам необходимо срочно выполнить удаление помеченных объектов в работающей базе, а времени на обновление платформы прямо сейчас нет, воспользуемся проверенным практическим методом:
.dt) или сделайте бэкап средствами СУБД MS SQL. Это обязательный шаг!В некоторых случаях после удаления расширения платформа продолжает хранить «фантомные» связи в оперативной памяти сервера из-за агрессивного кэширования метаданных. Если даже после удаления расширения сбой повторяется, выполним очистку кэша по следующему алгоритму:
services.msc).C:\Program Files\1cv8\srvinfo\reg_1541).snccntry.Local\Temp в папке пользователя USR1CV8).Описанная проблема является зарегистрированной и признанной ошибкой платформы 1С. Использование временных обходных путей с удалением расширений — это мера, пригодная лишь для разового применения. Для обеспечения стабильной и безопасной работы системы необходимо обновить платформу.
Чтобы минимизировать риски возникновения подобных аппаратных сбоев и ошибок СУБД в будущем, рекомендуем придерживаться золотых правил разработки с использованием расширений:
РегистрыБухгалтерии, РегистрыРасчета и таблицы движений. Обращение к ним из расширения создает колоссальную нагрузку на SQL-сервер и увеличивает вероятность конфликта блокировок.Таким образом, мы выяснили природу сбоя платформы 8.3.12 при удалении помеченных объектов, пошагово разобрали экспресс-метод восстановления работоспособности базы данных и определили стратегию предотвращения подобных ошибок в будущем.