При работе в программе 1С:Зарплата и управление персоналом (ЗУП) 3.1 пользователи иногда сталкиваются с критической ошибкой: в момент записи, проведения или закрытия документа «Изменение штатного расписания» программа мгновенно прекращает работу и «вылетает» в дамп. При этом стандартные процедуры обслуживания, такие как очистка локального кэша, тестирование и исправление (ТиИ) базы данных или проверка утилитой chdbfl.exe, не приносят желаемого результата. Ошибка стабильно воспроизводится как на локальных компьютерах, так и при переносе информационной базы на SQL-сервер.
В этой статье мы подробно проанализируем техническую природу этой проблемы, разберем данные технологического журнала и рассмотрим практические шаги для её устранения.
Для того чтобы понять, почему происходит аварийное завершение работы, обратимся к логам технологического журнала 1С. В момент падения платформы в лог записывается следующая критическая ошибка:
Неправильное имя пользователя или пароль Ошибка при выполнении запроса POST к ресурсу /e1cib/login
Эта ошибка указывает на сбой аутентификации при попытке платформы инициализировать новое фоновое (сеансовое) соединение. Рассмотрим подробнее, как это связано со штатным расписанием.
При проведении документа «Изменение штатного расписания» конфигурация 1С:ЗУП 3.1 инициирует множество фоновых и регламентных процессов:
Занятость позиций штатного расписания и Начисления позиций штатного расписания.Для выполнения асинхронных операций платформа создает новый фоновый поток (сеанс) и пытается неявно авторизовать его под учетными данными текущего пользователя. На устаревших релизах платформы семейства 8.3.12 (например, 8.3.12.1469 или 8.3.12.1567) присутствует зарегистрированная ошибка (баг платформы): механизм авторизации фонового задания дает сбой, если у пользователя настроена Windows-аутентификация (доменная авторизация) или установлен пустой пароль. Платформа теряет токен авторизации при POST-запросе к /e1cib/login, что приводит к необрабатываемому исключению и падению клиента в дамп.
---
Одним из неочевидных, но эффективных способов решения проблем с сессиями пользователей является полная программная очистка их настроек, хранящихся непосредственно в базе данных. Обычная очистка физического кэша на диске компьютера здесь не поможет, поскольку настройки форм и сессий кэшируются внутри системных таблиц базы.
Мы можем написать простую обработку, которая очистит эти настройки для всех или для конкретного пользователя. Для этого используется метод глобального контекста ОчиститьНастройкиПользователя(). Нам потребуется запустить эту процедуру в режиме Толстого клиента.
Рассмотрим пример кода, который обходит список всех пользователей информационной базы и очищает их системные настройки:
&НаСервере
Процедура ОчиститьНастройкиВсехПользователейНаСервере()
// Получаем список всех зарегистрированных пользователей ИБ
ПользователиСписок = ПользователиИнформационнойБазы.ПолучитьПользователей();
Для Каждого ТекущийПользователь Из ПользователиСписок Цикл
Попытка
// Очищаем настройки пользователя в системных хранилищах базы данных
ОчиститьНастройкиПользователя(ТекущийПользователь);
ЗаписьЖурналаРегистрации("Администрирование.ОчисткаНастроек",
УровеньЖурналаРегистрации.Информация,
,
,
"Успешно очищены системные настройки для пользователя: " + ТекущийПользователь.Имя);
Исключение
ЗаписьЖурналаРегистрации("Администрирование.ОчисткаНастроек",
УровеньЖурналаРегистрации.Ошибка,
,
,
"Не удалось очистить настройки пользователя: " + ТекущийПользователь.Имя + ". Ошибка: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
КонецПроцедуры
После выполнения данного кода будут удалены устаревшие и поврежденные кэшированные настройки окон, форм и отчетов, которые могли вызывать конфликт при неявной авторизации фоновых заданий.
---
Если обновление платформы временно невозможно, мы можем обойти ошибку, заблокировав фоновые триггеры, запускающиеся при проведении документа. Проанализируем настройки конфигурации ЗУП:
После отключения этих опций платформа перестанет инициировать ресурсоемкие асинхронные вызовы в момент записи изменений штатного расписания, что позволит успешно записать и провести документ.
---
Поскольку корень ошибки лежит в сбое POST-запроса /e1cib/login при создании фонового потока, нам необходимо проверить настройки авторизации пользователя, под которым происходит вылет в дамп:
---
Если в вашей информационной базе подключена Система взаимодействия (обсуждения внутри объектов конфигурации), то при проведении документов программа пытается передать информацию на сервер сообщений через фоновые веб-службы. При нестабильном интернет-соединении или ошибках авторизации на сервере 1С:Диалог это гарантированно приводит к моментальному аварийному завершению работы 1С.
Чтобы исключить этот фактор, выполним следующие действия:
---
Описанная проблема с падением сессии при POST-запросе к /e1cib/login признана разработчиками 1С системной ошибкой платформы семейства 8.3.12. В этой ветке присутствуют критические утечки памяти и некорректная обработка сетевых сокетов при эмуляции локальных вызовов в файловом режиме.
Единственным надежным и долгосрочным решением является переход на более современные и стабильные версии платформы. Рекомендуется обновить платформу 1С:Предприятие как минимум до актуальных релизов веток 8.3.14, 8.3.16 или до актуальной стабильной версии (например, 8.3.20+ и выше). В этих версиях механизм инициализации фоновых заданий под учетными данными текущего пользователя был полностью переработан, что исключает возникновение подобных сбоев.