Куда 1С пишет ошибки и как их достать: от окна сообщения до техжурнала

Пользователь пишет: «У меня вылетело красное окно, потом закрылось, помогите». Окна уже нет, а разбираться надо. Все зарегистрированные ошибки 1С лежат в трёх местах: в журнале регистрации (Администрирование → Поддержка и обслуживание → Журнал регистрации), в технологическом журнале сервера и в логах операционной системы и СУБД.

Какое место открывать, зависит от того, что сломалось. Ошибка в документе или отчёте — смотрим журнал регистрации. Вылет сеанса, «зависание» или падение службы — техжурнал и логи системы. Ниже по порядку, от самого простого к самому глубокому.

С чего начать: выбираем нужный журнал

Не лезьте сразу в техжурнал. В 80% случаев ответ уже есть в журнале регистрации, а он включён всегда.

Окно с текстом ошибки: что забрать, пока оно не закрылось

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

Что делать, пока окно открыто:

1. Нажмите «Подробно».
2. Выделите весь текст и скопируйте (Ctrl+C) либо сделайте скриншот целиком, с горизонтальной прокруткой, если она есть.
3. Запишите, что именно делал пользователь: какой документ, какая кнопка, в какую минуту.
4. Только после этого закрывайте окно.

Отдельный случай — сообщения, которые 1С показывает в окне «Сообщения» внизу формы, например «Поле не заполнено». Это не сбои, а проверки заполнения. В журнал они не попадают: это обычные пользовательские сообщения.

Журнал регистрации: основной источник по ошибкам базы

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

Как открыть журнал регистрации

В управляемых конфигурациях быстрее найти журнал через поиск по меню: нажмите на строку поиска и введите «журнал регистрации». Для ERP путь тот же, только раздел «Администрирование» может называться чуть иначе в зависимости от релиза. Если в меню не нашли, ищите по слову.

Как найти нужную ошибку среди тысяч записей

Журнал за день у загруженной базы содержит десятки тысяч событий. Без отбора вы утонете. Откройте форму отбора и задайте:

• ⏱ Период — окно в 5-10 минут вокруг времени сбоя, которое назвал пользователь;
• 👤 Пользователь — тот, у кого случилась ошибка;
• ⚠️ Уровень — «Ошибка» (для начала достаточно его, «Предупреждение» оставьте на потом);
• 🧩 Событие — при необходимости: например, «Данные. Ошибка проведения» или «Сеанс. Ошибка аутентификации».

Двойной щелчок по строке открывает карточку события. Поля, которые нужны в первую очередь:

• «Комментарий» — текст ошибки, часто полный, с модулем и строкой;
• «Метаданные» — какой документ или справочник затронут;
• «Данные» — ссылка на конкретный объект;
• «Приложение» и «Компьютер» — откуда пришёл сбой (толстый клиент, веб-клиент, фоновое задание, мобильное приложение).

Что делать, если журнал пустой или слишком короткий

Три типичные причины:

• 🗑 журнал очищен или сокращён: в файловой базе старые записи уходят при сокращении журнала;
• 📅 вы смотрите не тот период: время в журнале показывается по часовому поясу сеанса, а пользователь называет время по своим часам;
• 🔌 это не серверная ошибка, а клиентская: сбой веб-клиента или браузера в журнал не попадает.

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

Не очищайте журнал регистрации, пока не разберётесь с проблемой. Именно по нему потом ищут виновника ошибки и восстанавливают хронологию.

Технологический журнал: когда журнал регистрации молчит

Технологический журнал (техжурнал) пишет сама платформа, а не прикладное решение. В нём фиксируются исключения (EXCP), аварийные завершения процессов, блокировки, долгие вызовы, обращения к СУБД. По умолчанию он выключен, его включают файлом настроек.

Как включить техжурнал

Файл называется logcfg.xml и лежит в каталоге conf рядом с платформой. На Windows это обычно C:\Program Files\1cv8\conf\logcfg.xml, на Linux — /opt/1cv8/conf/logcfg.xml. Если каталога или файла нет, создайте.

Минимальная настройка, которая пишет исключения:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1c_logs\excp" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Что здесь важно:

• location — каталог для логов, служба 1С должна иметь на него права записи;
• history="24" — хранить записи 24 часа, потом удалять;
• событие EXCP — любое исключение на сервере;
• <property name="all"/> — писать все свойства события, включая текст ошибки и контекст.

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

