Ищем ошибки в 1С: от проверки модулей до анализа базы и журналов

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

Это три разных уровня: код и метаданные, данные в базе, поведение программы в работе. Сбой «база не открывается» и сбой «отчёт показывает <Объект не найден>» лечатся разными инструментами. Ниже порядок, в котором их удобно применять, от безопасных к тем, что меняют базу.

Что подготовить до проверки

Часть проверок только читает конфигурацию, часть исправляет данные. Перед вторыми нужна страховка.

📌 Что сделать заранее:

• 💾 Резервная копия. Выгрузка Администрирование → Выгрузить информационную базу... в файл .dt, для клиент-серверной базы дополнительно — бэкап средствами СУБД.
• 🧪 Копия для экспериментов. Режим «Тестирование и исправление» лучше сначала прогнать на копии: так видно, что он изменит.
• 👥 Окно без пользователей. Тестирование базы и физическая проверка файла требуют монопольного доступа. Все сеансы придётся завершить, поэтому планируйте вечер или выходной.
• 🔑 Права. Нужен пользователь с полными правами и доступ в Конфигуратор.

Какой инструмент за что отвечает:

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

Начинайте отсюда: проверка ничего не меняет и не мешает пользователям.

Быстрая проверка модулей

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

Это быстрый тест после правки кода. Он ловит опечатки, незакрытые блоки Если ... КонецЕсли, обращения к несуществующим переменным в строгих контекстах.

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

Конфигурация → Проверка конфигурации... открывает окно с набором флажков. Основные:

1. Проверка логической целостности конфигурации — ищет противоречия в метаданных: реквизит ссылается на удалённый объект, у регистра нет регистратора, форма указывает на несуществующую команду.
2. Поиск некорректных ссылок — ссылки на объекты метаданных, которых в конфигурации нет.
3. Синтаксический контроль модулей — с выбором контекстов: тонкий клиент, веб-клиент, сервер, внешнее соединение, мобильный клиент. Код, который компилируется на сервере, может не скомпилироваться в веб-клиенте, поэтому отмечайте те режимы, в которых реально работают пользователи.
4. Поиск неиспользуемых процедур и функций — подсказка для чистки кода, не ошибка.
5. Проверка существования назначенных обработчиков — событие формы указывает на процедуру, которой нет в модуле.
6. Поиск пустых обработчиков — обработчик есть, тела нет. Лишний вызов, особенно на клиенте.
7. Расширенная проверка — дополнительные правила: синхронные вызовы, модальность, использование методов, недоступных в выбранном контексте.

После нажатия «Выполнить» результат появится в окне сообщений. Каждая строка кликабельна.

Проверка из командной строки

Ту же проверку можно запускать без открытия Конфигуратора, например по расписанию после каждой загрузки изменений:

"C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"" ^
  /CheckConfig -ConfigLogIntegrity -IncorrectReferences -ThinClient -WebClient -Server ^
  -ExternalConnection -HandlersExistence -EmptyHandlers -ExtendedModulesCheck ^
  /Out"D:\Logs\check_config.log"

Номер платформы в пути подставьте свой. Для клиент-серверной базы вместо /F используется /S"сервер\имя_базы". Результат пишется в файл из параметра /Out.

Ссылочная целостность данных: тестирование и исправление базы

Проверка конфигурации смотрит на метаданные. Данные она не трогает. Если в отчётах видно <Объект не найден> (45:b8f2...), а документ не проводится из-за пустой ссылки, проблема в данных.

Когда нужен этот режим

• 🔗 в отчётах и формах выводится <Объект не найден>;
• 📉 остатки в оборотно-сальдовой ведомости не сходятся с движениями;
• 💥 база падала при записи, отключалось питание, обрывалась сеть;
• 🐢 база заметно замедлилась после массовой загрузки или удаления.

Порядок запуска

1. Завершите сеансы пользователей. Предупредите их заранее: при завершении сеанса несохранённые данные теряются.
2. Откройте Конфигуратор и выберите Администрирование → Тестирование и исправление....
3. Отметьте проверки: реиндексация таблиц, проверка логической целостности, проверка ссылочной целостности, пересчёт итогов. Сжатие и реструктуризацию включайте отдельно и только при необходимости — они идут дольше всего.
4. Первый прогон выполните в режиме «Тестирование», без исправления. Вы получите список проблем, а база останется прежней.
5. Изучите протокол. Если битых ссылок десяток — найдите их источник. Если тысячи — вероятно, в прошлом удалили справочник или загрузили данные с ошибкой.
6. Второй прогон, уже «Тестирование и исправление», выполняйте на копии, затем на рабочей базе.

