Что делать, если 1С зависла и не отвечает

Если «крутится» одна операция в вашем сеансе — попробуйте Ctrl+Break, а когда не помогает, снимите процесс клиента через «Диспетчер задач» (1cv8c.exe или 1cv8.exe). Если зависший сеанс мешает другим и вы администратор — его завершают из консоли кластера или утилитой rac. В файловой базе достаточно закрыть все клиенты.

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

Коротко, какой способ что оборвёт и когда его применять:

Остановить длительную операцию в своём сеансе

Самый частый случай — запустили тяжёлый отчёт или обработку, и окно «не отвечает». Прежде чем закрывать 1С, дайте платформе шанс остановиться штатно.

1. Если на экране индикатор прогресса с кнопкой отмены — нажмите её. Операция прервётся на ближайшей проверке.
2. Нажмите Ctrl+Break. Это штатная команда прерывания: встроенный язык остановит выполнение на ближайшей точке, где управление возвращается клиенту.
3. Подождите 10–20 секунд. Длинный серверный вызов (большой запрос, обмен) Ctrl+Break не прерывает — платформа ждёт ответа сервера.

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

Когда ничего не помогло, закройте клиент принудительно. Откройте «Диспетчер задач» (Ctrl+Shift+Esc), вкладка Подробности, найдите процесс:

• 1cv8c.exe — тонкий клиент (основной режим работы пользователей);
• 1cv8.exe — толстый клиент и «Конфигуратор».

Выделите нужный процесс и нажмите Снять задачу. Если открыто несколько баз, ориентируйтесь по столбцу потребления памяти — зависший обычно самый «тяжёлый».

Завершить чужой сеанс: консоль кластера и утилита rac

В клиент-серверном варианте (сервер 1С + СУБД) зависший сеанс одного пользователя может держать блокировку и мешать остальным. Завершает такой сеанс только администратор кластера — через графическую консоль или командную строку.

Через консоль администрирования. Откройте оснастку «Администрирование серверов 1С Предприятия» (MMC-консоль на сервере). Разверните дерево: кластер → Сеансы. В списке видны все активные сеансы: имя пользователя, информационная база, время, компьютер. Нужный сеанс — правой кнопкой → Удалить.

Там же есть узел Соединения — это более низкий уровень. Если сеанс не удаляется, завершите соответствующее соединение.

Через утилиту rac. Консольный клиент администрирования лежит в каталоге платформы (...\1cv8\8.3.x.xxxx\bin\rac.exe). Порядок такой:

rac cluster list
rac session list --cluster=<uuid-кластера>
rac session terminate --cluster=<uuid-кластера> --session=<uuid-сеанса>

Сначала узнаёте идентификатор кластера, потом список сеансов, затем завершаете нужный по его uuid. Если у кластера задан администратор, добавьте параметры авторизации. Полный перечень команд и параметров — в справке rac help и rac session help; не придумывайте ключи наугад.

Внутри самой программы список активных сеансов тоже виден: главное меню → Все функции → Стандартные → Активные пользователи. Завершить сеанс оттуда нельзя, но удобно посмотреть, кто в базе, прежде чем идти в консоль. Команду «Все функции» включают в настройках интерфейса, если её не видно.

Снять блокировку в СУБД

Если зависание проявляется как «БД заблокирована» или документы не проводятся, причина — блокировка на уровне СУБД: один запрос держит ресурс, остальные ждут. Разбирают это на стороне базы данных.

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

MS SQL Server. Когда сеанс не завершается, смотрите блокировки в SQL:

sp_who2 active

В столбце BlkBy виден номер процесса (SPID), который блокирует остальных. Если в этом столбце у строки стоит чужой SPID — значит, её держит он. Идёте по цепочке к процессу, у которого BlkBy пустой: это корень, виновник всей очереди. Снять его:

KILL <номер SPID>

Можно работать и через DMV — sys.dm_exec_requests, sys.dm_tran_locks покажут, кто кого ждёт и на каком ресурсе. Это удобнее, когда очередь ожиданий длинная и в sp_who2 тяжело разобраться глазами.

