← На главную

В практике сопровождения отраслевых и доработанных конфигураций 1С можно столкнуться с нестандартной ситуацией: при попытке записать или провести любой документ, а также при изменении данных в регистрах сведений сеанс «1С:Предприятие» мгновенно закрывается (вылетает) без отображения каких-либо диагностических сообщений об ошибке. При этом запись элементов справочников может проходить в штатном режиме. Стандартные действия по обслуживанию базы данных — тестирование и исправление (ТиИ), утилита chdbfl.exe, очистка пользовательского кэша и перезапуск на другой платформе — не дают положительного результата.

Разберем детально, почему возникает такое поведение платформы, как локализовать источник сбоя и какими способами можно восстановить корректную работу системы без потери функционала.

Причины аварийного завершения работы

Проанализируем архитектуру отраслевых решений. Основное отличие между справочниками и такими объектами, как документы или регистры сведений, заключается в наличии глобальных обработчиков событий и механизмах лицензирования.

1. Срабатывание подсистемы лицензирования (СЛК, Катран, Guardant). В отраслевых решениях часть функционала поставляется в виде скомпилированных закрытых общих модулей. Разработчики встраивают проверку лицензий в подписки на события записи ключевых объектов (документы, регистры). Если служба лицензирования недоступна, ключ защиты отсутствует, заблокирован порт или повреждена внешняя компонента, защищенный код инициирует метод закрытия программы либо падает из-за обращения к некорректному адресу памяти.
2. Несовпадение разрядности платформы 1С и библиотек защиты. Если используется 64-разрядный клиент (или сервер) 1С, а скомпилированный модуль защиты обращается к 32-разрядным внешним компонентам (DLL), платформа аварийно завершает процесс 1cv8.exe или рабочий процесс сервера rphost.exe.
3. Блокировка системными средствами безопасности (DEP, антивирусы). Механизм Data Execution Prevention (DEP) операционной системы Windows может принудительно гасить процесс при выполнении низкоуровневого кода защиты в оперативной памяти.
4. Зацикливание обработчиков (бесконечная рекурсия). В редких случаях в подписке на событие вызывается метод записи того же самого объекта (ЭтотОбъект.Записать()), что приводит к переполнению стека вызовов и мгновенному падению процесса.

Шаг 1. Локализация источника сбоя

Для подтверждения того, что падение связано именно с подписками на события и системой защиты, выполним диагностические действия.

1. Проверим системный журнал Windows (Event Viewer). Откроем «Просмотр событий» -> «Журналы Windows» -> «Приложение». Найдем событие с кодом Event ID 1000 (Application Error), зафиксированное в момент вылета 1С. В описании события обратим внимание на строку «Имя сбойного модуля» (Faulting module name). Если там указана внешняя библиотека защиты (например, LicenceServer.dll, v8protect.dll и т.д.), сбой однозначно вызван подсистемой лицензирования.
2. Проверим Журнал регистрации 1С. Отфильтруем журнал по событиям завершения сеанса. Если в журнале регистрируется событие «Завершение работы», значит, закрытие платформы было инициировано программно встроенным кодом.
3. Проанализируем состав подписок на события в дереве метаданных. Откроем конфигуратор, развернем ветку Общие -> Подписки на события. Обратим внимание на подписки, у которых в свойстве Источник указан составной тип (например, ДокументОбъект или РегистрСведенийНаборЗаписей), а в качестве обработчика назначен закрытый общий модуль.

Шаг 2. Корректная настройка системы лицензирования

Если конфигурация является лицензионной и использует аппаратные или программные ключи защиты, восстановим работоспособность подсистемы СЛК:

1. Установим или обновим сервер системы лицензирования (СЛК) до актуальной версии из дистрибутива поставщика конфигурации.
2. Проверим состояние службы лицензирования в оснастке services.msc операционной системы — служба должна быть запущена.
3. Убедимся, что сетевые порты сервера лицензирования (по умолчанию 9099 или 15200 в зависимости от версии) открыты и добавлены в исключения брандмауэра Windows.
4. Проверим соответствие разрядности: если компоненты защиты 32-битные, запускаем базу через 32-разрядный клиент «1С:Предприятие».

Шаг 3. Временное устранение сбоя в конфигураторе

Если требуется экстренно восстановить возможность проведения документов и записи регистров, а доступ к серверу лицензирования временно отсутствует, разберем порядок действий по точечному отключению сбойных подписок.

Важно: полное удаление подписок на события приведет к потере отраслевого функционала и нарушению бизнес-логики. Действовать нужно избирательно.

1. Включим возможность изменения конфигурации через меню Конфигурация -> Поддержка -> Настройка поддержки (кнопка «Включить возможность изменения»).
2. Найдем в ветке Подписки на события обработчики, ссылающиеся на закрытые модули.
3. Вместо удаления всей подписки откроем ее свойства и в поле Источник снимем галочки только с тех объектов (например, конкретного регистра или документа), которые вызывают сбой при записи.
4. Выполним поочередное отключение подписок, проверяя запись объектов в режиме «1С:Предприятие», чтобы точно выявить конкретную сбойную подписку.
5. После устранения проблем со службой лицензирования обязательно вернем конфигурацию на типовую поддержку из резервной копии или файла поставки .cf.

Таким образом, комплексная проверка службы защиты и анализ подписок на события позволяют быстро локализовать падение платформы и вернуть систему в рабочее состояние.