Ошибка выгрузки 1С 2026: причины, диагностика и решение без программиста

Бухгалтер запускает обмен УТ→БП в 17:30 — окно «Обмен данными прерван» или «Конфликт блокировок при выполнении транзакции». До закрытия дня — час, документы реализации зависли в очереди, а в журнале только короткая строка без понятного плана действий. В 2026 году такую ошибку нельзя диагностировать по одному всплывающему сообщению: у выгрузки 1С есть минимум три слоя — данные, транспорт сообщения и серверная инфраструктура. Ниже — практичный порядок проверки, который мы используем перед тем, как править код обмена или обновлять платформу.

Ключевые факты

• Платформа 1С строит обмен через планы обмена, сообщения и службу регистрации изменений: в очереди хранятся изменённые объекты, которые должны уйти конкретному узлу. Поэтому «ошибка выгрузки» часто означает не один сбой, а остановку очереди на первом проблемном объекте.
• Если ошибка связана с XML-сообщением РИБ, сначала проверяют чтение/запись файла, корректность узла и целостность сообщения. Это отдельно описано в методических материалах ИТС по ошибкам обмена в распределённой информационной базе.
• Конфликт блокировок диагностируется по технологическому журналу. В релизных материалах 1С для платформы указаны события TDEADLOCK и TTIMEOUT, а для TLOCK — свойства Regions, Locks и WaitConnections; именно они помогают отличить «документ не провёлся» от блокировки на регистре.
• NetDataExchangeException 10054 сам по себе не доказывает одну конкретную ошибку платформы. Это сигнал, что соединение было разорвано принимающей стороной или потеряна связь с процессом; рядом нужно смотреть EXCP, перезапуск rphost, сетевые события и дампы.
• Полнотекстовый индекс ППД действительно может влиять на сервер 1С: официальный механизм опирается на полнотекстовый индекс, а практические разборы показывают симптомы вроде регулярного перезапуска rphost.exe, роста временных файлов и памяти. Но это гипотеза после проверки журналов, а не универсальная причина любой выгрузки.
• Уменьшение размера порции обмена помогает только там, где ошибка воспроизводится на больших пакетах или долгих транзакциях. Если падает один документ из-за незаполненного реквизита, размер пакета проблему не решит.

Практическая диагностика на живом обмене

В нашей практике самый полезный первый артефакт — не скриншот окна ошибки, а короткая связка из четырёх фактов: время сбоя, узел обмена, первый проблемный объект и соседние записи журнала. На одном ночном обмене ЗУП→БП очередь останавливалась на документе начисления нового сотрудника: в интерфейсе было только «обмен не выполнен», а в журнале регистрации рядом с временем регламентного задания была причина отказа — не заполнена аналитика для проводки. Код обмена трогать не пришлось: исправили реквизит, повторили отправку и отдельно добавили Telegram-алёрт с именем документа.

Минимальный набор, который мы просим перед удалённой диагностикой:

1. Скрин точного сообщения и время с точностью до минуты.
2. Название направления обмена: УТ→БП, ЗУП→БП, РИБ, КД2/КД3, HTTP-сервис, COM или файловая выгрузка.
3. Журнал регистрации за интервал ±10 минут с отбором по важности «Ошибка» и регламентному заданию обмена.
4. Для клиент-серверной базы — фрагмент технологического журнала с EXCP, TLOCK, TTIMEOUT, TDEADLOCK за тот же интервал.
5. Размер файла/пакета обмена, свободное место на диске и путь, куда пишется выгрузка.

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

Риски и признаки по типам ошибок

Сравнение способов решения

Чек-лист диагностики «обмен упал» (10 шагов)

