← На главную

Сталкиваясь с ситуацией, когда у одного из пользователей 1С начинает хаотично «вылетать» 2-3 раза в день, а у остальных все работает стабильно, администратор или программист часто оказывается в тупике. Особенно когда стандартные отчеты об ошибках и журнал регистрации не дают четкого ответа. Проанализируем типичный случай: аварийное завершение работы клиента 1С, где в логах фигурирует сбойный модуль htmlui.dll и код исключения 0xc0000005. Разберем по шагам, как диагностировать и устранить эту проблему.

Ошибка, связанная с библиотекой htmlui.dll, напрямую указывает на проблемы с компонентом платформы, который отвечает за отображение HTML-содержимого в интерфейсе 1С. Это могут быть начальная страница, формы отчетов, баннеры или элементы, добавляемые расширениями. Код 0xc0000005 (Access Violation) говорит о том, что произошло нарушение доступа к памяти, что и приводит к «крашу» приложения. Поскольку проблема проявляется у одного пользователя в терминальной сессии (RDP), круг поиска сужается до его персонального окружения.

Шаг 1. Простые и быстрые методы устранения

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

1. Очистка кэша 1С

Кэш платформы 1С хранит временные данные: метаданные конфигурации, настройки форм и прочую служебную информацию. Иногда эти файлы повреждаются, что приводит к нестабильной работе. Поскольку проблема возникает у конкретного пользователя на терминальном сервере, очистку нужно выполнять именно в его профиле.

Кэш хранится в двух папках. Для их очистки необходимо:

1. Завершить все сеансы 1С данного пользователя.
2. Открыть проводник на терминальном сервере под учетной записью пользователя.
3. Перейти в папку локального кэша, введя в адресную строку %localappdata%\1C\1cv8, и удалить оттуда все папки с длинными буквенно-цифровыми именами (вида d178931d-aad6-475c-bbc3-59bf4394320a).
4. Перейти в папку roaming-кэша, введя в адресную строку %appdata%\1C\1cv8, и проделать ту же операцию.

После удаления этих папок при следующем запуске 1С создаст их заново. Это самый первый и обязательный шаг при любых «плавающих» ошибках.

2. Сброс пользовательских настроек

В базе данных 1С хранятся персональные настройки пользователя: расположение окон, отборы в списках, варианты отчетов и т.д. Иногда повреждение этих настроек может вызывать сбои. Сбросить их можно, не удаляя самого пользователя.

Для этого в режиме «Предприятие» под пользователем с административными правами нужно найти раздел администрирования настроек (например, «Настройки пользователей и прав» -> «Пользователи» -> выбрать нужного пользователя -> «Настройки»). Здесь можно очистить настройки конкретных форм или все настройки целиком. Это безопасная операция, которая вернет интерфейс пользователя к состоянию «по умолчанию».

3. Создание нового профиля на терминальном сервере

Если предыдущие шаги не помогли, проблема может быть глубже — в профиле пользователя Windows на терминальном сервере. Создание нового профиля — это надежный способ исключить влияние любых «накопленных» проблем.

1. Создайте нового пользователя в домене или на сервере терминалов (например, МенслуС_new).
2. Настройте для него те же права доступа к 1С, что и у проблемного пользователя.
3. Попросите пользователя поработать некоторое время под новой учетной записью.

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

Шаг 2. Анализ конфигурации и окружения

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

1. Поэтапное отключение расширений

Расширения, особенно связанные с интеграциями (Ozon, Wildberries, телефония), часто добавляют в интерфейс свои формы с HTML-элементами, выполняют фоновые задания и активно взаимодействуют с платформой. Конфликт между расширениями или ошибка в коде одного из них — частая причина сбоев.

Проведем диагностику методом исключения:

1. Отключите все расширения для проблемного пользователя (или в целом в базе, если это возможно на время теста).
2. Попросите пользователя поработать. Если сбои прекратились — вы на верном пути.
3. Начните включать расширения по одному (или небольшими логическими группами) и после каждого включения наблюдайте за работой системы.
4. Как только сбои возобновятся, вы найдете виновника. После этого можно обратиться к разработчику расширения или искать альтернативу.

2. Проверка системного окружения на сервере

Работа 1С зависит от системных компонентов Windows. Их повреждение может вызывать необъяснимые сбои.

• Проверка целостности системных файлов. Запустите командную строку от имени администратора на терминальном сервере и выполните команду sfc /scannow. Она проверит и восстановит поврежденные системные файлы Windows.
• Обновление Microsoft Visual C++ Redistributable. Убедитесь, что на сервере установлены все актуальные версии этих библиотек, так как многие компоненты 1С зависят от них.

Шаг 3. Глубокая диагностика с помощью Технологического журнала (ТЖ)

Когда все прочие методы исчерпаны, на помощь приходит самый мощный инструмент диагностики платформы 1С — Технологический журнал. Он позволяет записать все внутренние события, происходящие в системе, и с высокой точностью определить, какое именно действие привело к сбою.

1. Настройка Технологического журнала для отлова сбоя

Для отлова аварийного завершения нам нужно настроить ТЖ так, чтобы он не только логировал события, но и создавал дамп памяти (снимок состояния процесса) в момент сбоя.

Для этого:

1. На сервере 1С (или на терминальном сервере, если ошибка в клиенте) перейдите в папку установки платформы, а затем в подпапку conf. Например: C:\Program Files\1cv8\8.3.25.1445\bin\conf.
2. Создайте в этой папке текстовый файл с именем logcfg.xml.
3. Скопируйте в него следующую конфигурацию:
   Скопировать код

   
   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="http://v8.1c.ru/v8/tech-log">
       <log location="C:\1C\Logs\CrashLogs" history="4">
           <event>
               <eq property="name" value="EXCP"/>
           </event>
           <event>
               <eq property="name" value="EXCPCNTX"/>
           </event>
           <property name="all"/>
       </log>
       <dump create="1" location="C:\1C\Dumps" type="3" prntscrn="1"/>
   </config>
   

4. Убедитесь, что папки C:\1C\Logs\CrashLogs и C:\1C\Dumps существуют и у службы сервера 1С есть права на запись в них.

Важные моменты этой конфигурации:

• location="C:\1C\Logs\CrashLogs" — папка, куда будут писаться логи.
• <eq property="name" value="EXCP"/> — включает запись событий исключений (ошибок).
• <dump create="1" ... /> — самая важная часть. Эта строка говорит платформе создать полный дамп памяти процесса в момент его аварийного завершения.

После сохранения файла перезапустите службу Агента сервера 1С, чтобы настройки применились.

2. Анализ результатов

Теперь ждите очередного сбоя. После того как 1С у пользователя «вылетит», в папке C:\1C\Logs\CrashLogs появятся лог-файлы, а в папке C:\1C\Dumps — файл с расширением .dmp. Проанализируйте последние записи в логе перед моментом сбоя — они покажут, какой код выполнялся и какие действия пользователя предшествовали ошибке. Дамп памяти можно проанализировать с помощью специальных утилит (например, WinDbg) или отправить в техподдержку 1С для детального разбора.

Этот метод является наиболее точным и позволяет найти причину даже самых сложных и невоспроизводимых ошибок.