Как выбрать действие для битых ссылок

Тот же режим запускается из командной строки ключом /IBCheckAndRepair с параметрами -ReIndex, -LogIntegrity, -RecalcTotals и -TestOnly для режима без исправления.

Физическая проверка файла базы

Для файловой базы есть отдельная утилита chdbfl.exe в папке bin платформы. Она проверяет структуру файла 1Cv8.1CD, а не данные учёта.

Закройте базу у всех пользователей, запустите chdbfl.exe, укажите путь к файлу. Сначала снимите флажок «Исправлять обнаруженные ошибки» и посмотрите отчёт.

Для клиент-серверной базы физическую целостность проверяют средствами СУБД. В MS SQL Server это DBCC CHECKDB, в PostgreSQL — штатные инструменты обслуживания этой СУБД. Их запускает администратор СУБД.

Журнал регистрации: ошибки, которые видят пользователи

Если ошибка возникает «иногда» и «у кого-то», ищите её в журнале регистрации. Он хранит события сеансов: вход, запись объектов, ошибки выполнения.

Где открыть:

• в Конфигураторе — Администрирование → Журнал регистрации;
• в БП 3.0, ЗУП 3.1, УТ 11 — Администрирование → Обслуживание → Журнал регистрации;
• в любой конфигурации — через меню Все функции → Стандартные → Журнал регистрации (команду «Все функции» включают в Сервис и настройки → Параметры).

Как отфильтровать нужное

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

В колонке «Комментарий» лежит текст исключения вместе с модулем и номером строки, например {ОбщийМодуль.ОбменДанными.Модуль(1520)}. Это прямой адрес места в коде.

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

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

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

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

Параметр history — сколько часов хранить логи. Журнал быстро растёт, поэтому вынесите его на диск со свободным местом и не включайте лишние события надолго. После сбора данных удалите или переименуйте logcfg.xml.

Проверка производительности и поиск тяжёлых операций

Ошибкой считается и проведение документа за 40 секунд. Такие места ищут замером.

Замер производительности в отладке

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

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

Типичные тяжёлые конструкции

• 🔁 Запрос в цикле. 1000 строк табличной части дают 1000 обращений к СУБД вместо одного запроса с временной таблицей.
• 🔗 Разыменование ссылок через точку. Строка.Номенклатура.ЕдиницаИзмерения.Наименование в цикле — каждый раз неявный запрос.
• 📦 Виртуальная таблица без параметров. Отбор по остаткам ставят в условие ГДЕ вместо параметров виртуальной таблицы, и СУБД читает лишнее.
• 🔒 Длинные транзакции. Внешний вызов или ожидание пользователя внутри транзакции держит блокировки, и другие пользователи получают таймаут.

Наблюдение за работающей базой

Для сервера 1С полезны технологический журнал с событиями запросов к СУБД (DBMSSQL для MS SQL, DBPOSTGRS для PostgreSQL) и отбором по длительности. Так находят запросы, которые выполняются дольше заданного порога у реальных пользователей, а не в отладке.

Для регулярного контроля 1С предлагает отдельный продукт — Корпоративный инструментальный пакет с Центром управления производительностью. Он оценивает операции по методике APDEX и показывает, какие из них стали медленнее.

Проверка кода на соответствие стандартам разработки

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

АПК

Автоматизированная проверка конфигураций (АПК) — бесплатная конфигурация от 1С для проверки по системе стандартов и методик разработки. В неё выгружают метаданные и модули проверяемой конфигурации, после чего запускают набор правил. Результат — список нарушений с указанием объекта и ответственного.

АПК удобна команде, которая дорабатывает типовую или пишет свою: ошибки собираются в одном месте, у каждой есть статус.

BSL Language Server и SonarQube

Открытый проект BSL Language Server анализирует модули 1С вне платформы. Его используют:

• в редакторе VS Code с расширением для языка 1С — замечания видны прямо при наборе;
• в SonarQube через плагин для 1С — отчёт по всему проекту, история качества от сборки к сборке.

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

1C:EDT

Если разработка ведётся в 1C:Enterprise Development Tools, проверки работают постоянно. Ошибки и предупреждения выводятся в панели проблем, без отдельного запуска.

Что проверить после обновления или доработки

После обновления типовой и после загрузки доработок ошибки чаще всего прячутся на стыке. Короткий порядок контроля:

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