В практике системного администрирования и сопровождения 1С часто встречаются загадочные ситуации, когда клиентское приложение завершает работу без видимых причин в одно и то же время. Рассмотрим сложный кейс: 1С:Предприятие 8.3 (версия 13.1513) на конфигурации УТ 10.3 регулярно закрывается ровно в 17:08. При этом у большинства пользователей работа стабильна, а проблема локализована на конкретном рабочем месте. Разберем по шагам, как продиагностировать такую проблему и какие инструменты помогут найти истинную причину.
Первым делом проанализируем системные журналы. В журнале Application при аварийном завершении 1С обычно фиксируется событие с EventID 1000. В нашем случае данные события выглядят следующим образом:
Имя сбойного приложения: 1cv8.exe
Версия приложения: 8.3.13.1513
Имя сбойного модуля: basic.dll
Код исключения: c0000005
Разберем, что это означает. Ошибка c0000005 (Access Violation) свидетельствует о нарушении прав доступа к памяти. Приложение попыталось обратиться к адресу памяти, который ему не принадлежит или уже был освобожден. Сбой в basic.dll — это критическая ошибка базовой библиотеки платформы, которая часто возникает при потере связи с сервером или некорректном завершении сетевого контекста. Тот факт, что это происходит «по расписанию», сразу отсекает случайные факторы и заставляет нас искать скрытые планировщики задач.
Поскольку стандартные журналы Windows не дают понимания, что именно делала программа в момент падения, нам необходимо настроить Технологический журнал. Это мощный инструмент отладки, который фиксирует внутренние события платформы 1С. Для поиска причин падения (дампов) создадим файл logcfg.xml в каталоге C:\Program Files\1cv8\conf\ со следующим содержимым:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<dump location="C:\Dumps" create="true" type="2"/>
<log location="C:\Logs\CrashTrack" history="24">
<event>
<ne property="Name" value=""/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем полученный лог в момент падения (в нашем примере это 17:09). Выясним причину, изучив последние записи перед событием EXCP (Exception):
09:46.729014,CONN,2,process=1cv8,Usr=Usr,ClientID=2,Txt=Outgoing connection closed,Context='
МодульОбычногоПриложения : 390 : ДОП_ПечатьЦенников.ПечатьЦенников();
ОбщийМодуль.ДОП_ПечатьЦенников.Модуль : 9 : СписокДокументов = ДОП_Общий.ПолучитьДокументыДляПечатиРеактивнойДоставки();'
...
09:46.995000,EXCP,2,process=1cv8,OSThread=7968,Usr=Usr,OSException=1cv8_8.3.13.1513_203af153_20190121170947_10140 enabled
Посмотрим на этот фрагмент внимательно. Мы видим событие CONN со статусом Outgoing connection closed (Исходящее соединение закрыто). Это происходит прямо во время выполнения кода в модуле ДОП_ПечатьЦенников. Платформа пытается выполнить запрос к серверу, но обнаруживает, что канал связи разорван, что и приводит к Access Violation в basic.dll.
Почему соединение обрывается именно в 17:08-17:09? Проанализируем настройки сервера 1С:Предприятие. В консоли администрирования кластера для каждого рабочего сервера существуют параметры перезапуска рабочих процессов. Выясним ситуацию:
Если сервер 1С был запущен, например, в 17:08 вчерашнего дня, то ровно через сутки он попытается «мягко» перезапустить рабочие процессы. Процесс rphost помечается как выключенный, и вместо него запускается новый. Однако, если на клиенте в этот момент выполняется длительная или тяжелая операция (как наша ПечатьЦенников), старый процесс может быть принудительно завершен по истечении времени ожидания, либо клиентская часть некорректно обрабатывает переход на новый процесс.
Рассмотрим, почему это затронуло только одного пользователя. Использование 32-битного клиента накладывает ограничение на адресное пространство процесса (до 2-4 Гб). При выполнении функций печати ценников (где могут участвовать штрихкоды, картинки и тяжелые табличные документы) потребление памяти резко возрастает.
В версии 8.3.13.1513 были зафиксированы ошибки управления памятью при смене контекста соединения. Когда сервер дает команду на переподключение к новому рабочему процессу, 32-битный клиент, уже нагруженный подготовкой печати, не может корректно перестроить дерево объектов в памяти, что и вызывает падение в basic.dll.
Для устранения подобных вылетов разберем два основных пути: настройку сервера и обновление ПО.
Настроим сервер так, чтобы перезапуск процессов не вызывал «шоковой» терапии для клиентских сессий. Рекомендуется использовать следующие параметры в свойствах рабочего сервера:
0 (отключите перезапуск по времени). Перезапуск по интервалу считается устаревшей практикой, которую сама фирма 1С не рекомендует для высоконагруженных систем.3600 секунд), чтобы пользователи успели завершить свои операции и выйти из старого rphost естественным путем.Проанализируем возможность перехода на более стабильные релизы. Ветка 8.3.13 признана многими специалистами переходной и не самой удачной в плане стабильности. Рассмотрим следующие шаги:
Если настройки сервера не помогли, проверим системные механизмы защиты. Функция DEP (Data Execution Prevention) может блокировать выполнение кода в памяти, который генерирует basic.dll при работе с драйверами принтеров или сканеров. Добавим 1cv8.exe в исключения DEP:
Также важно убедиться, что антивирус (например, ESET) не сканирует временные файлы 1С в папке %LOCALAPPDATA%\1C\1cv8, так как блокировка файла .tmp в момент печати ценника вызовет аналогичный сбой доступа к памяти.
Подводя итог, отметим: стабильная работа 1С в клиент-серверном варианте сильно зависит от того, насколько «бесшовно» настроено взаимодействие между клиентской частью и рабочими процессами rphost. Использование Технологического журнала позволяет превратить «мистическое» падение в понятную последовательность событий, где виновником оказывается обычный таймер в настройках кластера.