Где прячется ошибка в модуле 1С и как её поймать: от журнала до отладчика

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

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

Что сообщение об ошибке уже говорит о месте сбоя

Окно ошибки в 1С содержит больше, чем видит пользователь. Раскройте подробности сообщения или попросите пользователя сформировать отчёт об ошибке — там будет стек.

Как читать типичное сообщение:

{Документ.РеализацияТоваровУслуг.МодульОбъекта(412)}: Ошибка при вызове метода контекста (Записать)
    по причине:
{ОбщийМодуль.ПроведениеСервер.Модуль(87)}: Значение не является значением объектного типа (Склад)

• 📍 {…МодульОбъекта(412)} — модуль и номер строки, где исключение всплыло наверх.
• 🔗 «по причине» — вложенная ошибка. Читайте снизу вверх: самая нижняя строка и есть первопричина.
• 🧩 В скобках после текста — имя свойства или переменной, на которой код споткнулся. Здесь это Склад: в поле пусто или лежит не ссылка.

Частые тексты и что за ними обычно стоит:

Журнал регистрации и техжурнал: ищем ошибку, которой нет у вас

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

Журнал регистрации

Открыть его можно двумя путями:

1. В Конфигураторе: Администрирование → Журнал регистрации.
2. В пользовательском режиме БП, ЗУП и УТ — раздел Администрирование → Обслуживание, группа протоколов работы.

Дальше установите отбор: уровень «Ошибка», нужный интервал и пользователя. В строке события смотрите поля «Метаданные», «Данные» и «Комментарий» — в комментарии лежит текст исключения с номером строки модуля.

Чтобы собственный код оставлял полезные следы, пишите в журнал подробное представление ошибки, а не короткое:

Попытка
    ВыполнитьОбменСУзлом(Узел);
Исключение
    Инфо = ИнформацияОбОшибке();
    ЗаписьЖурналаРегистрации("Обмен.ОшибкаВыгрузки",
        УровеньЖурналаРегистрации.Ошибка,
        Метаданные.ПланыОбмена.Полный,
        Узел,
        ПодробноеПредставлениеОшибки(Инфо));
    ВызватьИсключение;
КонецПопытки;

ПодробноеПредставлениеОшибки сохраняет стек, а ВызватьИсключение без параметров пробрасывает исходную ошибку дальше. Пустой блок Исключение … КонецПопытки без записи — главный враг поиска: ошибка была, а следов нет.

Технологический журнал

Техжурнал нужен, когда ошибка падает на сервере, в фоновом задании или связана с СУБД. Его включают файлом logcfg.xml в каталоге conf установленной платформы (например, C:\Program Files\1cv8\conf). Минимальная настройка для сбора исключений:

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

• 🗂 location — папка для логов, у службы сервера 1С должны быть права на запись.
• ⏳ history — сколько часов хранить файлы.
• ⚡ EXCP — исключения. Для блокировок добавляют события TLOCK, TTIMEOUT, TDEADLOCK.

Отладчик 1С: как поймать ошибку на нужной строке

Когда место примерно известно, переходите к отладчику. Он показывает значения переменных в момент сбоя — это то, чего нет ни в одном журнале.

Запуск отладки

1. Откройте Конфигуратор и запустите клиент через Отладка → Начать отладку (F5). Клиент сразу подключится к отладчику.
2. Поставьте точку останова на подозрительной строке: F9.
3. Воспроизведите действие пользователя. Выполнение остановится на точке.

Клавиши, которые нужны постоянно:

Остановка по ошибке — главный приём

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

Дальше откройте стек вызовов и пройдите вверх: часто неправильное значение пришло из вызывающей процедуры, а не родилось в строке падения.

Точка останова с условием

Ошибка падает на 3 412-й строке табличной части из 5 000? Поставьте точку с условием (Ctrl+Shift+F9), например Строка.Количество = 0. Отладчик пропустит все «хорошие» итерации.

Отладка серверного кода в клиент-серверной базе

В файловой базе серверный код отлаживается сразу. В клиент-серверной точки останова в серверных модулях не сработают, пока сервер 1С не запущен с разрешённой отладкой: в параметрах службы агента сервера (ragent) должен быть ключ -debug.

