Как завершить подвисшие сеансы 1С 8.3 при ошибке «Ошибка формата потока»?

В процессе эксплуатации клиент-серверного варианта 1С:Предприятие 8.3 администраторы иногда сталкиваются со сложной ситуацией: в консоли администрирования серверов зависают активные сеансы пользователей, которые не удается принудительно завершить. При попытке удалить такую сессию штатным способом система выдает ошибку: «Ошибка удаления сеанса: Ошибка операции администрирования Ошибка формата потока».

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

Выясним причину: почему сеансы восстанавливаются после перезапуска?

Рассмотрев архитектуру работы кластера 1С:Предприятие 8.3, можно выделить ключевые факторы, из-за которых сеансы становятся «неубиваемыми»:

1. Хранение сеансовых данных на диске: Начиная с платформы 8.3, информация о текущих сеансах и их состоянии сохраняется во временных файлах сеансового кэша вида snccntx* в каталоге реестра кластера (по умолчанию путь к ним выглядит как C:\Program Files\1cv8\srvinfo\reg_1541\...). При перезапуске службы менеджер кластера rmngr считывает данные из этих файлов и автоматически восстанавливает все незавершенные сессии.
2. Бесполезность завершения соединений в СУБД: Принудительное удаление процессов или соединений через Монитор активности MSSQL (Activity Monitor) не даёт результата. Таблица сеансов и внутренние блокировки 1С ведутся в оперативной памяти процессов 1С и служебных файлах кластера, а не в базе данных SQL. При удалении соединения со стороны MSSQL сервер 1С просто пытается переподключиться.
3. Сбой десериализации данных: Ошибка «Ошибка формата потока» в графической консоли MMC возникает из-за повреждения структуры данных внутри файлов сеансов или сбоя обработки исключений при нештатном обрыве связи. Графическая оснастка теряет возможность корректно передать команду завершения сеанса менеджеру кластера.

Решение 1. Полная очистка сеансового кэша сервера 1С

Для гарантированного удаления зависших сессий необходимо очистить файлы данных сеансов snccntx при полностью остановленной службе сервера 1С. Разберем порядок действий по шагам:

1. Остановим службу сервера 1С:Предприятие. Откроем оснастку управления службами (services.msc) и остановим службу агента сервера (например, 1C:Enterprise 8.3 Server Agent).
2. Проверим отсутствие оставшихся процессов. Откроем Диспетчер задач или командную строку и убедимся, что процессы rphost.exe, rmngr.exe и ragent.exe полностью завершены. Если процессы продолжают висеть в памяти, их необходимо завершить принудительно:
   Скопировать код

   
   taskkill /T /F /IM rphost.exe
   taskkill /T /F /IM rmngr.exe
   

3. Удалим файлы сеансового кэша. Перейдем в каталог данных кластера серверов 1С (обычно это C:\Program Files\1cv8\srvinfo\reg_1541\) и найдем файлы, имя которых начинается на snccntx. Удалим данные файлы, а также очистим папку временных файлов пользователя, под которым запускается служба 1С.
4. Запустим службу сервера 1С. После запуска службы кластер сформирует новые файлы сеансов, а зависшие «фантомные» сессии окончательно исчезнут.

Автоматизация очистки кэша с помощью командного файла

Чтобы ускорить процесс выполнения этой процедуры в будущем, разберем пример командного скрипта (BAT-файла). Он автоматически останавливает службу, завершает зависшие процессы, очищает временные файлы сеансов и запускает службу заново:

set log=C:\scripts\1C_server_restart.log
echo Begin restart 1C:Server %date% %time% >> %log%

net stop "1C:Enterprise 8.3 Server Agent (x86-64)" >> %log%
ping 127.0.0.1 -n 15 >> NUL

taskkill /T /F /IM rphost.exe >> %log%
taskkill /T /F /IM rmngr.exe >> %log%

del /F /Q "C:\Program Files\1cv8\srvinfo\reg_1541\snccntx*" >> %log%
del /F /Q "C:\Users\USR1CV8\AppData\Local\Temp\*.*" >> %log%

net start "1C:Enterprise 8.3 Server Agent (x86-64)" >> %log%
echo End restart 1C:Server %date% %time% >> %log%

Решение 2. Точечное завершение рабочего процесса rphost tanpa остановки кластера

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

1. В консоли администрирования кластера откроем ветку «Сеансы» и определим, на каком именно рабочем процессе (PID процесса rphost.exe) висит проблемный сеанс.
2. Запустим Диспетчер задач или командную строку на сервере приложений 1С.
3. Принудительно завершим только тот процесс rphost.exe, PID которого соответствует зависшему сеансу: taskkill /PID <Идентификатор_PID> /F

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

Решение 3. Использование утилиты командной строки RAC

Если графическая консоль MMC вылетает с ошибкой формата потока, обратимся к консольной утилите rac (Remote Admin Console), которая работает через службу ras (Remote Admin Service). Команды, отправляемые через rac, обращаются к менеджеру кластера напрямую, минуя графический интерфейс:

1. Получим список всех сеансов информационной базы через команду: rac session --cluster=<ID_кластера> list --ib-name=<Имя_Базы>
2. Найдем идентификатор зависшего сеанса (параметр session) и выполним команду его завершения: rac session --cluster=<ID_кластера> terminate --session=<ID_сеанса>

Профилактика: настройка параметров кластера

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

• Время завершения спящих сеансов: В свойствах информационной базы или кластера укажем таймаут завершения спящих сеансов (например, 1200–3600 секунд). По истечении этого времени система будет автоматически удалять неактивные соединения.
• Интервал перезапуска рабочих процессов: В свойствах кластера зададим интервал перезапуска рабочих процессов rphost.exe (например, 86400 секунд — раз в сутки) или ограничение по объему виртуальной памяти. Это позволит регулярно обновлять рабочие процессы в автоматическом режиме без накопления «мусорных» данных в памяти.