Откуда в 1С:Предприятии 8.3 берутся сбои и как найти их источник

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

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

Пять источников ошибок в 1С: как опознать по тексту

Текст ошибки почти всегда подсказывает группу. Сначала классифицируйте, потом чините.

Ошибки кода содержат путь в фигурных скобках: {Документ.РеализацияТоваровУслуг.МодульОбъекта(512)}. Если путь указывает на Расширение или внешнюю обработку — источник найден. Ошибки СУБД начинаются со слов Ошибка СУБД и дальше несут текст самого сервера баз данных, часто на английском.

Блокировки и медленная работа: почему пользователи мешают друг другу

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

Как возникает конфликт

• 📦 Два кладовщика одновременно проводят документы по одному складу и номенклатуре — оба меняют остатки в одном регистре.
• 📅 Бухгалтер закрывает месяц, а менеджеры в это время проводят продажи задним числом.
• ⏳ Тяжёлая регламентная операция (перепроведение, пересчёт итогов) держит блокировку минутами.
• 🔁 Взаимоблокировка: транзакция А ждёт данные, захваченные Б, а Б ждёт данные А. СУБД убивает одну из них.

Что помогает

1. Посмотрите, кто работал в момент ошибки: Администрирование → Обслуживание → Журнал регистрации, отбор по времени ±1 минута.
2. Разведите по времени тяжёлые операции. Закрытие месяца и групповое перепроведение — вечером или в выходной, когда документы не проводят.
3. Проверьте таймаут ожидания блокировки. В клиент-серверной базе его задают в Конфигураторе: Администрирование → Параметры информационной базы. По умолчанию — 20 секунд. Увеличение до 40–60 секунд маскирует проблему, а не решает её, но иногда спасает в пиковые часы.
4. Проверьте режим блокировок в свойствах конфигурации. Типовые конфигурации на актуальных релизах работают в управляемом режиме. Если в доработанной базе стоит автоматический режим, блокировки берутся на уровне СУБД и захватывают лишние строки.

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

Сбои после обновления платформы и конфигурации

Обновление — самый частый источник «внезапных» ошибок. Вчера всё работало, сегодня база не открывается.

Почему это происходит

• 🧱 Обновление прошло не до конца. Конфигурацию обновили в Конфигураторе, но не запустили базу в режиме Предприятия. Там выполняются обработчики обновления данных — без них новые реквизиты пустые, а документы падают с ошибками.
• 🖥️ Разные версии платформы. На сервере 1С стоит одна сборка, на части клиентов — другая. Клиент с другим номером версии не подключится к серверу.
• 🧩 Расширение не подходит к новому релизу. Расширение ссылалось на реквизит или процедуру, которые разработчики переименовали. После обновления оно выдаёт ошибку при применении или в момент вызова своего кода.
• 📜 Пропущены промежуточные релизы. Типовые конфигурации требуют обновляться по цепочке. Файл обновления .cfu сам подскажет, с каких версий на него можно перейти.
• 🆕 Новая платформа, старая конфигурация. Релиз конфигурации рассчитан на определённую минимальную версию платформы. Если номер платформы ниже требуемого, конфигурация не запустится; если сильно выше — встречаются отличия в поведении.

Порядок безопасного обновления

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

Сбои СУБД и сети в клиент-серверной базе

В клиент-серверном варианте между пользователем и данными три звена: клиент, сервер 1С, СУБД (MS SQL или PostgreSQL). Ошибка может родиться на любом.

Сеть и сервер 1С

Клиент сначала обращается к агенту сервера (порт 1540), тот передаёт его менеджеру кластера (1541), а дальше работа идёт с рабочими процессами в диапазоне портов, который задан в свойствах рабочего сервера (по умолчанию 1560–1591). Если файрвол закрыл хотя бы один из этих портов, будет Сервер 1С:Предприятия не обнаружен или обрыв соединения.

Что проверить:

• 🌐 Доступен ли сервер по имени, а не только по IP. Имя сервера должно разрешаться у каждого клиента — иначе подключение срывается после первого обращения к агенту.
• 🔥 Открыты ли порты 1540, 1541 и диапазон рабочих процессов на файрволе сервера.
• 📶 Нет ли обрывов на VPN или Wi-Fi. Удалённые сотрудники через нестабильный канал получают Соединение разорвано чаще остальных.

Ошибки самой СУБД

• 💽 Кончилось место под файлы базы или журнал транзакций. MS SQL в полной модели восстановления без регулярного бэкапа журнала раздувает файл .ldf до размера диска.
• 🔑 Изменили пароль пользователя СУБД, а в параметрах базы на кластере остался старый.
• 🧮 Устарела статистика, индексы фрагментированы — запросы замедляются, растут блокировки. Регламентные задания обслуживания СУБД это исправляют.
• 🧷 Повреждение страниц данных после аварийного отключения питания. Признак — ошибки СУБД при чтении конкретной таблицы.

