«Заморозка» изображения удалённого рабочего стола Windows 10 — решаем проблему
Столкнулся с интересной проблемой при переходе на удалённую работу. Работать приходится на рабочей машине через VPN, подключаясь к ней с помощью клиента удалённого рабочего стола с домашнего ПК. И вот при подобном соединении периодически как бы зависал экран, т.е. изображение полностью замирало, не менялось даже на чёрный экран. При этом отсоединения от сессии не проходило, мышь и клавиатура продолжала работать, так как при переключении было видно, что нажатия клавиш и мыши были переданы на удалённый ПК.
Приходилось постоянно переподключаться к рабочему ПК, что реально бесило — такое случалось часто, иногда по нескольку раз за несколько минут, иногда за час. Понятно было, что надо что-то делать, но непонятно было что. При этом домашний ноутбук, в отличии от ПК, таких кунштюков не выдавал, стабильно работая — было ясно, что проблема не в нестабильной работе сети или VPN, а кроется где-то в программной части домашнего ПК. Сначала я исправил всё, что показывал журнал системных ошибок, но это не помогло. Начал было уже косо смотреть на драйвер видеокарты, но мысль о том, что изображение замирает только в сессии RDP (Remote Desktop Protocol) меня успокоило на этот счёт. Поиски в интернете сначала успехов не принесли, потому что информации очень много и трудно так сформулировать запрос, чтобы на него не выдавалось куча бесполезной в моём случае информации. Но потом я всё-таки начал искать в английском сегменте и сразу нашёл решение.
По мнению тех, кто отвечал на вопрос подобный моему, дело заключалось в протоколе UDP, который использовался (вместе с TCP) в соединениях по протоколу RDP. И предлагалось отключить эту возможность через редактор локальных групповых политики Windows. Однако, в версии Windows 10 Home, этот редактор по-умолчанию отключён. Хорошо, что его можно установить, пусть для этого нам потребуется командная строка с правами администратора. Сначала надо ввести следующую строку:
FOR %F IN ("%SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientTools-Package~*.mum") DO (DISM /Online /NoRestart /Add-Package:"%F")Дождаться завершения и получив сообщение «Операция успешно завершена.», запустить вторую команду:
FOR %F IN ("%SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientExtensions-Package~*.mum") DO (DISM /Online /NoRestart /Add-Package:"%F")После перезагрузки ПК, запускаем с правами администратора оснастку gpedit.msc, можно из командной строки, можно просто из поиска в главном меню Windows:
Далее, надо найти в редакторе раздел Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Клиент подключения к удаленному рабочему столу:
Открываем Выбор транспортных протоколов RDP:
Включаем эту политику, и в параметрах Выбор типа транспорта выбираем «Использовать только TCP».
Скорее всего, отказаться от протокола UDP в пользу TCP, для решение этой проблемы, нужно из-за того, что UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных, а TCP осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым (в отличие от UDP), целостность передаваемых данных и уведомление отправителя о результатах передачи. И когда клиент RDP через протокол UDP не получает нужный ему пакет и из-за этого подвисает изображение, то по какой-то причине клиент не понимает этого и не пытается решить эту проблему отправкой нового сообщения на отрисовку экрана. А вот через протокол TCP такого не проявляется, поскольку он гарантирует получение данных.
Но у меня почему-то данное решение не заработало. И пришлось копать глубже. И наконец-то мне удалось найти ещё один вариант с отключением UDP для RDP — с помощью редактора реестра. Для этого надо запустить командную строку с правами администратора и запустить команду:
reg add "HKLM\software\policies\microsoft\windows nt\Terminal Services\Client" /v fClientDisableUDP /d 1 /t REG_DWORDИли запустить редактор реестра с правами администратора:
И в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client добавить новый ключ fClientDisableUDP со цифровым значением 1:
Вот после этого, перезагрузив ПК, я полностью решил проблему с «заморозкой» изображения в клиенте удалённого рабочего стола.
В том же обсуждении упоминался и возможный «виновник» данного поведения клиента RDP: обновление Windows 10 под номером 1903, которое, в том числе, вносило исправления, касающиеся RDP-протокола:
- CVE-2019-1181 | Remote Desktop Services Remote Code Execution Vulnerability;
- CVE-2019-1182 | Remote Desktop Services Remote Code Execution Vulnerability.
На мой взгляд, эта версия имеет право на существование, поскольку на моём ноутбуке обновление 1903 не установлено, поскольку после его установки сначала отваливается Bluetooth, а после перезагрузки возникает «синий экран» и систему можно восстановить, только откатив последние изменения. Поэтому на нём таких симптомов и не было.
P.S. В общем, предложенное решение проблему с отваливанием сессии RDP у меня решало, но при этом оставались кратковременные лаги через четко определенное время. Выявить их можно было с помощью постоянной работы команды ping и выяснилось, что примерно 1% пакетов через каждые 2 минуты не проходил. Причину выяснить долго не удавалось, но в конце концов виновник был найден - это был конфликт ПО VipNET (который обеспечивал рабочий VPN) и брандмауэра Windows, который по умолчанию банил вообще всё (у меня с ним даже FTP-клиент в пассивном режиме не работал из-за этого). То бишь пакеты проходили, но периодически - раз, затык и всё. Т.е. просто конфликт ПО, который решить практически невозможно без открытия всех входящих портов на брандмауэре или простого его отключения. Ну надо же сделать такой инструмент, который практически бесполезен, ведь для того, чтобы нормально пользоваться программами, которые не используют один порт (или диапазон), а на входящее подключение выбирают произвольный вплоть до 65535, его приходится тут отключать, потому что правило просто не создать. И да, я пробовал делать правило для программ, и для служб, и для протоколов - один чёрт, ничего не работает. Видимо, у меня руки из одного места растут.
Комментариев 6