Ситуация, когда толстый клиент 1С внезапно закрывается («вылетает») сразу после запуска без вывода каких-либо предупреждений или сообщений об ошибках, является одной из самых сложных для диагностики. Особенно это касается конфигураций на обычных формах, таких как «Управление торговым предприятием» (УТП). В то время как Тонкий клиент и Конфигуратор могут работать абсолютно штатно, толстый клиент просто прекращает процесс.
В этой статье мы совместно разберем пошаговый алгоритм поиска причин такого поведения: от поиска преднамеренных программных «закладок» до анализа системных дампов памяти и настройки технологического журнала. Наша задача — выяснить, на каком этапе происходит прерывание сеанса.
Как показывает практика опытных разработчиков, если база до определенного момента работала стабильно, а после обновления или увольнения сотрудника начала закрываться, первым делом стоит проанализировать программный код на наличие условий завершения работы. Проанализируем ситуацию: код может быть написан так, что он срабатывает только в толстом клиенте и только при определенных условиях (например, достижение конкретной даты или вход под определенным пользователем).
Рассмотрим, где чаще всего прячут подобные механизмы:
ПередНачаломРаботыСистемы и ПриНачалеРаботыСистемы. Именно здесь чаще всего вызывается метод ЗавершитьРаботуСистемы().Посмотрим на пример кода, который может вызывать подобное поведение:
Процедура ПриНачалеРаботыСистемы()
// Проверка на дату, после которой база перестает запускаться
Если ТекущаяДата() > '20231231235959' Тогда
// Код может быть скрыт множеством пробелов
ЗавершитьРаботуСистемы(Ложь);
КонецЕсли;
КонецПроцедуры
Для обнаружения таких «сюрпризов» лучше всего использовать механизм Сравнить и объединить с конфигурацией поставщика или со вчерашним бэкапом. Все лишние или измененные строки кода будут подсвечены системой, что сэкономит часы ручного поиска.
Выясним причину, связанную с правами доступа. В типовых и доработанных конфигурациях существует специфическая роль ЗапускТолстогоКлиента. Если у пользователя (или у всех пользователей после массового изменения прав) эта роль была снята, система может вести себя непредсказуемо. В некоторых конфигурациях логика отказа в доступе прописана жестко: если проверка прав не проходит в модуле приложения, вызывается немедленное завершение работы.
Рекомендуется временно назначить проблемному пользователю полные права и проверить, сохранится ли проблема. Если запуск под полными правами прошел успешно, значит, дело в ограничениях на уровне ролей или RLS (Record Level Security).
Если программный код чист, перейдем к техническим факторам. Часто причиной «молчаливого» вылета становится повреждение локального кэша конфигурации. Рассмотрим подробнее процесс его очистки. Обычного удаления базы из списка и повторного добавления может быть недостаточно.
Необходимо вручную удалить содержимое следующих папок:
%AppData%\Local\1C\1cv8\%AppData%\Roaming\1C\1cv8\Важный момент: если вы работаете в терминальном режиме, попробуйте зайти под другим пользователем Windows. Если под новым профилем ОС 1С стартует нормально, значит, проблема локализована в настройках конкретного пользователя или в его временных файлах (папка Temp).
Когда стандартные средства не помогают, проанализируем ситуацию с помощью «тяжелой артиллерии» — Технологического журнала 1С. Это позволит нам увидеть, что происходит в системе за миллисекунды до закрытия процесса 1cv8.exe. Разберем по шагам, как его настроить.
Создайте текстовый файл с именем logcfg.xml в папке C:\Program Files\1cv8\conf\ (или bin\conf конкретной версии платформы). Содержимое файла должно быть следующим:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\1C_Logs" history="2">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<property name="all"/>
</log>
</config>
После этого запустите толстый клиент. После его вылета откройте созданную папку C:\1C_Logs. Ищите файлы логов, где зафиксировано событие EXCP (Exception). Там будет указан адрес ошибки в памяти или конкретный модуль (например, какая-то внешняя компонента или dll-библиотека), вызвавший падение.
Выясним системные причины. Функция Windows DEP (предотвращение выполнения данных) может ошибочно принимать активность толстого клиента за попытку атаки (например, при попытке записи в защищенную область памяти). Поскольку толстый клиент выполняет гораздо больше операций напрямую с ОС, чем тонкий, он чаще попадает под подозрение.
Рассмотрим, как добавить 1С в исключения DEP:
sysdm.cpl).1cv8.exe вашей версии платформы.Также стоит проверить журналы антивирусного ПО. Бывают случаи, когда антивирус блокирует создание временных файлов в каталоге C:\Users\ИмяПользователя\AppData\Local\Temp\, что приводит к немедленному закрытию приложения без вывода сообщений.
Если вы используете 32-битный клиент 1С (что часто встречается даже на 64-битных ОС), помните об ограничении адресного пространства в 2 Гб. Тяжелые конфигурации, такие как УТП, при запуске толстого клиента в режиме «Обычное приложение» загружают в память огромное количество метаданных.
Если в момент загрузки конфигурации лимит памяти исчерпывается, процесс может «схлопнуться» без сообщения Out of Memory, так как на вывод самого сообщения памяти уже не остается. Проанализируем потребление памяти через «Диспетчер задач» в момент запуска: если значение приближается к 1.8–2 Гб, это явный признак проблемы. Решением в данном случае будет переход на 64-битный клиент 1С или оптимизация модулей приложения.
Подводя итог, если толстый клиент 1С закрывается молча, мы действуем методом исключения: сначала проверяем программный код на предмет «закладок» и условий завершения, затем проверяем права доступа, очищаем кэш и, в финале, используем Технологический журнал для выявления системных сбоев. Системный подход всегда позволяет найти корень проблемы, даже если она тщательно замаскирована.