Сеанс пользователя 1С глазами администратора: просмотр, отладка, блокировки

Подключиться к сеансу пользователя в 1С можно тремя способами, и каждый решает свою задачу. Посмотреть, кто работает и что делает сеанс, — через консоль кластера или утилиту rac. Увидеть экран пользователя — средствами Windows, теневым подключением к RDP-сессии. Пройти код по шагам в его сеансе — отладчиком Конфигуратора по протоколу HTTP.

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

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

Каждому способу нужен свой уровень доступа. Чаще всего администратор упирается не в 1С, а в права на сервере.

🔧 Что проверить заранее:

• 🔑 Учётную запись администратора кластера: без неё консоль покажет список кластеров, но не пустит дальше.
• 🧩 В типовых конфигурациях на БСП права раздаются через группы доступа. Пользователь с профилем «Администратор» видит обработку активных пользователей и может завершать сеансы из интерфейса.
• 🖥 Для теневого RDP в групповой политике Windows должно быть разрешено удалённое управление сеансами. Политика называется «Установить правила удалённого управления для пользовательских сеансов служб удалённых рабочих столов».

Где посмотреть сеансы пользователей прямо в 1С

Самый быстрый способ — без внешних утилит.

В режиме 1С:Предприятие

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) откройте Администрирование → Обслуживание и найдите ссылку «Активные пользователи». Обработка показывает:

• 👤 пользователя и компьютер;
• 🕐 начало сеанса;
• 🧾 приложение — тонкий клиент, веб-клиент, фоновое задание, COM-соединение;
• 🔢 номер сеанса.

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

Двойной клик по строке открывает журнал регистрации с отбором по этому сеансу. Это первый шаг при любом вопросе «что он там делает»: видно, какие документы пользователь открывал и записывал последние минуты.

В Конфигураторе

Меню Администрирование → Активные пользователи. Список тот же, но без журнала по клику. Удобно, когда нужно понять, кто держит базу перед обновлением.

Подключение к сеансу через консоль кластера и утилиту rac

Консоль кластера даёт больше, чем список в базе: память сеанса, текущий вызов, время в СУБД и ожидание блокировок.

Консоль администрирования серверов

1. Запустите «Администрирование серверов 1С Предприятия».
2. В дереве откройте Центральные серверы 1С:Предприятия → имя сервера → Кластеры → кластер → Информационные базы → база → Сеансы.
3. Если консоль не открывается, а оснастка пустая — зарегистрируйте radmin.dll той же версии платформы, что и сервер: regsvr32 "C:\Program Files\1cv8\8.3.xx.xxxx\bin\radmin.dll" из командной строки от имени администратора.
4. В списке сеансов включите видимые колонки через контекстное меню. Полезные для анализа: «Время вызова (текущее)», «Захвачено СУБД», «Блокировано СУБД», «Блокировано 1С», объём памяти.

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

Утилита rac через сервер администрирования

rac — консольный клиент для сервера администрирования ras. Сначала запустите ras на сервере 1С. Для проверки хватит одной команды из каталога bin платформы:

ras cluster --port=1545 localhost:1540

Для постоянной работы регистрируйте ras службой — тогда он поднимется сам после перезагрузки.

Дальше работаем с любого компьютера, где есть rac той же версии:

rem 1. Узнаём идентификатор кластера
rac srv1c:1545 cluster list

rem 2. Список сеансов кластера
rac srv1c:1545 session list --cluster=<uuid-кластера> --cluster-user=admin --cluster-pwd=***

rem 3. Подробности по одному сеансу
rac srv1c:1545 session info --cluster=<uuid-кластера> --session=<uuid-сеанса> --cluster-user=admin --cluster-pwd=***

rem 4. Сеансы с выданными лицензиями
rac srv1c:1545 session list --cluster=<uuid-кластера> --licenses --cluster-user=admin --cluster-pwd=***

В выводе session info ищите поля user-name, host, app-id, blocked-by-dbms, blocked-by-ls и duration-current. Ненулевое blocked-by-dbms значит, что сеанс ждёт блокировку СУБД, blocked-by-ls — управляемую блокировку 1С. Остальные параметры подкоманд смотрите в справке: rac help session.

