Ошибки 1С: где посмотреть и как разобраться в причинах

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

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

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

Где посмотреть ошибки в журнале регистрации 1С

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

Чтобы найти нужную ошибку, используйте отбор: задайте период вокруг момента сбоя, выберите уровень важности «Ошибка» и при необходимости конкретного пользователя. Двойной щелчок по событию открывает карточку с подробным описанием, включая текст исключения и контекст — какой объект или операция вызвали сбой.

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

Как включить и читать технологический журнал

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

В файле logcfg.xml задаются события для записи (например, EXCP — исключения, DBMSSQL — запросы к MS SQL Server, TLOCK и TDEADLOCK — блокировки) и каталог, куда складывать логи. После создания файла платформа начинает писать логи без перезапуска в течение примерно минуты. Логи представляют собой текстовые файлы, сгруппированные по процессам и времени.

Для разбора технологического журнала удобно искать по времени сбоя и по ключевым словам: EXCP, EXCPCNTX, Deadlock, Error. Событие EXCPCNTX показывает контекст исключения — стек вызовов, по которому можно определить, в каком модуле конфигурации возникла ошибка.

<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1clogs" history="24"><event><eq property="name" value="EXCP"/></event><event><eq property="name" value="DBMSSQL"/></event><property name="all"/></log></config>

Где искать ошибки в клиент-серверном варианте

В клиент-серверной архитектуре источников диагностики больше, и ошибку часто видно не в самой 1С, а на уровне инфраструктуры. Проверять нужно три уровня: сервер 1С:Предприятия, СУБД и операционную систему.

На сервере 1С откройте консоль администрирования кластера и посмотрите список сеансов и соединений: зависшие сеансы и ошибки рабочих процессов видны там. Дополнительно проверьте журнал регистрации кластера и каталог служебных файлов сервера (srvinfo), где лежат логи рабочих процессов rphost.

На стороне СУБД смотрите штатные журналы: для MS SQL Server — SQL Server Error Log и журнал приложений Windows, для PostgreSQL — лог-файлы, путь к которым задан в конфигурации. Ошибки вида «Ошибка СУБД: deadlock victim» или «could not serialize access» именно там содержат детали: какие таблицы и транзакции конфликтовали.

Как диагностировать ошибки обновления и обмена данными

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

При сбоях обмена данными (РИБ, обмен с сайтом, синхронизация между базами) информация ищется в трёх местах: журнале регистрации, протоколе обмена в самой базе (в типовых конфигурациях — «Результаты обмена данными» в разделе синхронизации) и файлах протоколов, которые создаются в каталоге обмена. Протокол обмена обычно содержит построчный разбор: какой объект не выгрузился и почему.

Отдельный частый случай — ошибки фоновых заданий. Откройте консоль заданий (в типовых — «Администрирование» → «Поддержка и обслуживание» → «Регламентные и фоновые задания») и посмотрите состояние: у упавшего задания будет статус с ошибкой и текст исключения в свойствах выполнения.

1. 1
   Зафиксируйте точный текст ошибки, время и действие пользователя
2. 2
   Откройте журнал регистрации и отфильтруйте события уровня «Ошибка» за этот период
3. 3
   Проверьте, повторяется ли ошибка у других пользователей и на других компьютерах
4. 4
   При зависаниях и аварийных завершениях включите технологический журнал и воспроизведите сбой
5. 5
   В клиент-серверном варианте проверьте логи СУБД и журнал событий Windows
6. 6
   По найденному контексту определите: проблема в данных, коде, правах или инфраструктуре

Ошибки кэша и локальные сбои клиента

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

Кэш хранится в профиле пользователя: в каталогах вида %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8 в папках с идентификаторами баз. Безопасный способ сброса — удалить базу из списка в окне запуска и добавить заново, либо при закрытой 1С удалить соответствующую папку кэша. Данные информационной базы при этом не затрагиваются — кэш пересоздастся автоматически.

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

Типичные ошибки диагностики и как их избежать

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

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

Третья ошибка — искать причину только в 1С, когда проблема инфраструктурная. Переполненный диск с tempdb, отключённая сетевая карта, нехватка памяти на сервере СУБД проявляются как «ошибки 1С», но лечатся на уровне сервера. Журналы Windows и мониторинг ресурсов — обязательная часть проверки.

Как проверить, что проблема решена

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

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

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