Каждый администратор и разработчик 1С рано или поздно сталкивается с ситуацией, когда стабильно работающая система после очередного обновления платформы начинает вести себя непредсказуемо. Одной из наиболее раздражающих проблем является аварийное завершение работы процесса 1cv8.exe (или 1cv8c.exe) через 10–30 секунд после того, как пользователь закрыл программу. Базы закрыты, работа завершена, но операционная система внезапно рапортует об ошибке типа APPCRASH.
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем взаимосвязь между платформой 1С, средствами криптографической защиты информации (СКЗИ), сторонними системами лицензирования и внутренними механизмами СУБД, а также выработаем четкие пошаговые инструкции для устранения сбоев.
Типичный сценарий выглядит следующим образом. Пользователь работает в терминальной сессии или на локальной машине под управлением ОС Windows. В процессе работы никаких нареканий нет: документы проводятся, отчеты формируются. Но как только пользователь нажимает на крестик или выбирает пункт меню «Файл — Выход», визуальное окно программы исчезает, а спустя некоторое время (обычно от 10 до 120 секунд) операционная система выдает стандартное окно ошибки: «Программа 1С:Предприятие прекратила свою работу».
Если мы заглянем в системный журнал Windows (Event Viewer) в раздел «Приложения» (Application), то обнаружим там ошибку с кодом события (Event ID) 1000. В подробностях будет указано:
1cv8.execprevchk.dll, crypt32.dll, mclnt.dll или ntdll.dll0xc0000005 (означает нарушение прав доступа к памяти — Access Violation)Давайте подробно рассмотрим основные причины этого сбоя и разберем методы борьбы с ними.
---
Выясним причину первой и самой распространенной неполадки. При закрытии клиентского приложения 1С запускается процедура выгрузки всех динамических библиотек и модулей из адресного пространства процесса. Если в системе установлены личные сертификаты электронной подписи, использующие алгоритмы ГОСТ, платформа при завершении работы пытается корректно закрыть сессии работы с криптопровайдером через Windows CryptoAPI. Именно в этот момент происходит конфликт между платформой 1С и библиотеками СКЗИ КриптоПро CSP.
Проанализируем ситуацию: чаще всего падение вызывают устаревшие версии КриптоПро или некорректно настроенный компонент проверки отзывов сертификатов. Для решения этой проблемы выполним следующие шаги:
Этот компонент отвечает за проверку списков отзыва сертификатов (CRL) в реальном времени. При закрытии 1С обращение к нему может вызывать зависание и последующий краш процесса. Чтобы его отключить, выполним действия:
Дополнительно рекомендуется отключить функции КриптоПро, которые пытаются встраиваться в процессы авторизации операционной системы. Для этого запустим утилиту управления «КриптоПро CSP» с правами администратора, перейдем на вкладку «Настройки безопасности» (или «Безопасность») и снимем галочку с пункта, разрешающего использование смарт-карт для входа в систему (интеграция с Winlogon).
Иногда сбой провоцируют старые, просроченные или некорректно импортированные сертификаты с устаревшим алгоритмом ГОСТ 2001. Нам необходимо открыть консоль сертификатов:
Win + R, введем команду certmgr.msc и нажмем Enter.Если используется устаревшая ветка КриптоПро CSP (например, 4.0 или ранние сборки 5.0), настоятельно рекомендуется выполнить обновление до сертифицированной версии КриптоПро CSP 5.0 R3 (и выше). В современных сборках разработчики криптопровайдера исправили множество ошибок утечки памяти при работе в многопоточных средах, подобных 1С.
---
Вторая частая причина — это интеграция сторонних модулей защиты. Отраслевые решения от партнеров фирмы 1С (например, решения от компаний «1С-Рарус», «Калуга Астрал» и других разработчиков) используют для контроля лицензирования специальное ПО: **СЛК (Система лицензирования и контроля)** или ключи защиты **Катран**.
Разберем механизм возникновения ошибки. При запуске базы 1С загружается внешний программный модуль защиты (обычно это dll-библиотека в каталоге шаблонов или внутри макета конфигурации), который связывается со службой лицензирования. При выходе из программы 1С посылает сигнал на освобождение лицензии. Если версия библиотеки СЛК несовместима с текущим релизом платформы 1С (например, вы обновили платформу до 8.3.13+, а служба лицензирования осталась старой), процесс выгрузки dll зависает. Через определенный таймаут Windows принудительно завершает процесс с ошибкой.
Посмотрим на алгоритм решения этой проблемы:
Если у вас на сервере крутится несколько баз, проверьте, возникает ли ошибка на пустой (чистой) демо-базе без доработок. Если на чистой базе ошибки нет, а на рабочей отраслевой (например, «Управление автотранспортом» или «Общепит») ошибка стабильно воспроизводится — дело гарантированно в модуле защиты.
Не обязательно покупать новые дорогостоящие лицензии у разработчиков отраслевого решения. Сами дистрибутивы систем лицензирования СЛК версии 3.0 и выше часто доступны для свободного скачивания на сайтах поддержки. Выполним обновление сервера защиты:
---
В некоторых релизах платформы (в частности, в ветке 8.3.13, включая релиз 8.3.13.1644) разработчики фирмы 1С внесли изменения в механизм трансляции запросов к СУБД. Это привело к критической ошибке: при использовании функций работы с датами в условиях виртуальных таблиц или в секциях сравнения дат происходил сбой.
Рассмотрим пример запроса, который мог вызывать неявные ошибки СУБД или приводить к нестабильности сеанса при закрытии транзакций:
ВЫБРАТЬ
ПродажиОбороты.Номенклатура КАК Номенклатура,
ПродажиОбороты.КоличествоОборот КАК Количество
ИЗ
РегистрНакопления.Продажи.Обороты(НАЧАЛОПЕРИОДА(&НачалоГраницы, ДЕНЬ), КОНЕЦПЕРИОДА(&КонецГраницы, ДЕНЬ), , ) КАК ПродажиОбороты
При использовании конструкции НАЧАЛОПЕРИОДА внутри параметров виртуальных таблиц на релизе 8.3.13.1644 платформа генерировала некорректный SQL-код, что нагружало сервер и могло приводить к аварийному завершению работы службы или клиентского приложения.
Варианты решения этой проблемы:
8.3.12.1529 или 8.3.12.1714.8.3.13.1809, 8.3.14 или перейти на актуальные современные ветки (например, 8.3.22+), где данные проблемы оптимизации запросов давно устранены.---
Если предыдущие методы не принесли результата, велика вероятность, что у пользователей накопился поврежденный кэш конфигурации или программа зависает при попытке отправить статистику использования на серверы 1С.
Рассмотрим процедуру полной очистки кэша и настройки сетевой безопасности по шагам:
Завершим все сеансы работы с 1С. Откроем проводник Windows и перейдем по двум путям (вместо %username% подставим имя конкретного пользователя или воспользуемся системными переменными):
%localappdata%\1C\1Cv8 (обычно это C:\Users\ИмяПользователя\AppData\Local\1C\1Cv8)%appdata%\1C\1Cv8 (обычно это C:\Users\ИмяПользователя\AppData\Roaming\1C\1Cv8)Внутри этих папок мы увидим множество папок с длинными буквенно-цифровыми именами (например, 1a2b3c4d-5e6f-...). Это и есть локальный кэш баз данных. Удалим все эти папки. При следующем запуске 1С создаст их заново, подтянув актуальную структуру метаданных с сервера.
При закрытии программа пытается связаться с серверами обновлений и статистики фирмы 1С. Если на сервере терминалов закрыт доступ в интернет или брандмауэр блокирует порты, 1С будет ожидать ответа ровно по таймауту (от 15 до 30 секунд), после чего аварийно закроется. Чтобы предотвратить это:
Подводя итог нашей совместной работе по диагностике, отметим: в 90% случаев падение 1С через 20 секунд после закрытия лечится либо обновлением/настройкой КриптоПро CSP (отключением Revocation Provider), либо обновлением внешних компонент защиты СЛК. Выполнив описанные шаги, вы обеспечите стабильную и бесперебойную работу пользователей в системе.