Как увидеть экран пользователя: теневое подключение к RDP-сессии

Когда пользователи работают в 1С на терминальном сервере, «подключиться к сеансу» обычно означает посмотреть его экран. Это делает Windows, а не 1С. Приём рабочий на Windows Server 2016 и новее.

1. На терминальном сервере узнайте номер RDP-сессии пользователя:

query session /server:term01

2. Подключитесь в режиме наблюдения или управления:

rem только смотреть
mstsc /shadow:3 /v:term01

rem смотреть и управлять мышью и клавиатурой
mstsc /shadow:3 /v:term01 /control

3. Пользователь увидит запрос на разрешение подключения. Ключ /noConsentPrompt убирает запрос, но работает, только если групповая политика допускает управление без согласия.

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

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

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

Отладка сеанса пользователя и замер производительности

Когда нужно понять, какой код выполняется у пользователя, подключайтесь отладчиком. С платформы 8.3 основной вариант — отладка по протоколу HTTP через сервер отладки dbgs.

Подготовка сервера

Серверный код можно отлаживать, только если агент сервера запущен с ключом отладки. В параметрах службы агента в строке запуска должно быть -debug -http.

Подключение отладчика

1. В Конфигураторе откройте Сервис → Параметры → Отладка и выберите протокол HTTP.
2. Запустите отладку или откройте Отладка → Подключение. В окне предметов отладки появятся сеансы, которые разрешили подключение.
3. В окне предметов отладки откройте настройку автоматического подключения и отметьте типы предметов: тонкий клиент, сервер, фоновые задания.
4. Пользователь должен запустить клиент с разрешённой отладкой. Надёжный способ — ярлык с параметрами:

"C:\Program Files\1cv8\common\1cestart.exe" /DEBUG -http -attach /DEBUGGERURL "http://devpc:1550"

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

Замер производительности

Подключившись, включите Отладка → Замер производительности и попросите пользователя повторить медленное действие. После остановки замера откроется список строк кода с числом вызовов и долей времени. Обычно картина ясна сразу: 80–90% времени приходится на одну-две строки — запрос или цикл с обращением к базе.

💡 Отладку на рабочей базе ведите аккуратно: точка останова в серверном коде остановит сеанс пользователя, пока вы не продолжите выполнение. Лучше воспроизводить проблему на копии базы.

Поиск блокировок и взаимоблокировок по сеансам

Жалоба «у меня всё висит» почти всегда сводится к тому, что один сеанс ждёт другой. Начинают с консоли кластера.

Кто кого держит

• 🔴 В списке сеансов отсортируйте по колонке «Блокировано 1С» или «Блокировано СУБД». В ней указан номер сеанса, который держит блокировку.
• 🟠 Перейдите к сеансу-виновнику: посмотрите «Время вызова (текущее)» и «Захвачено СУБД». Долгий вызов с большим временем в СУБД — кандидат на разбор.
• 🟢 По номеру сеанса откройте журнал регистрации и найдите, что этот пользователь проводил в эту минуту.

Типичный текст ошибки у пользователя, который не дождался блокировки:

Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки

Время ожидания по умолчанию — 20 секунд. Оно задаётся в свойствах информационной базы на сервере СУБД, а не в 1С.

Со стороны MS SQL Server

Если «Блокировано СУБД» не пустое, посмотрите блокировки на сервере СУБД:

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

blocking_session_id — соединение SQL, которое держит ресурс. Сопоставить его с сеансом 1С помогает колонка «Соединение с СУБД» в консоли кластера.

Взаимоблокировки

Взаимоблокировка — два сеанса ждут друг друга, и один из них система принудительно прерывает. Поймать их по списку сеансов почти невозможно: всё длится доли секунды. Нужен технологический журнал. Положите в каталог conf платформы файл logcfg.xml:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

События TDEADLOCK покажут оба сеанса и пространства блокировок, TTIMEOUT — таймауты ожидания, TLOCK — сами управляемые блокировки. Журнал быстро растёт: включайте его на время расследования, history="24" хранит сутки.

Ошибки при подключении к сеансу и что делать

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