Что делать, если фантомные пользователи в 1С 8.2 не позволяют обновить конфигурацию?

← На главную

В процессе администрирования 1С:Предприятие 8.2 администраторы часто сталкиваются с ситуацией, когда при попытке обновить конфигурацию базы данных или выполнить действия, требующие монопольного режима, система выдает ошибку. В сообщении перечисляются имена пользователей (например, «Иванов, Петров...»), которые якобы работают в базе, хотя консоль сервера 1С и список активных пользователей в самой программе показывают, что в системе никого нет, кроме администратора. Рассмотрим подробно, почему возникают «фантомные» пользователи и как очистить систему от зависших соединений.

Метод 1: Очистка серверного кэша сеансов (каталог srvinfo)

Основная причина возникновения фантомных сеансов на платформе 8.2 — это рассинхронизация данных в служебных файлах кластера. Когда рабочий процесс rphost завершается некорректно (например, при сбое или принудительном завершении через диспетчер задач), информация о сеансах может остаться в файлах контекста, даже если само соединение с базой данных уже разорвано. Физическая перезагрузка сервера не всегда помогает, так как при старте служба 1С заново считывает данные из этих файлов.

Разберем по шагам процесс очистки кэша сеансов:

Остановим службу 1С:Предприятие. Откроем оснастку «Службы» (services.msc) и найдем службу Агент сервера 1С:Предприятия 8.2. Остановим её. Это критически важно, так как при работающей службе файлы заблокированы.
Перейдем в каталог данных кластера. По умолчанию данные хранятся по пути C:\Program Files\1cv82\srvinfo (или в папке Program Files (x86) для 32-битных систем).
Найдем папку нужного кластера. Внутри srvinfo будет папка вида reg_1541 (номер соответствует порту кластера). Зайдем в неё.
Удалим контекст сеансов. Нам нужны папки, название которых начинается на snccntx (Session Context). В этих папках 1С хранит информацию о текущих сеансах пользователей. Удалим содержимое этих папок или сами папки.
Запустим службу. Снова запустим службу Агент сервера 1С:Предприятия 8.2. Теперь список сеансов будет абсолютно чистым.

Метод 2: Блокировка регламентных заданий в консоли сервера

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

Проанализируем ситуацию и выполним следующие действия:

Зайдем в Консоль администрирования серверов 1С:Предприятия. Откроем свойства нашей информационной базы. Установим галочку «Блокировка регламентных заданий включена». Рекомендуется также установить «Блокировка начала сеансов включена» и указать параметр /UC (код разрешения), чтобы вы сами могли зайти в конфигуратор. После установки блокировок подождем 2–5 минут, чтобы все текущие фоновые процессы завершились или были отсечены планировщиком.

Метод 3: Проверка спящих процессов в SQL Server

Если база данных работает в клиент-серверном варианте под управлением MS SQL Server, проблема может крыться на уровне СУБД. 1С видит активного пользователя, если в SQL Server висит открытая транзакция или «спящее» (sleeping) соединение, которое удерживает блокировку на системные таблицы 1С.

Выясним причину с помощью SQL Management Studio:

Откроем SQL Server Management Studio и выполним запрос для поиска активных соединений с нашей базой данных. Можно использовать стандартную процедуру sp_who2 или более детальный запрос:


SELECT 
    spid, 
    status, 
    loginame, 
    hostname, 
    db_name(dbid) as DBName
FROM sys.sysprocesses
WHERE dbid = DB_ID('Имя_Вашей_Базы');

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

Метод 4: Очистка локального кэша пользователя

В редких случаях список пользователей, который выдает 1С при ошибке («В базе работают: ...»), берется из локальных кэш-файлов того пользователя, который запускает Конфигуратор. Это происходит из-за того, что информация о последнем составе сеансов могла закэшироваться в профиле Windows.

Рассмотрим порядок очистки локального кэша:

Закроем все окна 1С:Предприятия.
Перейдем в папки:
- %AppData%\1C\1Cv82
- %LocalAppData%\1C\1Cv82
Удалим все папки с длинными буквенно-цифровыми названиями (GUID базы). Внимание: это сбросит настройки пользователя (размеры окон, положение панелей), но поможет избавиться от неактуальных данных о блокировках.

Метод 5: Проверка терминальных сессий (RDP)

Если работа ведется на терминальном сервере, физическая перезагрузка службы 1С может не помочь, если процессы 1cv8.exe зависли в «отсоединенных» (Disconnected) сессиях пользователей Windows. Процесс продолжает удерживать соединение с сервером 1С, хотя пользователь давно закрыл окно RDP крестиком.

Проверим диспетчер задач на сервере. Перейдем на вкладку «Подробности» или «Пользователи» и завершим все процессы 1cv8.exe и 1cv8s.exe, которые запущены не вами. Только после того, как в памяти сервера не останется ни одного клиентского процесса 1С, попытка обновления будет успешной.