Приветствуем вас, коллеги! Процесс обновления крупных типовых конфигураций «1С:Предприятие», таких как «Управление торговлей», редакция 11, часто преподносит неприятные сюрпризы. Одним из наиболее коварных сбоев является внезапное аварийное завершение рабочего процесса фонового задания при выполнении обработчиков обновления. Особенно часто это происходит на этапе работы обработчика РегистрыСведений.ПоставляемыеМакетыПечати.ОбновитьКонтрольнуюСуммуМакетов.
В этой статье мы подробно разберем, почему падает рабочий процесс сервера rphost, как это связано с расширениями конфигурации, какими инструментами локализовать проблему и как успешно завершить обновление базы данных.
Давайте рассмотрим типичный сценарий. Вы запускаете обновление конфигурации «Управление торговлей» с релиза 11.4.7.150 на 11.4.8.73 (или аналогичные версии в рамках редакции 11.4) на платформе «1С:Предприятие 8.3» (например, 8.3.17.1549). База работает в клиент-серверном варианте. В процессе отработки отложенных обработчиков обновления система выдает критическую ошибку: «Аварийно завершился рабочий процесс фонового задания».
При этом вы можете столкнуться со следующими странностями:
Выясним истинные причины такого поведения платформы. Как показывает практика, корень проблемы кроется вовсе не в самой типовой конфигурации УТ, а во взаимодействии платформы с установленными в базе расширениями конфигурации.
При переходе на новые версии платформы (в частности, в диапазоне версий от 8.3.15 до 8.3.17) существенно меняются внутренние механизмы работы с расширениями. Если в вашей базе установлены старые или неадаптированные расширения, в их модулях могут содержаться синтаксические ошибки или несоответствия сигнатур методов (например, при использовании аннотаций &Вместо, &Перед, &После).
На указанных версиях платформ существовал неприятный баг: если при компиляции фонового задания сервер сталкивался с ошибкой в модуле расширения, он не выводил диагностическое сообщение в Журнал регистрации, а мгновенно завершал работу процесса rphost по дампу памяти (unhandled exception). Из-за этого транзакция прерывалась до записи логов, оставляя администратора базы данных в полном неведении.
Как решить эту проблему:
Вторая и самая интересная причина связана непосредственно с работой обработчика РегистрыСведений.ПоставляемыеМакетыПечати.ОбновитьКонтрольнуюСуммуМакетов. Этот обработчик обходит все макеты печатных форм в системе, включая макеты, добавленные через расширения.
Для каждого макета расширения платформа формирует внутреннее системное имя по следующему шаблону:
Конфигурация <ИмяРасширения>: <ИмяМакета>
Намер, если у вас есть расширение с именем ДоработкиУТ и макетом ПланРабот, платформа сформирует строку: Конфигурация ДоработкиУТ: ПланРабот.
В процессе расчета контрольной суммы Библиотека стандартных подсистем (БСП) пытается временно выгрузить двоичные данные этого макета на диск сервера для последующего анализа. При создании временного файла платформа использует сгенерированное системное имя макета.
Проанализируем эту ситуацию с точки зрения операционной системы Windows. Символ двоеточия (:) в Windows является строго зарезервированным спецсимволом (используется для разделения дисков и путей или альтернативных потоков NTFS). Создать файл, содержащий двоеточие в имени, в Windows физически невозможно. Когда платформа 1С пытается передать операционной системе команду на запись временного файла с некорректным именем, происходит системный сбой на уровне C++ кода платформы, что мгновенно «роняет» рабочий процесс сервера без записи в Журнал регистрации.
Как решить проблему с именами макетов:
Посмотрим, как можно локализовать и устранить этот конфликт:
В процессе поиска решения разработчики часто пытаются обойти проблему программным путем, создавая собственные расширения-«заплатки» для перехвата транзакций в регистре ПоставляемыеМакетыПечати. Давайте посмотрим на пример такого кода, который, однако, не решает корневую проблему падения процесса, но хорошо иллюстрирует логику работы обработчика:
// Данный код иллюстрирует попытку безопасной записи в регистр сведений
Попытка
БлокировкаДанных = Новый БлокировкаДанных;
ЭлементБлокировки = БлокировкаДанных.Добавить("РегистрСведений.ПоставляемыеМакетыПечати");
МенеджерЗаписи = РегистрыСведений.ПоставляемыеМакетыПечати.СоздатьМенеджерЗаписи();
МенеджерЗаписи.ИмяМакета = Макет.Имя;
МенеджерЗаписи.Объект = ИдентификаторОбъектаМетаданныхВладельца;
МенеджерЗаписи.Прочитать();
Если Не МенеджерЗаписи.Выбран() Тогда
МенеджерЗаписи.ИмяМакета = Макет.Имя;
МенеджерЗаписи.Объект = ИдентификаторОбъектаМетаданныхВладельца;
КонецЕсли;
Если МенеджерЗаписи.ВерсияМакета <> ВерсияМакета Тогда
МенеджерЗаписи.ВерсияМакета = ВерсияМакета;
МенеджерЗаписи.ПредыдущаяКонтрольнаяСумма = МенеджерЗаписи.КонтрольнаяСумма;
МенеджерЗаписи.КонтрольнаяСумма = КонтрольнаяСумма;
МенеджерЗаписи.Записать();
КонецЕсли;
Исключение
// Попытка зафиксировать ошибку без падения rphost
ЗаписьЖурналаРегистрации("ОбновлениеМакетов", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;
Почему подобные программные обходы в коде 1С не помогают? Потому что падение происходит не на уровне встроенного языка 1С (где его можно было бы перехватить конструкцией Попытка...Исключение), а на более низком уровне платформы при обращении к файловой системе ОС Windows. Единственным надежным решением является полное устранение некорректных символов в метаданных или временное отключение расширения на период обновления.
Чтобы избежать подобных аварийных ситуаций при будущих обновлениях УТ 11, ERP или Комплексной автоматизации, рекомендуем придерживаться следующих правил:
9000000000 байт вместо 0), что поможет серверу корректно обрабатывать тяжелые фоновые транзакции без аварийного перезапуска рабочих процессов.Применяя эти методы, вы сможете быстро локализовать любые нестандартные ошибки обновления и обеспечить стабильную работу вашей системы «1С:Предприятие».