Сеанс 1С оборвался: ищем причину и снимаем зависшие блокировки

Чтобы узнать, кто аварийно завершил работу в 1С, откройте Администрирование → Обслуживание → Журнал регистрации и найдите сеанс, у которого есть событие «Сеанс. Начало», но нет «Сеанс. Завершение». Рядом будут пользователь, компьютер и время. Для клиент-серверной базы дальше смотрите консоль кластера, технологический журнал и дампы процессов.

Аварийное завершение редко бывает единичной бедой. За ним тянутся зависшие сеансы, занятые лицензии, «висящие» транзакции и сообщения вроде Конфликт блокировок при выполнении транзакции у тех, кто продолжает работать. Найти источник и убрать эти хвосты можно за 15–20 минут, если знать, куда смотреть.

Что происходит при аварийном завершении работы 1С

Когда пользователь закрывает программу штатно, клиент сообщает серверу о завершении сеанса. Сервер откатывает незавершённые транзакции, освобождает блокировки и лицензию. Журнал регистрации получает запись «Сеанс. Завершение».

При аварии этого обмена нет. Процесс 1cv8c.exe или 1cv8.exe падает, ноутбук уходит в сон, обрывается VPN или Wi-Fi. Сервер какое-то время считает сеанс живым.

Что остаётся после такого сбоя:

• 🔒 Управляемые блокировки открытой транзакции. Пока сервер не поймёт, что клиента нет, другие пользователи ждут и получают ошибку по таймауту.
• 🧾 Транзакция в СУБД. Если упал рабочий процесс сервера rphost, транзакции его соединений откатываются на стороне СУБД. Пока откат идёт, таблицы заняты.
• 🎫 Лицензия. Сеанс в консоли кластера продолжает её занимать.
• 📁 Файл блокировки в файловой базе. Если процесс завис, а не умер, ОС держит файл 1Cv8.1CD открытым.

Кто может быть «виновником»

Под фразой «кто аварийно завершил работу» обычно скрываются три разных ситуации:

Если упали сразу десять человек — ищите не пользователя, а процесс сервера или сеть.

Как найти виновника по журналу регистрации

Журнал регистрации — первый и самый доступный источник. Он есть и в файловой, и в клиент-серверной базе.

1. Откройте Администрирование → Обслуживание → Журнал регистрации (БП 3.0, ЗУП 3.1, УТ 11). В Конфигураторе тот же журнал — в меню Администрирование → Журнал регистрации.
2. Нажмите Установить отбор. Задайте интервал: 15–30 минут до момента, когда начались жалобы.
3. В отборе по событиям оставьте группу «Сеанс» и «Транзакция».
4. Отсортируйте список по номеру сеанса или пользователю.
5. Ищите сеанс с «Сеанс. Начало», но без «Сеанс. Завершение» за тот же день.

Признаки, на которые стоит смотреть

• ⏱ Последняя запись сеанса — «Транзакция. Начало», а фиксации или отмены после неё нет. Этот пользователь проводил документ или выполнял обработку в момент сбоя.
• 🔁 Через минуту тот же пользователь заходит снова под новым номером сеанса. Классика: окно упало, человек перезапустил программу.
• 🖥 Несколько пользователей с разных компьютеров теряют сеансы в одну и ту же секунду. Это уже сервер или сеть.

Журнал Windows как подтверждение

На компьютере пользователя откройте Просмотр событий → Журналы Windows → Приложение. Отфильтруйте по уровню «Ошибка» и источнику Application Error. Запись с именем модуля 1cv8c.exe или 1cv8.exe в нужное время подтверждает падение клиента.

На сервере то же самое ищите по rphost.exe, rmngr.exe и ragent.exe. Падение rphost.exe объясняет массовые обрывы.

Сеансы и блокировки в консоли кластера серверов

Для клиент-серверной базы основной инструмент — Консоль администрирования серверов 1С.

1. Откройте консоль и разверните узел Кластеры → <ваш кластер> → Информационные базы → <база>.
2. Перейдите в узел Сеансы. Отсортируйте по «Последней активности».
3. Сеанс без активности десятки минут, с компьютера, где пользователь уже вышел, — кандидат на зависший.
4. Узел Блокировки покажет, какие объекты держит сеанс.
5. Узел Соединения покажет, привязан ли сеанс к живому соединению и какому рабочему процессу.

То же доступно из командной строки через rac. Сначала узнайте идентификаторы кластера и базы:

rac cluster list
rac infobase summary list --cluster=<uuid_кластера>
rac session list --cluster=<uuid_кластера> --infobase=<uuid_базы>
rac lock list --cluster=<uuid_кластера>

Точный набор параметров для вашей версии платформы смотрите в rac help session и rac help lock.

Как завершить зависший сеанс

В консоли — правая кнопка мыши на сеансе, команда удаления (завершения) сеанса. Через rac — подкоманда session terminate с идентификатором сеанса.

