Как найти и исправить ошибку «форма.форма.форма» в журнале регистрации 1С

← На главную

Каждый разработчик или администратор системы 1С рано или поздно сталкивается с малоинформативными записями в журнале регистрации (ЖР). Одной из самых загадочных является ошибка вида «форма.форма.форма (номер строки)». Она не указывает на конкретный документ, справочник или отчет, что ставит в тупик даже опытных специалистов. В этой статье мы подробно разберем, что скрывается за этой формулировкой, почему платформа выдает именно такой текст и как пошагово локализовать проблему.

Разбираемся в природе ошибки: почему ЖР пишет «форма.форма.форма»?

Прежде всего, проанализируем структуру этой записи. В нормальной ситуации журнал регистрации выводит полный путь к объекту метаданных, например: Справочник.Номенклатура.Форма.ФормаЭлемента.Форма. Однако, когда платформа не может однозначно сопоставить исполняемый в данный момент код с деревом метаданных конфигурации, она использует универсальный «заглушечный» путь.

Рассмотрим подробнее, что означает каждое слово в этой цепочке:

Первое «форма» — указывает на тип объекта (внешняя форма или динамический объект).
Второе «форма» — обозначает контейнер (основная форма объекта).
Третье «форма» — указывает на сам модуль формы, в котором произошло исключение.

Выясним основную причину появления такой записи. Чаще всего это происходит при работе с внешними обработками (.epf) или внешними отчетами (.erf). Когда пользователь открывает файл напрямую через «Файл — Открыть» или когда обработка запускается программно из временного хранилища (например, через механизм дополнительных отчетов и обработок), платформа загружает ее в память как временный объект. Если в этот момент происходит критическая ошибка, система не всегда может «вспомнить» исходное имя файла и записывает в журнал технический путь модуля.

Способ 1: Анализ контекста сеанса в журнале регистрации

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

Откроем журнал регистрации и установим фильтр по номеру сеанса, в котором произошла ошибка.
Посмотрим на события, которые предшествовали ошибке в пределах 1–2 секунд.
Ищем записи с событием Внешняя обработка. Запуск или Дополнительный отчет или обработка. Запуск.
Часто перед строкой с ошибкой идет информационное сообщение о загрузке конкретного файла из временного каталога или из справочника «Дополнительные отчеты и обработки».

Проанализируем ситуацию: если мы видим, что перед ошибкой пользователь запускал «ЗагрузкаДанныхИзExcel.epf», то с высокой долей вероятности 161-я строка находится именно в модуле формы этой обработки.

Способ 2: Использование Технологического журнала (самый надежный метод)

Когда стандартный журнал регистрации бессилен, на помощь приходит Технологический журнал (ТЖ). В отличие от ЖР, ТЖ фиксирует все исключения (exceptions) на уровне платформы с полным стеком вызовов. Это позволяет увидеть реальный путь к файлу, даже если он находится во временной папке пользователя.

Для настройки сбора нужных данных создадим или отредактируем файл logcfg.xml в каталоге настроек платформы (обычно C:\Program Files\1cv8\conf). Разберем пример конфигурации для отлова нашей ошибки:


<config xmlns="http://v8.1c.ru/7.4/config">
  <log location="C:\LOGS\ERROR_TRACE" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="EXCPCNTX"/>
    </event>
    <property name="all"/>
  </log>
</config>

После активации этой настройки платформа начнет записывать все исключительные ситуации в указанный каталог. В лог-файле ищите событие EXCP. Там будет указан не только текст ошибки, но и полный путь к модулю. Вместо безликого форма.форма.форма вы увидите что-то вроде ExternalDataProcessor.ИмяОбработки.Form.Module(161).

Способ 3: Отладка «Остановка по ошибке»

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

Запустите конфигуратор и подключитесь к рабочему сеансу.
Перейдите в меню Отладка — Настройка отладки.
На вкладке «Остановка по ошибке» установите флажок «Останавливаться по ошибке».
Важно: установите флажок «Игнорировать ошибки в модулях с установленным признаком "Отказ"», чтобы не останавливаться на штатных проверках системы.
Воспроизведите действия пользователя. Платформа сама откроет конфигуратор на нужной строке кода, даже если этот код находится во внешней обработке, временно загруженной в память.

Посмотрим на пример кода, который часто вызывает подобные падения на строке 161 при работе с формами:


&НаКлиенте
Процедура ВыполнитьЗагрузку()
    // Предположим, это строка 161
    Объект.ДанныеЗагрузки.Очистить(); 
    // Ошибка может возникнуть, если Объект.ДанныеЗагрузки — это Неопределено
    // или если форма потеряла связь с данными.
КонецПроцедуры

Способ 4: Поиск по сигнатурам кода

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

Рекомендуется использовать инструменты типа Total Commander или специализированные утилиты поиска текста. В поле «Поиск текста» введите уникальный фрагмент кода, который вы ожидаете увидеть в проблемном месте (если примерно понимаете контекст задачи), либо просто просканируйте каталог с обработками на наличие файлов, где в модуле формы количество строк превышает 161.