1. Точный текст ошибки. Зафиксируйте: «Обмен данными прерван», «Конфликт блокировок при выполнении транзакции», «Ошибка формата потока», «На сервере произошла неисправимая ошибка», «Объект уже существует» — это пять разных диагнозов. Скриншот с текстом обязателен, иначе диагностика превращается в гадание.
2. Журнал регистрации в момент сбоя. Все функции → Стандартные → Журнал регистрации → отбор по времени ±5 минут от ошибки → колонка «Важность» = «Ошибка». Здесь будет имя документа, пользователь, метаданные. В РИБ/КД2 события синхронизации помечены пиктограммами «обмен не прошёл» (транспорт) и «предупреждение» (данные) — это разные ветки решения.
3. Регистрация изменений по узлу. В типовых конфигурациях это может быть отдельная форма состава отправляемых данных, а на уровне платформы — таблицы регистрации изменений плана обмена. Найдите проблемный узел и объект. Удалять запись регистрации можно только осознанно: сама запись уйдёт из очереди, но объект после этого не будет отправлен в этом цикле обмена.
4. Технологический журнал (если клиент-серверная база). В logcfg.xml включить события EXCP, TLOCK, TTIMEOUT, TDEADLOCK. После повтора ошибки в каталоге журналов искать *.log за нужную минуту. По WaitConnections из TLOCK/TTIMEOUT ищут соединение, которое участвовало в ожидании; если рядом есть SDBL, сопоставляют t:connectID и длительность транзакции.
5. Очередь сообщений обмена. Для УТ↔БП/КД3: Администрирование → Синхронизация данных → Состав отправляемых данных. Если объект «застрял» — кнопка «Все ещё неотправлено» покажет реальное содержимое очереди. Часто оказывается, что обмен и не пытался дойти — он остановился на первом отказе.
6. Кэш платформы. Закрыть 1С → удалить %APPDATA%\1C\1cv8\<GUID>\ и %LOCALAPPDATA%\1C\1cv8\<GUID>\. Кэш пересоберётся за минуту, ошибки СУБД с временными таблицами #tt2, #tt3 обычно уходят.
7. Дампы rphost. Каталог дампов зависит от настроек технологического журнала и кластера; в документации 1С отдельно описано, что техжурнал может сохранять минимальные дампы при аварийном завершении. Если дампы появляются в одно и то же время, сопоставьте их с обменом и регламентными заданиями.
8. Проверка версии платформы. В клиенте: Сервис → О программе. Обновление имеет смысл не «на всякий случай», а когда ваш релиз старый, ошибка воспроизводится и в changelog/поддержке есть исправление по похожему сценарию. Перед обновлением — копия базы и тестовый прогон обмена.
9. Размер пакета обмена. В настройках узла обмена проверьте количество элементов в транзакции отправки. При тяжёлых документах уменьшайте порцию постепенно: например, с 1000 до 300, затем до 100–200, если таймауты сохраняются.
10. Тестирование и исправление. Конфигуратор → Администрирование → Тестирование и исправление. Все галочки кроме «Реструктуризация таблиц», режим «Тестирование и исправление». На базе 5 ГБ — 30–90 минут. Перед запуском — обязательно .dt-выгрузка.

Типичные сценарии и точечные решения

Сценарий 1. «Конфликт блокировок при выполнении транзакции» при обмене УТ↔БП. В техжурнале ищется TTIMEOUT или длинный TLOCK с полями Regions, Locks, WaitConnections. По ним видно, на каком пространстве блокировок обмен ждал ресурс и какой контекст был у операции. Первые безопасные меры — разнести обмен и массовое проведение по расписанию, уменьшить порцию отправки, затем уже смотреть запросы и обработчики проведения.

Сценарий 2. «Обмен данными прерван» — упал на конкретном документе. Журнал регистрации показывает прикладную причину: не хватает остатка, дата запрета, не заполнен договор, нет права на запись, реквизит не найден по соответствию. Решение — исправить данные и повторить обмен. Снимать регистрацию объекта стоит только после сверки: если документ есть только в источнике, он не попадёт в приёмник.

