Как принудительно закрыть 1С на удалённом рабочем столе

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

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

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

Определите, какой именно процесс завис

На терминальном сервере одновременно работают десятки процессов с одинаковыми именами. Толстый и тонкий клиент 1С обычно видны как 1cv8.exe или 1cv8c.exe, веб-клиент работает внутри браузера, а фоновые задания клиент-серверной базы выполняются рабочими процессами rphost.exe на сервере 1С. Завершать «первый попавшийся» 1cv8.exe нельзя — можно закрыть сеанс другого сотрудника.

Откройте диспетчер задач (Ctrl+Shift+Esc), перейдите на вкладку «Подробности» и добавьте столбец «Имя пользователя» через контекстное меню заголовков колонок. Так вы увидите, какому пользователю принадлежит каждый процесс. Если вы обычный пользователь без прав администратора, вы увидите и сможете завершить только свои процессы — это нормальная защита системы.

Способ 1: завершение через диспетчер задач

Самый доступный способ, не требующий командной строки. Нажмите Ctrl+Shift+Esc внутри сеанса RDP, найдите зависший процесс 1cv8.exe, щёлкните по нему правой кнопкой и выберите «Снять задачу». Если окно 1С отображается, но не отвечает, на вкладке «Процессы» оно будет помечено как «Не отвечает» — это дополнительное подтверждение, что вы выбрали правильный объект.

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

После снятия задачи подождите 10–20 секунд: в клиент-серверном режиме соединение с базой закрывается не мгновенно, и сеанс в консоли кластера может «повисеть» ещё некоторое время, прежде чем исчезнуть.

Способ 2: команда taskkill в командной строке

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

taskkill /PID 12345 /F

Параметр /F означает принудительное завершение без ожидания ответа приложения. Если вы точно уверены, что на сервере работаете только вы (например, личный тестовый сервер), можно завершить все процессы 1С по имени образа: taskkill /IM 1cv8.exe /F. На рабочем терминальном сервере так делать нельзя — команда закроет 1С у всех пользователей.

Фильтрация по пользователю возможна через PowerShell, что полезно администратору:

Get-Process 1cv8 -IncludeUserName | Where-Object {$_.UserName -like '<em>ivanov</em>'} | Stop-Process -Force

Способ 3: завершение сеанса через консоль кластера 1С

Если база работает в клиент-серверном режиме, у администратора есть самый «чистый» инструмент — консоль администрирования серверов 1С. Откройте консоль, разверните кластер, перейдите в раздел «Сеансы», найдите нужного пользователя по имени и базе, затем через контекстное меню выберите «Удалить».

Преимущество способа в том, что кластер корректно разрывает соединение и снимает связанные блокировки, тогда как убитый на уровне Windows процесс может оставить «фантомный» сеанс, который будет держать блокировки ещё несколько минут. Это особенно важно, если зависший пользователь редактировал документы — остальные сотрудники будут получать ошибки «Конфликт блокировок» до тех пор, пока сеанс не исчезнет.

Обратите внимание: удаление сеанса в консоли закрывает клиентское приложение на стороне сервера без сохранения данных. Предупредите пользователя, если есть такая возможность.

Способ 4: разрыв всего сеанса RDP

Если завис не только 1С, а весь удалённый рабочий стол (чёрный экран, не открывается диспетчер задач), администратор может сбросить сеанс целиком. Это делается через диспетчер задач на вкладке «Пользователи» (пункт «Выйти»), через оснастку «Диспетчер удалённых рабочих столов» либо командой logoff с номером сеанса, который показывает команда query session или quser.

quser
logoff 7

Разрыв сеанса завершает все процессы пользователя, включая 1С, без сохранения открытых документов. Это крайняя мера: сначала попробуйте завершить только процесс 1С, потому что в сеансе могут быть другие открытые программы с несохранённой работой.

Что проверить после принудительного закрытия

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

Если блокировки остались, откройте консоль кластера и удалите зависший сеанс вручную — после этого объекты базы освободятся. В файловом режиме работы аналогичную роль играет файл 1Cv8.1CL в папке базы: если после аварийного завершения база сообщает, что она занята, убедитесь, что все процессы 1С на всех компьютерах закрыты, после чего файл блокировки можно удалить.

Как снизить риск повторных зависаний

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

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

FAQ