Файловая база по сети

Файловый вариант по сетевой папке — отдельный источник проблем. Обрыв сети в момент записи повреждает файл 1Cv8.1CD. При 5–10 одновременных пользователях файловая база по сети уже заметно тормозит, а блокировки в ней берутся на уровне таблиц целиком.

Ошибки в коде конфигурации и доработках

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

Типичные тексты и что за ними стоит

• ❌ Значение не является значением объектного типа — код обращается к реквизиту пустой ссылки. Например, в документе не заполнен контрагент, а обработка читает его ИНН.
• ❌ Поле объекта не обнаружено — реквизит удалили или переименовали при обновлении, а доработка его ищет.
• ❌ Индекс находится за границами диапазона — цикл перебирает коллекцию и удаляет из неё элементы прямым перебором.
• ❌ Деление на 0 — расчёт без проверки знаменателя, частый гость в самописных отчётах.
• ❌ Метод объекта не обнаружен — обработка написана под другую версию конфигурации.

Как локализовать

1. Откройте «Подробно…» и найдите путь {Модуль(строка)}.
2. Если путь ведёт во внешнюю обработку или расширение — отключите их и повторите действие.
3. Если ошибка в типовом модуле, проверьте, не снята ли конфигурация с поддержки. Изменённые типовые объекты — частая причина ошибок после обновления.
4. Для повторяемой ошибки включите в Конфигураторе Сервис → Параметры → Отладка (останов по ошибке) и пройдите сценарий в отладке — увидите значения переменных в момент сбоя.

Нехватка ресурсов и аппаратные сбои

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

Признаки

• 🧠 Память. Недостаточно памяти, аварийное завершение рабочего процесса rphost, перезапуск процессов в консоли кластера. Тяжёлый отчёт за год может съесть несколько гигабайт.
• 💾 Диск. На сервере 1С кончилось место — некуда писать временные файлы и сеансовые данные. На клиенте полный диск ломает кэш.
• 🔥 Процессор. Загрузка 100% часами — запросы встают в очередь, растут таймауты блокировок.
• ⚡ Железо. Битые сектора, перегрев, сбои ОЗУ. Признаки — Ошибка формата потока, Файл базы данных поврежден, ошибки, которые возникают без всякой системы.

Что сделать

1. Посмотрите журнал событий Windows (eventvwr.msc, разделы «Система» и «Приложение») на время сбоя: ошибки диска, падение служб, нехватка памяти.
2. В консоли кластера проверьте, не перезапускаются ли рабочие процессы. Пороги памяти задаются в свойствах рабочего сервера.
3. Проверьте свободное место на дисках сервера 1С, СУБД и в папке временных файлов.
4. Для дисков с подозрением на сбой — проверка SMART и chkdsk во время простоя.

Повреждённый файловый кэш на клиенте — отдельная мелкая причина. Странные ошибки интерфейса, которые есть у одного пользователя и нет у других, часто проходят после запуска с ключом /ClearCache или очистки папок кэша в %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Закройте 1С перед очисткой.

Как диагностировать ошибку в 1С: журналы, ТЖ, дампы

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

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="C:\v8logs" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
</config>

Здесь EXCP — исключения, TTIMEOUT — превышение времени ожидания блокировки, TDEADLOCK — взаимоблокировки. history="24" хранит логи 24 часа.

3. Дампы

При аварийном завершении платформа пишет дамп. На клиенте — в %APPDATA%\1C\1cv8\dumps. Сам дамп разбирает специалист или поддержка, но время его создания совпадает с моментом падения — по нему удобно искать событие в журналах.

4. Тестирование и исправление базы

Для подозрения на повреждение: Конфигуратор → Администрирование → Тестирование и исправление. Для файловой базы есть отдельная утилита chdbfl.exe в каталоге bin платформы — она проверяет физическую целостность файла 1Cv8.1CD.

Перед тестированием с исправлением сделайте резервную копию: режим «исправлять» может удалить битые ссылки и записи. Для запуска нужен монопольный доступ — все пользователи должны выйти из базы.

Что приложить, если обращаетесь к специалисту

• 📝 Полный текст ошибки из окна «Подробно…».
• ⏰ Точное время и имя пользователя.
• 🖥️ Версию платформы и релиз конфигурации (Справка → О программе).
• 🔄 Что менялось накануне: обновления, новые обработки, перенос сервера.

С таким набором специалист начинает разбор сразу, без лишних уточнений.

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