Event ID 4779: Сеанс отключен (Session Disconnected) - RDP
Архитектура RDP-сессий и статус Disconnected
Событие 4779 логируется в журнале Security, когда пользователь отключается от терминального сеанса (например, RDP), но не завершает его работу (не нажимает Пуск -> Выход / Sign Out). Чаще всего пользователь просто нажимает "крестик" на окне удаленного доступа. При этом ядро Windows переводит сессию в состояние Disconnected (Отключено). Все запущенные программы (1С, Excel, Chrome) продолжают полноценно работать и потреблять оперативную память (RAM) сервера.
Отличия 4779 от 4647 (Logoff)
| Событие (Event ID) | Суть действия (Operation) | Судьба оперативной памяти (RAM) |
|---|---|---|
| 4779 (Disconnected) | Разорвано сетевое подключение. Пользователь нажал 'крестик' или упал интернет. | RAM занята. Программы висят в памяти, ожидая возвращения пользователя. |
| >4647 (Logoff) | Пользователь нажал 'Выйти' (Logoff). | RAM освобождена. Ядро убило все процессы (wsmprovhost, 1c.exe) и уничтожило сессию. |
Пошаговое дерево решений (Борьба с утечками ОЗУ)
Сценарий 1: Управление "брошенными" сессиями (GPO)
Тысячи событий 4779 означают, что пользователи не умеют правильно выходить из системы. Это приводит к переполнению ОЗУ (Memory Leak) и зависанию терминальных ферм. Вам необходимо настроить автоматический Logoff.
- Откройте
gpedit.msc(на сервере RDS или в домене). - Перейдите:
Конфигурация компьютера -> Адм. шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов -> Ограничение времени сеансов. - Включите политику Задать ограничение времени для отключенных сеансов (Set time limit for disconnected sessions).
- Установите значение 2 часа или 3 часа. (После этого времени сервер сам убьет сессию, освободив RAM).
Сценарий 2: Аудит 'грязных' отключений (PowerShell)
Если вам нужно найти сотрудников, которые систематически "бросают" свои сессии, отследите их по логам.
Скрипт поиска отключенных сессий:# Ищем отключенные сессии за сегодня
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4779; StartTime=(Get-Date).Date} |
Select-Object TimeCreated,
@{N='User';E={$_.Properties[0].Value}},
@{N='ClientIP';E={$_.Properties[4].Value}} | Format-Table -AutoSizeТиповые ошибки администраторов
- Поиск события 4634 после 4779: Если пользователь отключился (4779), событие окончательной смерти сессии (>4634 Logoff) не сгенерируется, пока не сработает таймаут из Сценария 1. Сессия будет висеть в невидимом лимбе сутками, потребляя ресурсы процессора.
Неконтролируемые RDP-сессии — главная причина деградации производительности 1С и обрушения серверов. Передайте ферму RDS нам на поддержку: мы настроим автоматическую ротацию сессий, профили FSLogix, сброс кэшей (Recycling) и ускорим работу пользователей.
Частые вопросы (FAQ)
Вызывает ли 4779 событие 4634 (Account Logged Off)?
Нет. Событие 4634 появится только тогда, когда сессия будет окончательно убита (вручную администратором, самим пользователем при возврате, или по тайм-ауту GPO).
Генерируется ли 4779 при блокировке экрана (Win+L)?
В старых версиях ОС — да, блокировка экрана генерировала 4779. В современных ОС (Windows 10 / Server 2016+) для блокировки экрана выделено специальное событие 4800 (Workstation Locked).
Останавливаются ли скрипты и загрузки при 4779?
Нет. Все процессы (копирование файлов, выполнение отчетов SQL) продолжают работать в фоне. Оконная станция (Window Station) просто отключается от видеодрайвера (RDP WDDM).
Почему 4779 происходит ровно через 10 минут простоя?
У вас включена групповая политика 'Задать ограничение времени для активных, но бездействующих сеансов' (Idle Session Limit). Сервер сам отключает пользователя за неактивность.
Сгенерируется ли 4779 при разрыве VPN соединения?
Да. Если туннель VPN падает, TCP-пакеты RDP перестают доходить до сервера (Keep-Alive Timeout). Служба TermService фиксирует разрыв и переводит сессию в статус Disconnected (4779).