Как исправить ошибку 10054 «Удаленный хост разорвал соединение» и аварийное завершение rphost в 1С

← На главную

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

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

Шаг 1. Анализ причин ошибки и поиск аварийных дампов

Разберем основные причины, из-за которых сокет закрывается с кодом 10054:

Аварийное завершение процесса rphost: Если рабочий процесс сервера 1С «падает» из-за внутренней ошибки или повреждения данных, СУБД и клиентские сеансы мгновенно теряют связь с сервером.
Сбои при динамическом обновлении: Некорректно примененное динамическое обновление (особенно при активных сеансах или выполняющихся фоновых заданиях) вызывает критическое исключение при попытке считывания данных конфигурации.
Проблемы сетевой инфраструктуры виртуализации: Включение опций сетевой разгрузки (Large Send Offload (LSO), TCP Chimney Offload) на сетевых адаптерах Hyper-V или VMware часто приводит к спонтанным сбросам TCP-соединений. Также причиной может быть неправильная работа IPv6 при отсутствии соответствующей записи в DNS.
Повреждение файла журнала регистрации: В некоторых случаях критический завис или сбой происходит из-за повреждения файла журнала регистрации (особенно нового формата SQLite).

Выясним, создаются ли на сервере файлы аварийных дампов. По умолчанию они сохраняются в системных каталогах или папке службы 1С с расширением .mdmp. Если дампы с именем вида rphost_*.mdmp генерируются регулярно, значит, рабочий процесс действительно падает из-за необработанного исключения.

Шаг 2. Настройка технологического журнала для диагностики

Чтобы точно узнать, на каком действии или событии падает сервер, настроим технологический журнал. Создадим файл logcfg.xml в каталоге параметров платформы (например, C:\Program Files (x86)\1cv8\conf\logcfg.xml).

Рассмотрим пример правильного файла конфигурации ТЖ для сбора информации об исключениях (excp), вызовах серверных функций (CALL) и контексте сетевых вызовов (SCALL):


<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <dump type="3" location="C:\_1C\DUMPS" create="true"/>
  <log location="C:\_1C\LOG" history="72">
    <property name="all"/>
    <event>
      <eq value="excp" property="name"/>
    </event>
    <event>
      <eq value="CALL" property="name"/>
    </event>
    <event>
      <eq value="SCALL" property="name"/>
    </event>
  </log>
</config>

Проанализируем полученные логи ТЖ. Если в журнале присутствуют записи со следующими ошибками:


EXCP,4,process=rphost,p:processName=trade,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="Файл не обнаружен 'v8srvr://1cs1/trade/Files/SprScndInfo'"
...
EXCPCNTX,3,SrcName=DBMSSQL,Sql="{call sp_executesql(N'SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Config WHERE FileName = P1 ORDER BY PartNo', N'P1 nvarchar(128)', N'DynamicallyUpdated')}"

Это прямо указывает на то, что процесс rphost падает при старте фонового задания (BackgroundJob) из-за поврежденного динамического обновления информационной базы.

Шаг 3. Отключение регламентных заданий через файл конфигурации кластера

Если база данных вылетает сразу при подключении, доступе к свойствам через консоль кластера или попытке входа в Конфигуратор, отключим выполнение регламентных заданий вручную.

Остановим службу сервера 1С:Предприятие (1C:Enterprise 8.3 Server Agent).
Откроем файл конфигурации кластера 1CV8Clst.lst, находящийся в каталоге служебных данных сервера (по умолчанию C:\Program Files\1cv8\srvinfo\reg_1541\).
Найдем строку нужной информационной базы. Фрагмент описания со значением 0 после списка дат означает, что фоновые задания включены: {0,00010101000000,00010101000000,"","",""},0,1,"",0,"","",1365},
Изменим значение флага на 1, чтобы блокировать выполнение регламентных заданий: {0,00010101000000,00010101000000,"","",""},1,1,"",0,"","",1365},
Запустим службу сервера 1С. Теперь регламентные задания не будут автоматически стартовать при запуске процесса и обрушивать rphost.

Шаг 4. Очистка следов некорректного динамического обновления в СУБД

Основной источник падений при старте сеанса или проведении документов после «живого» обновления — застрявшие временные таблицы конфигурации в Microsoft SQL Server. Удалим служебные записи из базы данных напрямую через SQL Management Studio.

Важно: Перед выполнением любых DML-запросов обязательно создайте полную резервную копию базы данных SQL!

Проверим наличие записей динамического обновления в таблицах Config и ConfigSaver:


SELECT * FROM Config WHERE FileName LIKE '%dyn%';
SELECT * FROM ConfigSaver;

Если записи найдены, очистим их следующими командами:


DELETE FROM Config WHERE FileName LIKE '%dyn%';
DELETE FROM Config WHERE FileName = 'DynamicallyUpdated';
DELETE FROM ConfigSaver;

После удаления этих записей очистите кэш сервера 1С (удалите содержимое папок временных файлов в каталоге srvinfo) и перезапустите сервер 1С.

Шаг 5. Решение ошибки падения backend.dll (0xc0000005) при входе пользователей

Если после очистки динамического обновления Конфигуратор запускается, но при попытке входа в режиме «1С:Предприятие» приложение вылетает с ошибкой модуля backend.dll (код исключения 0xc0000005), это свидетельствует о нарушении целостности пользователей или таблицы параметров.

Разберем алгоритм исправления этого сбоя:

Удаление таблицы пользователей и сброс настроек авторизации: Простого очищения таблицы v8users недостаточно. Информация о пользователях также дублируется в системной таблице Params. Выполним в SQL запуск запроса:
```
DELETE FROM Params WHERE FileName = 'usrdef';
TRUNCATE TABLE v8users;
```
Это позволит войти в базу под администратором без пароля.
Подмена таблицы конфигурации из эталонной базы: Если таблица Config повреждена настолько, что тестирование и исправление базы вызывает сбой, восстановим структуру следующим образом:
- Создадим новую пустую базу данных на том же релизе платформы и конфигурации.
- Скопируем содержимое таблицы Config из новой пустой базы в поврежденную.
- Зайдем в Конфигуратор и выполним обновление конфигурации базы данных (клавиша F7). П랫폼a пересопоставит объекты метаданных с имеющимися таблицами SQL.
- Загрузим актуальный файл конфигурации .cf и повторно выполним обновление.

Шаг 6. Сопоставление имен таблиц SQL с метаданными 1С

При тестировании и исправлении база может выдавать ошибку на конкретной таблице (например, региона сведений вида _InfoRg...). Для поиска и устранения повреждений конкретной таблицы необходимо узнать её физическое имя в СУБД.

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

СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();

Если база не запускается вовсе, структуру хранения можно проанализировать через таблицы DBSchema (хранящуюся внутри Config) или сопоставить имена с помощью специальных утилит чтения метаданных.

Выполнение описанного комплекса мер позволяет полностью устранить ошибку 10054, восстановить работоспособность сервера 1С и вернуть информационные базы в штатный режим работы.