Как читать записи техжурнала

Каждое событие начинается со строки вида время-длительность,НАЗВАНИЕ,уровень,…, дальше идут свойства через запятую. Для разбора ошибок пригодятся:

Событие EXCPCNTX пишется следом за EXCP и несёт контекст. Начинайте поиск с EXCP: найдите запись по времени, затем читайте блок Context.

Для больших объёмов логи удобнее обрабатывать инструментами, а не глазами: поиск по grep на Linux или Select-String в PowerShell отбирает нужные строки за секунды.

Select-String -Path "C:\1c_logs\excp\*\*.log" -Pattern "EXCP" -Context 0,3

Логи операционной системы и СУБД

Если сервер 1С не запускается или процессы падают без исключения в техжурнале, причину ищут уровнем ниже.

Windows

1. Откройте «Просмотр событий» (eventvwr.msc).
2. Перейдите в Журналы Windows → Приложение и Система.
3. Отфильтруйте по уровню «Ошибка» и «Критический» и по времени сбоя.
4. Ищите источники, связанные с 1С, службой агента сервера (1C:Enterprise 8.3 Server Agent), драйверами и диском.

Типичные находки: нехватка памяти, падение процесса rphost.exe, отказ диска, обрыв сети до СУБД.

Linux

На современных дистрибутивах службу сервера 1С смотрят через systemd:

journalctl -u srv1cv83 --since "1 hour ago"

Имя службы зависит от установки, проверьте его через systemctl list-units | grep 1c. Для сообщений ядра (например, убийство процесса по нехватке памяти) подойдёт dmesg.

СУБД

Что искать: нехватка места, превышение времени ожидания, взаимоблокировки, обрыв подключения. Если вместе с ошибкой 1С в логе СУБД видны те же отметки времени, причина на стороне базы данных, а не прикладного кода.

Проверка конфигурации в Конфигураторе

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

Запуск проверки:

1. Откройте базу в режиме Конфигуратора.
2. Выберите Конфигурация → Проверка конфигурации.
3. Отметьте нужные проверки: синтаксис модулей, поиск неиспользуемых процедур, ссылки на метаданные, логическую целостность.
4. Запустите и дождитесь окна «Результаты» внизу.

Для быстрой проверки одного модуля внутри редактора есть синтаксический контроль (Ctrl+F7). Он находит опечатки, неизвестные переменные и неверные параметры вызова.

Если ошибка воспроизводится у конкретного пользователя, а проверка чистая, используйте отладчик: Отладка → Начать отладку, расставьте точку останова (F9) в модуле из текста ошибки и повторите действие.

Автоматический мониторинг: чтобы узнавать об ошибках раньше пользователей

Когда баз много, ходить по журналам вручную долго. Варианты, от простого к сложному:

• 📧 Оповещение из самой 1С. Регламентное задание, которое раз в час читает журнал регистрации за последний период и отправляет ошибки на почту администратору.
• 📊 Мониторинг серверов. Система вроде Zabbix следит за службами, диском, памятью и пишет в чат, когда служба упала.
• 🧮 Мониторинг производительности. Встроенные средства оценки (APDEX) показывают, что ключевые операции стали медленнее нормы.
• 🔍 Сбор логов в одном месте. Техжурнал и логи ОС отправляют в централизованное хранилище, где по ним ищут по текстам и времени.

Что именно выбрать, зависит от числа баз и пользователей. Для одной бухгалтерии с 5-10 людьми хватит оповещения по почте и проверки места на диске раз в неделю.

Пошаговый разбор: от жалобы пользователя до причины

Типичные ошибки при поиске ошибок

• ❌ Смотрят журнал за весь день без отбора. Результат: тысячи записей и ни одной понятной. Всегда сужайте по времени и пользователю.
• ❌ Путают часовые пояса. Сервер, клиент и пользователь могут жить в разных поясах, время в журнале — серверное.
• ❌ Оставляют техжурнал включённым «на всякий случай». Диск заполняется, база начинает тормозить уже из-за самого логирования.
• ❌ Ищут клиентскую ошибку в серверных логах. Сбой браузера или тонкого клиента лежит в клиентской части, не в журнале базы.
• ❌ Правят типовой код, не прочитав текст ошибки до конца. Пока не открыта полная расшифровка, причина неизвестна.

Частые вопросы