PostgreSQL. Активные запросы и блокировки видны в системном представлении:

SELECT pid, state, wait_event, query FROM pg_stat_activity;

Прервать конкретный бэкенд:

SELECT pg_terminate_backend(<pid>);

Монопольный доступ для снятия блокировки не нужен — это разные вещи. Монополия требуется только для обновления структуры конфигурации, загрузки .dt и тестирования-исправления базы.

Файловая база «занята другим процессом»

В файловом варианте нет сервера и консоли — всё проще. База лежит в одной папке (1Cv8.1CD), и доступ к ней координируется служебными файлами блокировки рядом с базой.

Типичная ситуация: клиент аварийно закрылся, а база считает, что сеанс ещё жив. При попытке войти — «Файл базы данных занят» или подобное.

Что делать по шагам:

1. Закройте все окна 1С на всех компьютерах, которые работают с этой базой.
2. Откройте «Диспетчер задач» и снимите все «висящие» процессы 1cv8c.exe и 1cv8.exe (на каждой машине, где открывали базу).
3. Проверьте, не держит ли папку базы антивирус или программа резервного копирования.
4. Попробуйте войти снова.

Если после закрытия всех клиентов рядом с базой остался служебный файл блокировки, который не исчез, — удалять его вручную можно только когда вы на 100% уверены, что базу никто не открыл. Самый надёжный способ снять зависшую блокировку в файловом варианте — перезагрузить компьютер, на котором висел процесс: при старте системы никаких держателей папки не останется.

Чтобы такие зависания не повторялись:

• 🖧 Не держите рабочую файловую базу на сетевой шаре с доступом нескольких пользователей — обрывы сети как раз и оставляют «мёртвые» блокировки. Для совместной работы это повод перейти на клиент-серверный вариант.
• 🧹 Приучите пользователей закрывать 1С через меню, а не кнопкой питания и не закрытием крышки ноутбука.
• 💾 Храните регулярные копии папки базы: если файл блокировки окажется частью повреждения, откатитесь на копию без потери дня работы.

Найти причину зависания в технологическом журнале

Снять зависший процесс — полдела. Чтобы не повторялось, нужно понять, что именно висело: долгий запрос, ожидание блокировки или взаимоблокировка (deadlock). Это показывает технологический журнал платформы.

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

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

Что искать в собранных файлах:

• 🔒 TLOCK — ожидание управляемой блокировки: видно, какой сеанс держит ресурс и кто ждёт.
• ♻️ TDEADLOCK — взаимоблокировка: два сеанса ждут друг друга, платформа убивает одного.
• ⏱️ TTIMEOUT — сработал тайм-аут ожидания блокировки.
• 🐌 Долгие CALL/DBMSSQL — тяжёлые серверные вызовы и запросы к СУБД.

По TLOCK вы увидите не только жертву, но и виновника — сеанс, который держит ресурс дольше положенного. Часто это и есть «зависший» пользователь, которого осталось завершить способом из раздела про консоль.

Крайняя мера: перезапуск агента сервера

Когда не завершается ни один сеанс, консоль не отвечает, а работа встала у всех — остаётся перезапустить службу сервера 1С. Это обнуляет кластер целиком.

На сервере службу зовут «Агент сервера 1С:Предприятия 8.3», процесс — ragent.exe. За ним стоят менеджер кластера rmngr.exe и рабочие процессы rphost.exe.

Порядок:

1. Откройте оснастку «Службы» (services.msc).
2. Найдите службу, имя которой начинается с «1C:Enterprise 8.3 Server Agent» (отображаемое — «Агент сервера 1С:Предприятия 8.3»).
3. Правой кнопкой → Перезапустить.

После рестарта агент заново поднимет рабочие процессы, и база снова станет доступна.

Не трогайте отдельный процесс rphost.exe без понимания: в кластере их может быть несколько, и снятие не того процесса ударит по чужим базам. Перезапуск службы агента — более предсказуемый шаг, чем ручное снятие рабочих процессов.

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