Если сеанс не завершается и висит дальше, проблема глубже — в рабочем процессе. Перезапуск rphost или службы «Агент сервера 1С:Предприятия» обрывает сеансы всех пользователей кластера. Делайте это вне рабочего времени или после общего предупреждения.

Технологический журнал, дампы и блокировки СУБД

Журнал регистрации говорит «кто и когда». Технологический журнал и дампы говорят «почему».

Настройка logcfg.xml

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

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <dump create="true" location="D:\1C_dumps" type="3"/>
  <log location="D:\1C_techlog" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="PROC"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <property name="all"/>
  </log>
</config>

Что ловят эти события:

• 🧨 EXCP — исключения, в том числе те, что предшествуют падению процесса.
• ⚙️ PROC — старт и завершение процессов сервера. Видно, когда rphost перезапустился.
• 🔐 TDEADLOCK — взаимоблокировки управляемых блокировок.
• ⏳ TTIMEOUT — превышение времени ожидания блокировки. Тут видно, чья транзакция держала ресурс.

history="24" хранит логи 24 часа. Не включайте property name="all" для всех событий надолго — на загруженном сервере техжурнал за час съедает гигабайты.

Где смотреть дампы

Дампы .mdmp падают в каталог из параметра location. Имя файла содержит имя процесса и время. Сам дамп разбирать нужно отладчиком, но для диагностики хватает факта: время падения, процесс, версия платформы. С этим уже можно идти к партнёру или в поддержку.

Блокировки на уровне СУБД

Если в 1С сеанса уже нет, а таблицы всё равно заняты — смотрите саму СУБД.

Microsoft SQL Server, кто кого блокирует:

SELECT session_id, blocking_session_id, wait_type, wait_time, status
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

PostgreSQL, «зависшие» транзакции и цепочки блокировок:

SELECT pid, usename, state, xact_start, pg_blocking_pids(pid) AS blocked_by
FROM pg_stat_activity
WHERE state = 'idle in transaction' OR cardinality(pg_blocking_pids(pid)) > 0;

Файловая база: «занята» после аварии

В файловом варианте нет кластера и консоли. Зато есть типовой симптом: все вышли, а база не даёт монопольный доступ для обновления.

Как проверить:

1. На компьютере, где лежит база, откройте Управление компьютером → Общие папки → Открытые файлы.
2. Найдите 1Cv8.1CD и посмотрите, с какого пользователя и компьютера он открыт.
3. Попросите этого пользователя закрыть 1С. Если окна у него нет — завершите процесс 1cv8c.exe или 1cv8.exe в диспетчере задач на его машине.
4. Если не помогло, закройте открытый файл на сервере той же командой из «Открытых файлов».

После серии аварий файловую базу стоит проверить. Сделайте копию каталога базы, затем запустите Конфигуратор → Администрирование → Тестирование и исправление либо утилиту chdbfl.exe из каталога bin платформы. Обоим режимам нужен монопольный доступ.

Сеть и оборудование как причина обрывов

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

• Соединение с сервером 1С:Предприятия разорвано
• Сеанс отсутствует или удален
• Сеанс работы завершен администратором — это не сбой, а ручное или автоматическое завершение из консоли.

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

• 🌐 Порты. Клиент обращается к агенту сервера на 1540, затем к менеджеру кластера на 1541 и к рабочим процессам из диапазона, заданного в свойствах рабочего сервера (по умолчанию 1560–1591). Если межсетевой экран режет часть диапазона, сеансы рвутся при переключении на новый процесс.
• 📶 Wi-Fi и VPN. Короткий обрыв на 10–20 секунд для браузера незаметен, а соединение 1С падает.
• 💤 Энергосбережение. Сон ноутбука или отключение сетевой карты для экономии энергии рвут соединение. Отключите это в свойствах адаптера.
• 🛡 Антивирус и DPI. Проверка трафика и файлов базы в реальном времени даёт задержки и разрывы. Добавьте каталоги базы и сервера 1С в исключения по согласованию с безопасниками.
• 🔌 Питание. Сервер без ИБП после скачка напряжения — прямой путь к повреждению базы.

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

Профилактика: настройки кластера и порядок работы

Полностью исключить аварии нельзя. Можно сделать так, чтобы они не тянули за собой всех остальных.

Настройки кластера

В свойствах кластера в консоли есть параметры перезапуска рабочих процессов:

• Интервал перезапуска — плановый перезапуск rphost раз в N секунд. Значение 86400 — раз в сутки. Процесс перезапускается без обрыва сеансов: новые соединения уходят в новый процесс, старый доживает.
• Допустимый объём памяти и интервал превышения допустимого объёма памяти — если процесс долго превышает лимит, кластер выводит его из работы. Это защищает от падения из-за утечки памяти.
• Выключенные процессы останавливать через — сколько ждать, прежде чем принудительно остановить старый процесс. 0 означает «не останавливать принудительно».

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

Порядок работы

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

Если обрывы продолжаются

Когда журнал и техжурнал показывают падения, а очевидной причины нет, сузьте круг:

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

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