Сценарий 3. rphost.exe падает каждые 20–40 минут. Симптом: в консоли кластера серверов видно, что PID rphost меняется, рядом с обменом появляются EXCP и дампы, в %TEMP% быстро растут временные файлы. Один из проверяемых вариантов — проблема с полнотекстовым индексом ППД. Решение: в окно обслуживания сделать резервную копию, очистить и обновить индекс, затем сутки наблюдать за регламентными заданиями ППД и обменом.

Сценарий 4. «На сервере произошла неисправимая ошибка» при печати/сохранении документа со штрихкодом. Такой текст сам по себе не указывает на обмен. Сначала нужно понять, совпадает ли сбой по времени с выгрузкой, печатью, внешней компонентой или фоновым заданием. Если в техжурнале рядом только EXCP и дамп без TLOCK/TTIMEOUT, диагностика уходит в анализ процесса и внешних компонент, а не в правила обмена.

Сценарий 5. Обмен через COM-соединение разрывается с NetDataExchangeException 10054. Это не диагноз, а симптом разрыва соединения. Проверьте, не перезапустился ли rphost, нет ли сетевого разрыва, не завершилось ли внешнее приложение, которое держит COM-соединение. Если ошибка повторяется только на одном релизе платформы, следующий шаг — проверка changelog и тест на актуальном релизе в копии базы.

Сценарий 6. «Ошибка формата потока» при загрузке .dt/обмене XML. Чаще всего проверяют не базу, а файл и путь доставки: хватает ли места, не пишет ли выгрузка на нестабильный UNC-путь, не заблокировал ли файл антивирус, открывается ли XML/ZIP локально. Если повторная локальная выгрузка проходит, причина была в транспорте или файловой системе.

Как Синхрон1С предотвращает повторение

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

• размер регистра «Зарегистрированные изменения» по каждому узлу обмена → алёрт «очередь УТ→БП растёт, последний успешный обмен 3 часа назад»;
• наличие EXCP/TTIMEOUT/TDEADLOCK в техжурнале за последний интервал → алёрт с расшифровкой WaitConnections и именем проблемного объекта;
• результаты последних регламентных заданий (Обмен данными, Полнотекстовое индексирование) → алёрт при ошибке выполнения;
• свежие .mdmp в каталоге дампов → алёрт «упал rphost, адрес ошибки 0x...» с группировкой по одинаковым адресам;
• свободное место на диске под tempdb/PostgreSQL и под каталогом обмена.

Связь — через стандартные веб-сервисы 1С либо ComConnector, конфигурация не правится.

Telegram-бот Синхрон1С — мониторинг очереди обмена и алёрты по падениям rphost.

Часто задаваемые вопросы

Где в 1С посмотреть, какой именно документ оборвал обмен? Начните с журнала регистрации: отбор по времени сбоя, важности «Ошибка» и регламентному заданию обмена. Если ошибка прикладная, там обычно видны объект, пользователь и причина отказа. Затем откройте состав отправляемых данных или регистрацию изменений по нужному узлу, чтобы понять, что осталось в очереди.

Что значит TTIMEOUT и как найти виновника? Это таймаут ожидания блокировки в технологическом журнале сервера 1С. Смотрите TLOCK/TTIMEOUT, поля Regions, Locks, WaitConnections и контекст. По WaitConnections можно искать связанное соединение и понять, какая операция мешала обмену, но иногда нужен полный интервал журнала, а не одна строка.

Можно ли снять регистрацию документа в очереди обмена без последствий? Это допустимо только после сверки. Сама запись регистрации изменений не является документом, но её удаление означает, что конкретное изменение не будет отправлено в текущей очереди. Если объект ещё не попал в приёмник, вы получите расхождение баз.

Почему rphost.exe падает каждые 30 минут? Вариантов несколько: регламентное задание, внешняя компонента, сетевой разрыв, ошибка платформы, нехватка памяти, проблема ППД. Проверьте, совпадает ли время падения с обменом и заданиями полнотекстового индексирования, затем смотрите дампы и соседние EXCP.

