RDP подключается, но зависает или обрывается: как собирать данные о сеансе

Сначала назовите симптом точнее

«RDP завис» может означать неподвижную картинку при живом сеансе, остановку одного приложения, отключение транспорта или завершение входа пользователя. Для каждого случая нужны свои данные. Зафиксируйте точное время, текст окна, код ошибки и происходившее действие: простой, видео, передача файла, печать или переподключение VPN.

Здесь рассматривается прямой сеанс mstsc.exe к Windows 11 или администрируемому Windows-хосту. У RDS, RD Gateway и облачных рабочих мест есть отдельные серверы и политики. Серверные ошибки лицензирования RDS нельзя автоматически объяснять ими обычный вход к Windows 11 Pro. ^[1]

При повторном входе установите судьбу старого сеанса

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

qwinsta

Сохраните имя пользователя, идентификатор и состояние нужного сеанса. Статус Disc означает отключённый сеанс, а не обязательно выполненный выход. Результат команды после эпизода нужно сопоставить с событиями и временем; он не восстанавливает всю историю. ^[2]

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

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

Найдите журналы на обеих сторонах

На клиенте и хосте выполните:

Get-WinEvent -ListLog '*TerminalServices*' |
  Select-Object LogName, IsEnabled, RecordCount
Get-WinEvent -ListLog '*RemoteDesktopServices*' |
  Select-Object LogName, IsEnabled, RecordCount

Для mstsc-клиента полезен доступный журнал Microsoft-Windows-TerminalServices-RDPClient/Operational. На хосте ищут LocalSessionManager, RemoteConnectionManager и RdpCoreTS. Названия и наличие каналов зависят от компонента и версии. Смотрите полный путь, поставщика и текст, а не универсальную расшифровку одного номера. ^{[1], [3]}

В Просмотре событий сохраните нужные каналы как EVTX; дополнительно полезен System вокруг эпизода. Если канал был выключен, его включение помогает только следующему воспроизведению. Проверяйте часы и часовые пояса обеих машин: локально показанное время и XML-время события могут различаться представлением.

Соберите узкое временное окно

Пример для клиентского журнала за последние полчаса:

$LogName = 'Microsoft-Windows-TerminalServices-RDPClient/Operational'
Get-WinEvent -FilterHashtable @{
  LogName = $LogName
  StartTime = (Get-Date).AddMinutes(-30)
} | Sort-Object TimeCreated |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
    Format-List

Для хоста подставьте реально найденный путь журнала и выполните на самом хосте. Команда может требовать прав на чтение или сообщить об отсутствии подходящих событий. Нулевой результат не доказывает, что обрыва не было. ^[3]

Отделите путь сети от графики и приложения

Во время эпизода проверьте, доступен ли хост другим согласованным способом, и что показывает человек у его локального экрана. Если зависла только одна программа, а рабочий стол и другие окна отвечают, исследуйте приложение. Если локально остановился весь хост, один RDP-клиент не является достаточным объяснением.

Сопоставьте обрыв с потерей Wi‑Fi, переподключением VPN, сном клиента, сменой сети и общей нагрузкой хоста. Для прямого RDP повторите Test-NetConnection к фактическому порту до и после сбоя. Этот TCP-тест не проверяет UDP и не измеряет плавность изображения. ^[4]

Для графической гипотезы можно сравнить меньшее разрешение, один монитор и сеанс без ненужного перенаправления дисков и устройств. Меняйте только один параметр и сохраните исходное значение. Улучшение указывает на направление поиска, но само по себе не доказывает дефект видеодрайвера.

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

Обратимый тест: временно использовать только TCP

Официальная политика клиента «Turn Off UDP On Client» при включении ограничивает RDP транспортом TCP; в отключённом или ненастроенном состоянии клиент пытается использовать TCP и UDP. Это позволяет сравнить транспорт при воспроизводимом обрыве, но не является обязательной настройкой любого RDP. ^[5]

На клиенте Windows Pro, Enterprise или Education откройте gpedit.msc → Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Службы удалённых рабочих столов → Клиент подключения к удалённому рабочему столу. Найдите политику отключения UDP на клиенте. Запишите прежнее состояние, временно включите, закройте mstsc и создайте новое подключение.

Повторите тот же сценарий достаточно долго, чтобы захватить обычный интервал проблемы. Затем верните точное исходное состояние политики и сравните. Управляемая доменная политика может перекрыть локальную; не обходите её реестровым параметром. У Windows Home редактор gpedit отсутствует штатно, устанавливать сторонний «разблокировщик» не требуется.

Если TCP стабилен, а обычный режим нет, исследуют UDP-путь, VPN, драйверы и промежуточные устройства. Такое сравнение не доказывает, что любой UDP в системе сломан. Меньшая частота обрывов в коротком тесте тоже ещё не подтверждает исправление.

Проверьте тайм-ауты и обновления по конкретной сборке

Регулярное отключение после одинакового времени простоя направляет к лимитам сеанса и политике сети. Отдельно различайте предел неактивности, максимальную длительность и завершение уже отключённого сеанса. Эти значения могут задаваться централизованно. Описание политик Microsoft помогает определить их назначение; переносить чужие значения без контекста не нужно. ^[5]

Если начало проблемы совпало с обновлением, сохраните сборки клиента и хоста, версии драйверов и дату. Проверяйте документированную известную проблему именно этих версий. Старое исправление UDP для Windows 8.1 не является свидетельством причины текущего сбоя Windows 11.

Передайте данные, которые позволят продолжить анализ

Нужны схема «клиент → VPN или шлюз → хост», точное время, полный код, судьба сеанса, версии обеих Windows, журналы обеих сторон и результат одного контролируемого изменения. Добавьте, повторяется ли проблема с другого разрешённого клиента или в другой сети.

В сложной корпоративной среде Microsoft предлагает одновременный сбор TSS на соответствующих узлах. Это отдельный диагностический этап с согласованным объёмом данных; включать запись экрана и выполнять серверные сценарии на личном ПК автоматически не следует. ^[6]