Диагностика ошибок в 1С: от текста сообщения до причины

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

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

Когда использовать какой способ

Выбор зависит от того, кто вы и что именно произошло.

Прочитайте сообщение целиком, а не только заголовок

В окне ошибки 1С показывает короткую фразу. Настоящая причина часто лежит глубже. Нажмите кнопку «Подробно» (в части окон это ссылка или стрелка рядом с текстом) — откроется полный текст с цепочкой вызовов.

Что искать в развёрнутом тексте:

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

Прежде чем идти дальше, ответьте себе на три вопроса. Воспроизводится ли ошибка у другого пользователя? В какой момент она возникает (проведение, печать, открытие формы)? Что изменилось недавно — обновление, новая настройка, загрузка данных?

Журнал регистрации: что случилось, когда окно уже закрыто

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

Откуда открыть:

• в пользовательском режиме — раздел Администрирование → Поддержка и обслуживание → Журнал регистрации (в типовых конфигурациях 8.3 с интерфейсом «Такси»);
• в Конфигураторе — меню Администрирование → Журнал регистрации.

Для отбора откройте форму отбора и задайте:

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

В найденной записи смотрите колонки «Событие», «Данные», «Комментарий». В комментарии обычно тот же развёрнутый текст ошибки, а в «Данных» — объект, с которым работали. Для фоновых заданий ищите события, связанные с регламентными заданиями: там ошибки видны только в журнале.

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

Отладка: как увидеть, что происходит в коде

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

Подготовка

Работайте на копии базы, а не на рабочей. Отладка останавливает выполнение, и пользователи на боевой базе будут ждать.

1. Откройте копию базы в Конфигураторе.
2. Найдите модуль и строку из текста ошибки. Поиск по конфигурации — Ctrl+Shift+F.
3. Поставьте точку останова на этой строке (F9).

Запуск и разбор

Запустите отладку из меню Отладка → Начать отладку (F5). Платформа откроет 1С:Предприятие в режиме отладки. Воспроизведите действие, после которого появляется ошибка.

Когда выполнение остановится на точке:

• смотрите значения переменных во всплывающей подсказке при наведении курсора;
• добавляйте выражения в окно вычисления (Shift+F9) — можно проверить любое выражение, не меняя код;
• идите по коду по шагам: F11 — с заходом в процедуру, F10 — без захода;
• смотрите стек вызовов, чтобы понять, кто вызвал текущую процедуру.

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

Подключение к уже запущенному клиенту

Отладчик можно подключить к сеансу, который уже работает: меню Отладка → Подключение. Это нужно, когда воспроизвести ошибку можно только в определённом окружении — в веб-клиенте или на тонком клиенте на другом компьютере.

Логирование, консоль и проверка отдельных кусков кода

Не всегда есть возможность запустить отладчик. Тогда помогает логирование: вы записываете значения в журнал регистрации или в сообщение пользователю в нужных местах и смотрите, что получилось. Для записи в журнал программисты используют метод ЗаписьЖурналаРегистрации с уровнем «Ошибка» или «Информация» — события потом отбираются по имени, которое вы сами задали.

Если нужно быстро проверить кусок кода или запрос, не трогая конфигурацию, используют внешнюю обработку «Консоль кода» или «Консоль запросов» из открытых источников (на ИТС и в сообществах их несколько вариантов). Подключается как внешняя обработка через Файл → Открыть, если у пользователя есть право.

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

Проверка целостности базы и конфигурации

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

Тестирование и исправление информационной базы

Меню Администрирование → Тестирование и исправление. Инструмент проверяет логическую и ссылочную целостность, структуру таблиц и может исправить найденное.

Порядок работы:

1. Закройте всех пользователей. Для этого режима нужен монопольный доступ.
2. Сделайте резервную копию базы: инструмент может изменить данные.
3. Сначала запустите режим «Только тестирование» — он ничего не меняет и показывает проблемы.
4. Исправление включайте только после разбора отчёта и только если понимаете, что именно будет исправлено.

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

Меню Конфигурация → Проверка конфигурации. Она ищет синтаксические ошибки, несуществующие ссылки на метаданные, незаполненные обязательные свойства. После доработок или установки расширения это обязательный шаг: часть ошибок видна только тут, а не при обычной работе.

Ошибки в клиент-серверном варианте

В клиент-серверной базе часть кода выполняется на сервере, и сообщение пользователю приходит уже «упакованным». Поэтому дополнительно проверьте следующее.

• 🖥️ Где именно упало. В развёрнутом тексте ищите указание на серверный вызов или модуль. Клиентская и серверная ошибки лечатся по-разному.
• 🗂️ Журнал регистрации на сервере. События серверных процессов попадают в тот же журнал базы, но с отбором по сеансу или пользователю найти нужное проще.
• 🧩 Технологический журнал. Это отдельный механизм платформы. Он настраивается файлом logcfg.xml в каталоге конфигурации платформы на сервере и пишет подробные логи процессов (исключения, долгие вызовы, блокировки). Включайте на ограниченное время и с узким отбором: объём логов растёт очень быстро.
• 🔐 Блокировки и таймауты. Ошибки вроде «Превышено время ожидания блокировки» говорят о конкурирующих транзакциях, а не о коде. Смотрите, кто и чем занят в этот момент.
• 🔌 Сеанс и лицензии. Если ошибка про подключение или недоступность сервера, проверьте консоль кластера: идут ли сеансы, есть ли свободные лицензии.

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

Типичные сообщения и куда смотреть первым делом

Часть ошибок узнаётся с первого взгляда. Ниже — быстрая шпаргалка, чтобы не гонять весь алгоритм зря.

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

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

Чек-лист перед тем, как звать программиста

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

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