Расшифровка ошибок 1С: от окна сообщения до технологического журнала

Красное окно «Ошибка при выполнении операции» чаще всего открывают и сразу закрывают. А в нём уже есть половина диагноза: какая операция упала, на какой строке какого модуля и что именно сказала платформа. Читать ошибки 1С нужно сверху вниз: сначала окно, потом журнал регистрации, потом стек вызовов, и только если этого мало, технологический журнал и СУБД.

Ниже порядок, в котором работает администратор. Каждый следующий шаг дороже предыдущего по времени, поэтому до тяжёлых инструментов добираемся, только когда лёгкие ничего не дали.

Из чего состоит окно с ошибкой

У сообщения платформы есть несколько слоёв, и пользователи обычно видят только верхний. Нажмите кнопку подробного текста в окне ошибки. Если её нет, скопируйте сообщение целиком: в обычных формах текст выделяется и копируется комбинацией Ctrl+C.

В развёрнутом виде обычно видно такое:

• 📍 Место возникновения — имя модуля, процедуры и номер строки: {ОбщийМодуль.ИмяМодуля.Модуль(145)}. Число в скобках — строка в модуле.
• 💬 Текст исключения — то, что сказал код или платформа: «Поле объекта не обнаружено», «Деление на ноль», «Нарушено ограничение уникальности».
• 🧩 Вложенные причины — после слов «по причине» идёт цепочка. Самая глубокая запись в конце цепочки — настоящая причина. Верхние лишь обёртки.
• 🖥 Источник — где упало: на клиенте или на сервере. От этого зависит, куда смотреть дальше.

Тип сообщения тоже подсказывает путь. Ошибка в вашем коде или в типовой конфигурации выглядит как текст с модулем и строкой. Сбой платформы — как «Критическая ошибка», «Аварийное завершение» или сообщение о нехватке памяти. Проблемы доступа — «Недостаточно прав». Это три разных ветки диагностики.

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

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

Работа с ним строится на фильтре. Без отбора журнал — тысячи строк.

1. Откройте отбор и задайте интервал — час-два вокруг момента ошибки. Время у пользователя спрашивайте до минуты.
2. Выберите уровень «Ошибка», при необходимости «Предупреждение».
3. Укажите пользователя, если знаете, у кого упало.
4. При необходимости ограничьте событие, например проведение документа или фоновое задание.

Дальше смотрите на колонки. Нужны «Дата», «Пользователь», «Событие» и «Комментарий». Именно в комментарии лежит полный текст ошибки, часто длиннее, чем показал экран. Двойной щелчок по строке открывает карточку с подробностями.

Полезный приём: найдите первую ошибку в серии. Если сначала упала запись справочника, а через минуту десять документов не проведены, виноват первый сбой, остальные — следствие.

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

⚠️ Хранение журнала ограничено настройками. Если событие старое, его там может уже не быть. Для регулярных ошибок настройте разбор журнала сразу после жалобы.

Стек вызовов: как найти строку, которая упала

Стек вызовов — это путь, по которому выполнение пришло к ошибке. Читается он как цепочка: сверху точка падения, ниже тот, кто её вызвал, ещё ниже его вызывающий. Такой список помогает понять не только где сломалось, но и из какого сценария это запущено.

Как получить стек:

• в окне ошибки откройте подробный текст — в нём указаны модули и строки;
• в журнале регистрации комментарий нередко содержит ту же цепочку;
• в конфигураторе можно перейти к модулю по номеру строки: откройте нужный модуль и воспользуйтесь переходом к строке (Ctrl+G).

Как читать записи вида ОбщийМодуль.РаботаСДокументами.Модуль(312): тип объекта, его имя, вид модуля и номер строки. Типовые виды модулей: модуль объекта, модуль формы, модуль менеджера, общий модуль. По виду модуля понятно, на чьей стороне исполнялся код: у формы часть процедур клиентская, а модуль объекта и менеджера выполняется на сервере.

Что делать с находкой:

1. Откройте указанный модуль в конфигураторе и перейдите на строку.
2. Прочитайте несколько строк выше: ошибка часто в подготовке данных, а не в самой строке.
3. Если модуль типовой и без изменений, строка почти всегда указывает на неподходящие данные, а не на баг платформы. Ищите, какое значение пришло пустым или не того типа.
4. Если модуль изменён вашей доработкой, проверьте её автора и дату. Типовая ошибка после обновления — доработка рассчитывала на старый реквизит.

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

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

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