Фоновые задания и HTTP-сервисы подключают через Отладка → Подключение: там видны предметы отладки, к которым можно присоединиться.

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

Многие ошибки появляются после доработки: реквизит переименовали, а в одном из модулей осталось старое имя. Найти все места помогают три инструмента Конфигуратора.

• 🔎 Поиск ссылок на объект. Щёлкните правой кнопкой по объекту в дереве метаданных и выберите поиск ссылок. Покажет формы, макеты, роли, подписки и другие объекты, где он задействован.
• 🧭 Глобальный поиск (Ctrl+Shift+F). Ищет текст по всем модулям сразу. Удобно искать имя процедуры, имя реквизита в кавычках ("Склад") или текст из ВызватьИсключение.
• 🗺 Переход к определению (F12). Встаньте на вызов процедуры — откроется её текст, даже в другом общем модуле.

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

Блокировки и конфликты доступа: ошибки, которые не видны в одиночку

Код может быть верным и падать только при одновременной работе нескольких пользователей. Типичные тексты:

• ⛔ Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки
• 🔁 Сообщения о взаимоблокировке (deadlock) от СУБД или менеджера блокировок.

Как искать причину:

1. Проверьте свойство конфигурации «Режим управления блокировкой данных» (корень дерева метаданных → свойства). В режиме «Управляемый» конфликты возникают на объектах БлокировкаДанных из кода, в «Автоматическом» — на уровне СУБД.
2. Включите в техжурнале события TLOCK, TTIMEOUT и TDEADLOCK. В событии TTIMEOUT есть сведения о сеансе-виновнике и области, которую он держал.
3. Найдите в коде блокировку этой области и посмотрите, что происходит после неё до конца транзакции.

Частые причины в коде:

• 🐢 Долгая транзакция: внутри проведения вызывают внешний сервис, формируют отчёт или обрабатывают тысячи строк.
• 📐 Слишком широкая блокировка: блокируют весь регистр, а не измерения конкретного документа.
• 🔀 Разный порядок блокировок в двух процедурах: первая захватывает остатки, потом взаиморасчёты, вторая — наоборот. Это классический путь к взаимоблокировке.
• 🕳 Чтение без блокировки перед записью: два сеанса читают один остаток и оба списывают его.

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

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

Встроенные проверки Конфигуратора

• ✅ Синтаксический контроль модуля (Ctrl+F7) — ловит опечатки и незакрытые конструкции в открытом модуле.
• 🧪 Проверка конфигурации — Конфигурация → Проверка конфигурации. Отметьте логическую целостность, поиск некорректных ссылок и расширенную проверку для нужных режимов: тонкий клиент, веб-клиент, сервер, внешнее соединение. Расширенная проверка находит вызовы, недоступные в конкретном контексте, — то, что синтаксический контроль пропускает.
• 🧹 Там же есть поиск неиспользуемых процедур и функций. Мёртвый код не ошибка, но мешает читать модуль.

Внешние инструменты

Проверка исправления

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

Ошибки в управляемых формах: клиент, сервер и контекст

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

Типичные ошибки и их смысл:

• 🧱 Переменная не определена (Объект) внутри &НаСервереБезКонтекста — процедура не видит форму. Передайте нужные значения параметрами или смените директиву на &НаСервере.
• 🔌 Метод объекта не обнаружен при вызове с клиента — процедура описана без серверной директивы или находится в общем модуле без флага «Вызов сервера».
• 🪟 Использование модальных окон в данном режиме запрещено — в коде Вопрос() или Предупреждение(), а в свойствах конфигурации модальность отключена. Замените на ПоказатьВопрос с ОписаниеОповещения.
• ⏳ Использование синхронных методов на клиенте запрещено — то же для работы с файлами и внешними компонентами. Нужны асинхронные аналоги методов.
• 🔗 Обращение через точку на клиенте (Объект.Контрагент.ИНН) не работает : на клиенте есть только ссылка. Получите реквизит серверным вызовом.

Быстрая диагностика по симптому

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