Переход на новые версии технологической платформы 1С:Предприятие — это всегда ответственный шаг, который часто диктуется производственной необходимостью. Например, когда нам требуется задействовать механизм расширений конфигурации для интеграции современных систем (таких как «1С:Документооборот») со старыми прикладными решениями на обычных формах (например, «Управление производственным предприятием» или «Управление торговлей 10.3»).
Однако при использовании релиза 8.3.13.1644 многие разработчики и системные администраторы столкнулись с критической проблемой: клиентское приложение аварийно завершает работу с генерацией дампа (ошибка «Прекращена работа программы 1cv8.exe») прямо при запуске информационной базы в режиме толстого клиента. В этой статье мы подробно проанализируем причины этого сбоя, разберем сопутствующие технические проблемы данной ветки платформы и выработаем надежные сценарии решения проблемы.
ОбновитьИнтерфейс()Основным триггером падения платформы 8.3.13.1644 в толстом клиенте обычного приложения является вызов глобального метода ОбновитьИнтерфейс(). Этот метод традиционно используется в конфигурациях на обычных формах при начале работы системы, смене роли пользователя или интерактивном переключении интерфейсов.
В процессе выполнения этого метода платформа пытается перерисовать главное меню, панели инструментов и командные панели активных окон. Из-за внутренней ошибки в модуле отрисовки интерфейса (скомпилированном новым пакетом C++), обращение к структурам интерфейса вызывает нарушение прав доступа к памяти (Access Violation), и операционная система аварийно закрывает процесс 1С.
Давайте посмотрим на классический пример кода в модуле обычного приложения, который гарантированно приводил к дампу на проблемном релизе:
Процедура ПриНачалеРаботыСистемы()
// Настройка параметров сеанса и проверка прав
УстановитьПараметрыСеанса();
// Вызов, вызывающий падение в дамп на платформе 8.3.13.1644
ОбновитьИнтерфейс();
КонецПроцедуры
Если в вашей конфигурации используется подобная конструкция, то при инициализации интерфейса приложение закроется без вывода понятных пользователю диагностических сообщений.
Проанализируем сопутствующую проблему производительности и стабильности, которая тесно связана с архитектурными изменениями в платформе начиная с версии 8.3.11 и усугубившаяся в 8.3.13/8.3.14. Разработчики 1С перешли на использование нового компилятора C++ и заменили собственную реализацию кучи памяти (ранее базировавшуюся на библиотеке STLport) на системные вызовы динамической библиотеки nuke83.dll.
Это привело к следующим последствиям:
malloc начинают лавинообразно нагружать одно из ядер процессора до 99-100%, вызывая жуткие «тормоза» или зависание клиента с последующим аварийным завершением по таймауту.Помимо проблем с толстым клиентом, в данном релизе было зафиксировано еще несколько критических багов, которые делают его эксплуатацию в рабочей среде небезопасной:
DistributedMoxelImpl.cpp при попытке пользователя изменить состав полей или отборов после первичного формирования отчета._tmpRCT.---
Рассмотрим по шагам практические сценарии преодоления этой проблемы в зависимости от ваших инфраструктурных возможностей.
Если для вашей текущей работы не требуются специфические возможности более свежих платформ (такие как работа с новыми версиями расширений), наиболее надежным и проверенным решением будет использование стабильного релиза из ветки 8.3.12 (например, 8.3.12.1790 или аналогичных).
В этой ветке отсутствуют критические ошибки отрисовки обычного интерфейса, и она прекрасно оптимизирована для работы со старыми прикладными решениями (УПП, УТ 10.3) без изменения программного кода конфигурации.
Если новые возможности платформы (например, интеграция с ДО через расширения) критически важны, необходимо пропустить проблемную ветку 8.3.13 и обновиться на стабильные релизы ветки 8.3.14. Ошибка отрисовки интерфейса при вызове ОбновитьИнтерфейс() в ней была успешно устранена разработчиками 1С.
Важное примечание: При переходе на 8.3.14 обязательно убедитесь, что на серверах приложений и рабочих станциях установлены современные операционные системы (не ниже Windows Server 2012 R2 / Windows 7), чтобы избежать деградации производительности из-за нового компилятора C++.
В условиях, когда обновить платформу прямо сейчас невозможно (например, из-за ограничений на «технологическое окно» обслуживания СУБД или наличия единственного серверного ключа в распределенной сети заводов с разными часовыми поясами), можно временно изолировать проблемный вызов в коде.
Для этого необходимо проанализировать логи технологического журнала или отладчика, найти вызовы метода ОбновитьИнтерфейс() и временно закомментировать их либо обернуть в безопасный блок:
Попытка
ОбновитьИнтерфейс();
Исключение
// Запись в журнал регистрации без прерывания работы пользователя
ЗаписатьВЖурналРегистрации("Интерфейс", УровеньЖурналаРегистрации.Предупреждение, , ,
"Не удалось обновить интерфейс программно: " + ОписаниеОшибки());
КонецПопытки
Обратите внимание: данный обходной путь не гарантирует 100% стабильности, так как авто-обновление интерфейса может инициироваться самой платформой при выполнении других интерактивных действий пользователя.
Если вам требуется одновременно запускать старую УПП на стабильной платформе (например, 8.3.12) и новый «1С:Документооборот» на современной платформе (например, 8.3.15), лучшим решением будет развертывание двух независимых служб сервера 1С:Предприятие на одном физическом сервере. Они разводятся по разным сетевым портам (например, стандартные порты 1540, 1541, 1560-1591 для первой службы и 2540, 2541, 2560-2591 для второй).
Это позволит вам обеспечить максимальную стабильность для пользователей тяжелой ERP-системы без отказа от современных технологий в сопутствующих конфигурациях.