Включается он конфигурационным файлом logcfg.xml. Его кладут в каталог conf рядом с установленной платформой на сервере. После сохранения файла платформа подхватывает настройки, обычно без перезапуска службы.

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

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

Здесь location — каталог, куда пишутся файлы, а history — сколько часов хранить. Каталог создайте заранее и дайте право записи учётной записи, под которой работает служба сервера 1С.

События, которые чаще всего нужны:

Файлы журнала текстовые. Каждая строка начинается с времени и длительности события, дальше идут свойства через запятую. Искать по ним удобно обычным поиском по каталогу, например по тексту ошибки или номеру соединения. Номер соединения и сеанса связывает запись технологического журнала с конкретным пользователем.

⚠️ Не оставляйте подробный технологический журнал включённым надолго. Событие all без отбора заполнит диск за часы и замедлит работу. Включили, воспроизвели ошибку, выключили, убрали файл настройки или события. Если журнал пишется на системный диск сервера, следите за свободным местом.

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

Ошибки СУБД и блокировки: как отличить их друг от друга

Некоторые сообщения на самом деле приходят от СУБД или от механизма блокировок платформы. Узнаются по тексту.

• 🔒 «Превышено максимальное время ожидания блокировки» или «Время ожидания блокировки истекло» — одна транзакция ждала освобождения данных дольше допустимого. Виноват не тот, кто увидел ошибку, а тот, кто держал блокировку.
• 🔁 «Конфликт блокировок при выполнении транзакции» — две операции захватили ресурсы в разном порядке и взаимно ждут. Платформа прерывает одну из них.
• 🗄 Тексты о недоступности сервера СУБД, сбое соединения, нехватке места — инфраструктурные проблемы, не прикладные.
• ⏱ «Тайм-аут запроса» — запрос выполняется слишком долго, обычно из-за большого объёма данных или отсутствия подходящего индекса.

Порядок разбора блокировки:

1. В журнале регистрации найдите время ошибки и пользователя, у которого упало.
2. В технологическом журнале включите TLOCK, TTIMEOUT и TDEADLOCK и повторите сценарий.
3. В записи тайм-аута найдите, кто держал блокировку и по какому ресурсу (таблица и условие).
4. По номеру соединения найдите, что делал держатель. Часто это длинная транзакция: большой документ, обмен или закрытие месяца в то же время, когда пользователи проводят документы.
5. Решение зависит от причины. Развести по времени тяжёлые регламентные операции, сократить транзакцию в коде или обратиться к разработчику.

Не пытайтесь лечить блокировку перезапуском сервера. Он обрывает сеансы всех пользователей и теряет несохранённые данные, а причина вернётся, потому что осталась в сценарии.

Как собирать данные об ошибках без ручной рутины

Когда ошибок много, разбирать их вручную по жалобам неэффективно. Несколько приёмов, которые закрывают рутину:

• 📤 Выгрузка журнала регистрации по расписанию. Через регламентное задание или внешнюю обработку сохраняйте записи уровня «Ошибка» за сутки в файл или справочник. За неделю видно, какие ошибки повторяются.
• 📊 Подсчёт по тексту. Группируйте ошибки по тексту и модулю: пять ошибок из одного места важнее пятидесяти разовых.
• 🔔 Оповещение администратора. Отправляйте сообщение, когда в журнале появляются критические ошибки по важным событиям: обмен, закрытие месяца, регламентные задания.
• 🗂 Готовый комплект для поддержки. Заведите шаблон: текст ошибки, время, пользователь, версия платформы и конфигурации, выгрузка журнала за этот интервал. Поддержка тогда не возвращается с вопросами.
• 🧹 Разбор технологического журнала скриптом. Для EXCP достаточно поиска по каталогу и подсчёта строк с одинаковым текстом. Для сложного анализа используют готовые инструменты разбора технологического журнала.

Версию платформы и конфигурации смотрите в окне «О программе» (меню справки). Эти два номера нужны в любой заявке: без них воспроизвести ошибку нельзя.

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