Стоит ли обновлять платформу 1С только из-за обменов? Стоит, если ошибка воспроизводится, ваш релиз заметно устарел или в описании обновлений есть исправление похожего сбоя. Но обновление не заменяет диагностику данных: документ с незаполненным реквизитом не начнёт проводиться только из-за новой платформы.

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

Почему обмен проходит вручную, но падает ночью? Ночью часто одновременно запускаются закрытие месяца, обновление индекса ППД, резервное копирование, обмен с сайтом и выгрузка в бухгалтерию. Проверьте расписание регламентных заданий и системных задач Windows/Linux: ручной запуск днём может не попадать в конфликт блокировок или нехватку ресурсов.

Что отправить специалисту, чтобы не тратить первый час на уточнения? Время ошибки, направление обмена, файл правил/версию конфигураций, журнал регистрации за ±10 минут, фрагмент технологического журнала и пример объекта, который не ушёл. Если есть rphost_*.mdmp, укажите путь и время создания, сам файл можно передать отдельно.

Смотрите также

• Ошибка доступа к файлу 1С — 1Cv8.1CD, handle.exe, NTFS-права
• 1С ошибка базы данных — диагностика и восстановление повреждённых баз
• Регламентные задания 1С: настройка и диагностика
• Мониторинг 1С в Telegram — автоматические уведомления о сбоях
• Резервное копирование базы 1С

Стоимость интеграции — 30 000 ₽ за проект, включая настройку мониторинга очередей обмена, парсинга техжурнала и алёртов по чек-листу выше. Напишите в Telegram: @onoutnoxon.

Подробнее о возможностях — на странице Синхрон1С.

Источники:

• Обмен данными — платформа 1С:Предприятие: https://v8.1c.ru/platforma/obmen-dannymi/
• План обмена — платформа 1С:Предприятие: https://v8.1c.ru/platforma/plan-obmena/
• Служба регистрации изменений — платформа 1С:Предприятие: https://v8.1c.ru/platforma/sluzhba-registratsii-izmeneniy/
• Технологический журнал — платформа 1С:Предприятие: https://v8.1c.ru/platforma/tehnologicheskiy-zhurnal/
• Описание обновления 1С:Предприятие 8.2.16 — события TDEADLOCK, TTIMEOUT, свойства TLOCK: https://downloads.v8.1c.ru/content/Platform/8_2_16_352/1cv8upd.htm
• Методика ИТС по ожиданиям на блокировках и WaitConnections: https://its.1c.ru/db/content/metod8dev/src/developers/scalability/troubleshooting/i8106006.htm
• Обработка ошибок при обмене данными в распределенной информационной базе — ИТС 1С: https://its.1c.ru/db/content/metod8dev/src/developers/platform/metod/dataexchange/i8102265.htm
• Полнотекстовый поиск — платформа 1С:Предприятие: https://v8.1c.ru/platforma/polnotekstovyy-poisk/
• Таймаут при ожидании блокировки — 1C База знаний: https://1c-bz.ru/performance/626/
• Расследование конфликтов управляемых блокировок TTIMEOUT — 1s-on.ru: https://1s-on.ru/chto-takoe-ttimeout-1spredpriyatiya-i-kak-ego-najti/
• Практический разбор падения rphost.exe из-за индекса ППД — adminotes.ru: https://adminotes.ru/resheno-protsess-1s-rphost-zavershaetsya-iz-za-indeksa-ppd/

Для статьи использован AI-ассистент для структуры и первичного поиска источников; фактические утверждения сверены с документацией 1С, ИТС и практическими разборами технологического журнала. Неподтверждённые проценты и привязка NetDataExchangeException 10054 к одной конкретной ошибке платформы удалены. Финальную редактуру выполнил Александр Руин, основатель habab.ru. Обновлено: 2026-05-04.