Купили начальнику отдела новый компьютер и монитор. На компьютере установлена система Windows 10. Сразу появилось две проблемы :
1. Если переключаешься на свой рабочий стол, сворачивая терминал и работаешь на нем, а потом опять хочешь зайти в терминал, то возникает синий экран, держится секунд 10, а потом либо показывает дальше нормально удаленный рабочий стол, либо вообще полностью выкидывает из удаленки с завершением сеанса. Терминал на Windows Server 2012.
Такая проблема возникла когда ни клиентских машинах установлен Windows 10, у тех у кого Windows 7 — таких проблем нет.
2. На Full HD мониторе все формы документов не распахиваются на весь экран (форма документа на весь экран, а табличная часть и остальные реквизиты на форме занимают лишь половину формы). Через кнопку «Восстановить положение окна» удается распределить все реквизиты на всю форму по длине и ширине. Но это надо делать каждый раз. Кэш у пользователя чистили, даже заводили нового терминального пользователя. На других мониторах такой проблемы нет. Разрешение экрана у проблемного монитора 1920*1080 и 175 процентов масштаб.
Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров67K
Для доступа удалённому Windows-серверу из Windows-системы большинство администраторов используют протокол удалённого рабочего стола (Remote Desktop Protocol — RDP). Есть, конечно, и существенная доля тех, кто оперирует более обширным перечнем вариантов подключения — Microsoft Remote Assistance, VNC, Radmin и много чего ещё, но мы поговорим про RDP. Вернее, не о самом RDP, а о проблемах, которые могут возникнуть при подключении к удалённому серверу при помощи этого протокола.
Для многих, вероятно, не составляет труда решить внезапно возникшее затруднение, когда почему-то не получается подключиться к виртуалке, вдобавок практически каждый, не сходя с места, подкинет пару-тройку советов, где и что следует глянуть, чтобы исправить проблему. И всё же, вдруг кто-то чего-то не знает. На этот случай под катом несколько способов выхода из ситуации — по большей части самых простых.
▍ Немного теории
RDP — сетевой протокол разработки корпорации Microsoft, позволяющий управлять удалённым компьютером или виртуальной машиной. Протокол был разработан для поддержки множества различных типов сетевых топологий, таких как ISDN, POTS, IPX, NetBIOS, TCP/IP. Текущая версия работает только по протоколу TCP/IP. Передача данных через стек RDP производится в рамках семиуровневых стандартов модели OSI. Данные из службы или приложения передаются вниз по стекам протоколов, где они разбиваются на секции, направляются в канал, шифруются, оформляются, упаковываются в сетевой протокол и, наконец, отправляются в адрес клиента. Возвращаемые данные обрабатываются так же, только в обратном порядке. Пакет лишается своего адреса, после чего разворачивается, расшифровывается и передаётся приложению.
Протокол использует архитектуру клиент-сервер, когда клиент инициирует подключение, а сервер отвечает на полученный запрос. Чтобы начать сеанс RDP, клиент посылает на удалённый узел запрос на подключение, включающий в себя данные, необходимые для входа в систему — учётную запись пользователя, разрешение и глубину цветопередачи экрана удалённого рабочего стола, параметры использования клавиатуры, звука и тому подобное. После чего сервер проверяет корректность учётных данных подключающегося пользователя и устанавливает соединение с клиентом.
В установленном соединении RDP использует сочетание методов сжатия, кэширования и кодирования для оптимизации передачи обновлений экрана, ввода с помощью мыши и клавиатуры и других данных.
Для подключения к удалённому рабочему столу из Windows-системы используется специальный клиент, запуск которого осуществляется при помощи комбинации клавиш Win и R, где необходимо ввести mstsc.
По умолчанию RDP использует на удалённой машине порт 3389. Для того, чтобы успешно установить соединение, этот порт должен быть открыт и доступен через брандмауэры и конфигурацию сетевой безопасности. При этом следует отметить, что номер порта может быть изменён администратором для приведения настроек конфигурации RDP в соответствие со своими конкретными потребностями.
▍ Недостаточность прав пользователя
Для многих очевидно, что пользователь, под именем которого производится подключение к удалённому рабочему столу, должен обладать определёнными полномочиями. В самом простейшем случае локальная учётная запись должна входить либо в группу Administrators, либо, если данной учётке не нужны администраторские привилегии, в группу Remote Desktop Users. Если же пользователь не обладает достаточными правами, ошибка при подключении выглядит следующим образом:
Решением в данном случае является добавление учётной записи дополнительных полномочий путём помещения её в соответствующую группу, либо потребуется настройка групповых политик, если вы используете Active Directory.
▍ Проверка порта RDP
Именно с возможным изменением номера порта связан первый из рассматриваемых рецептов восстановления неработающего подключения к удалённому рабочему столу. Если номер порта на удалённом сервере не совпадает с номером порта на локальной машине, клиент mstsc выдаёт ошибку, как на скриншоте ниже.
Чтобы проверить и при несоответствии изменить номер порта на удалённом сервере, придётся подключиться к нему либо при помощи консоли, либо с использованием какого-либо другого протокола — здесь вам в помощь VNC, Radmin или что-либо подобное. На серверах RUVDS для подобных ситуаций предусмотрен специальный аварийный режим работы, который по сути является аналогом консольного подключения. Для того, чтобы получить возможность управлять виртуальной машиной в данном режиме, достаточно кликнуть на изображение его экрана в списке серверов.
Получив доступ к удалённой машине, необходимо запустить редактор реестра. Для этого в строке поиска набираем regedit. В результате чего система найдёт соответствующее приложение.
Хорошим тоном в таких ситуациях является создание резервной копии на случай, если внесённые изменения приведут к каким-либо неожиданным последствиям. Системный реестр — серьёзная вещь, поэтому подобный подход здесь особенно важен. Чтобы создать бэкап в редакторе реестра, переходим в File, затем Export. После чего указываем место на диске, куда нужно сохранить файл резервной копии, в разделе Export range отмечаем сохранение всего реестра целиком и нажимаем Save.
Если что-то пойдёт не так, восстановить реестр из копии можно будет также в редакторе через File → Import.
Теперь к главному. В редакторе реестра через Edit → Find запускаем поиск ветки rdp-tcp.
В ветке RDP-Tcp ищем параметр PortNumber, открываем его, указываем отображение в десятичном формате и, если значением параметра является не 3389, меняем его и нажимаем ОК.
Теперь для применения внесённых изменений необходимо перезапустить службы удалённых рабочих столов. Чтобы это сделать, в строке поиска вводим services и выбираем приложение, в котором перечислены службы, работающие в фоновом режиме.
Здесь находим службу Remote Desktop Services и кликаем на Restart.
Кроме того, следует иметь в виду, что порт, предназначенный для подключения по RDP, должен быть открыт в брандмауэре удалённого сервера. Правила, применяемые для RDP, называются Remote Desktop — User Mode. Проверяем их тоже на всякий случай.
Если попытки подключиться по RDP всё ещё заканчиваются ничем, следует в числе прочего проверить статус протокола. Для этого также необходимо войти в удалённую систему через консоль или протокол, отличный от RDP, после чего запустить редактор реестра. Здесь проверяем параметр fDenyTSConnections, который находится в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server. Значением параметра может быть 0 или 1. Первое значение означает, что протокол работает, второе указывает на то, что он отключён. Естественно, устанавливаем значение параметра в 0 и снова пытаемся подключиться к серверу по RDP.
Для проверки статуса протокола удалённого рабочего стола можно использовать командную оболочку PowerShell. В поисковой строке набираем powershell и запускаем найденное приложение от имени администратора.
В командной строке выполняем команду Get-Service TermService и смотрим, что вывод показывает в колонке Status.
Здесь же проверяем, слушается ли порт 3389 на стороне сервера. Оптимально, если порт присутствует в списке и в столбце Status имеет значение Listen. Проверку состояния порта производим командой:
Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 3389
Помимо этого, PowerShell позволяет проверить наличие в брандмауэре правила, разрешающего входящие RDP-подключения. Команда для такой проверки выглядит следующим образом:
Get-NetFirewallPortFilter | Where-Object LocalPort -EQ 3389 | Get-NetFirewallRule
О том, что доступ к порту разрешён, свидетельствует значение True в поле Enabled и значение Allow в поле Action.
Проверить состояние порта RDP можно также и из монитора ресурсов, для запуска которого после нажатия Win R вводим resmon.exe, либо в Control Panel переходим Administrative Tools → Resource Monitor. Активность на порту доступна для мониторинга в разделе TCP Connections вкладки Network.
▍ Проверка настроек файрвола в личном кабинете
В личном кабинете RUVDS присутствует штатный межсетевой экран, при помощи которого можно легко настроить параметры доступа к виртуальным серверам. Основой конфигурации данного файрвола является набор разрешающих и запрещающих правил, создаваемых владельцем виртуалок. Для доступа к настройкам межсетевого экрана переходим в личный кабинет и в настройках сервера переключаемся на вкладку Сеть, где кликаем на Настроить файрвол для публичных адресов. Чтобы получить доступ к изменению конфигурации межсетевого экрана, необходимо корректно набрать пароль от личного кабинета.
В открывшемся окне обратите внимание на список правил файрвола. Здесь нас в первую очередь должны интересовать правила, касающиеся рассматриваемого протокола. Если ранее вы уже прописывали правила, позволяющие или запрещающие подключаться к порту RDP из какой-то определённой сети или с какого-либо IP-адреса, то, вероятно, невозможность подключения к виртуальной машине заключена именно в этом. Убедитесь, что IP-адрес, с которого вы пытаетесь соединиться с вашим VPS, является валидным с точки зрения текущего набора правил.
Желание обезопасить сервер путём ограничения доступа к нему не лишено здравого смысла, но всё же требует определённой степени аккуратности. Здесь важно не заблокировать доступ самому себе.
▍ Проверка локальной рабочей станции
Корнем проблем, препятствующих бесперебойному подключению по RDP, может служить компьютер, с которого такое подключение производится. В некоторых случаях помогает очистка истории RDP-подключений. Сделать это можно в редакторе реестра на локальной машине. А именно, открываем редактор, для чего используем комбинацию клавиш Win и R, где вводим regedit.exe и переходим на ветку HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client. Там разворачиваем ветку Default и выделяем все параметры с именами MRU0-MRU9, потом нажимаем правую кнопку мыши и кликаем на Удалить.
Там же можно очистить всю историю RDP-подключений вместе с сохранёнными адресами и именами пользователей. Для этого необходимо удалить содержимое ветки Servers. Поскольку выделять все вложенные ветки внутри Servers не совсем сподручно, удобнее будет удалить данную ветку целиком и после этого создать новую с таким же названием.
После таких манипуляций с реестром перезагружаем локальный компьютер и пробуем подключиться к удалённой машине.
В некоторых случаях может помочь изменение настроек подключения в клиенте mstsc. Для этого запускаем его, нажимаем стрелочку Показать параметры и переходим во вкладку Взаимодействие. Здесь устанавливаем или убираем галочку в строке Восстановить подключение при разрыве (действие зависит от того, в каком состоянии находится данный чекбокс).
Затем снова пробуем при помощи кнопки Подключить.
▍ Заключение
При любых сложностях в подключении к удалённой машине следует помнить, что доступ к виртуальному серверу RUVDS возможен через аварийный режим. Данный режим хотя и имеет ограничения по времени использования, всё же позволяет решить проблему на стороне удалённого сервера. В то же время, как мы уже смогли убедиться, причина невозможности подключения может заключаться в рабочей станции, с которой производится подключение.
Не всегда неудачная попытка подключения по RDP заканчивается выводом какой-либо ошибки. Для пользователя, который подключается к удалённой системе, это может выглядеть как «бесконечный коннект». В такой ситуации полезно убедиться, что на виртуальном сервере установлено достаточное количество оперативной памяти, которое позволяет службе RDP работать в штатном режиме. К примеру, на удалённой системе может быть запущено чрезмерное количество торговых ботов, и под такой нагрузкой у сервера нет возможности поддерживать полноценную работу RDP.
Также никто не отменял самый популярный метод решения всех неурядиц — перезагрузку машины. Не исключено, что сервер банально «завис». Перезапустить его можно в личном кабинете при помощи соответствующей кнопки под изображением экрана виртуалки.
Если решить проблему всё же не удаётся, всегда можно инициировать переустановку операционной системы на виртуальном сервере, если на нём нет важной информации или такие данные предварительно сохранены. Ну, и естественно, можно обратиться к специалистам технической поддержки.
Скидки, итоги розыгрышей и новости о спутнике RUVDS — в нашем Telegram-канале ?
Время на прочтение4 мин
Количество просмотров25K
30 сентября 2016 г вышел Windows Server 2016. К сожалению, вместе с положительными новшествами пришли и отрицательные. В Windows Server успешно перенесена ошибка из Windows 10 Anniversary Update, вызывающая падение удалённого сервера при обращении из него к локальному пути \\tsclient через FAR Manager.
С самого первого проявления данной проблемы я пытался обратить на это внимание фирмы Microsoft, но безуспешно. Решения нет до сих пор.
UPDATE. Ошибка была исправлена в рамках обновления 14.03.2017 как в Windows 10, так и в Windows Server 2016. Версия исправленного драйвера rdbss.sys — 10.0.14393.953 (04.03.2017).
Проблема
В процессе работы мне часто приходится обращаться к удалённым компьютерам через Remote Desktop. Иногда приходится копировать файлы туда/обратно; при этом бывает весьма полезна возможность обратиться к дискам моего компьютера из клиента RDP по пути вида \\tsclient\d. Также нужно упомянуть, что привык пользоваться FAR Manager.
После выпущенного в августе 2016 г обновления Windows Anniversary Update, в котором, как я надеялся, компания Microsoft исправит ряд своих ошибок, произошло обратное. При обращении к пути \\tsclient\d через FAR удалённая машина стала падать в синий экран. Конкретно виновным оказался драйвер rdbss.sys.
Проблема повторялась на раз-два-три, и дальнейшие тесты прекрасно проходили на виртуальных машинах с поставленной «с нуля» операционной системой. Виновник был чётко виден при просмотре дампа ядра.
BugCheck 27, {fcb0027c, ffffd5073f279eb8, ffffd5073f279af0, 0}
Page c920 not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : rdbss.sys ( rdbss! ?? ::FNODOBFM::`string'+1f09 )
nt!KeBugCheckEx
rdbss! ?? ::FNODOBFM::`string'+0x1f09 (в реальности RxSelectAndSwitchPagingFileObject)
rdbss!RxCommonClose+0x126
rdbss!RxFsdCommonDispatch+0x55b
rdbss!RxFsdDispatch+0x86
rdpdr!DrPeekDispatch+0x203
mup!MupStateMachine+0x1dc
mup!MupClose+0x8c
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x1a6
FLTMGR!FltpDispatch+0xb6
nt!IopDeleteFile+0x12d
nt!ObpRemoveObjectRoutine+0x78
nt!ObfDereferenceObjectWithTag+0xc6
nt!ObCloseHandleTableEntry+0x28f
nt!NtClose+0xcb
nt!KiSystemServiceCopyEnd+0x13
0x00007ffa`8c925034
Переписка
Что же, подумал я, обратимся в компанию Microsoft. Поскольку форм отправки сообщений по подобным поводам я не нашёл (а заводить платный support request как-то не хотелось), была создана тема в technet forum. В сообщении я описал последовательность воспроизведения проблемы и приложил анализ дампа Windows от WinDBG.
В результате получил ответ от модератора:
По данным вашего анализа, проблема связана с «rdbss.sys». Это драйвер подсистемы буферизации перенаправленного диска. Поскольку проблема наблюдается на любой машине, я подозреваю, драйвер несовместим с функционалом Windows 10 RDP. Вам лучше подтвердить это у разработчика данного программного обеспечения.
Попытка указать, что разработчиком модуля rdbss.sys в составе Windows 10 является компания Microsoft, не привели к успеху. «Обращайтесь к компании-разработчику; у меня нет возможности это проверять», пишет модератор, сотрудник Microsoft.
Здесь я подумал, что проблема повторяется и для непривилегированного пользователя (действительно), и решил написать в Microsoft Security Report. К отправке подобного сообщения Microsoft относится серьёзно — по электронной почте нужно отправить зашифрованное письмо (S-MIME или OpenPGP с ключом Microsoft), на которое дадут ответ в течении суток.
Действительно, ответ дали:
Видимо, эта проблема FAR Manager, а не Windows 10. Однако это нельзя считать проблемой безопасности, поскольку вы уже имеете доступ к системе и возможность выполнять код на машине.
На вопрос, нормально ли, если непривилегированный пользователь может вызвать BSOD, ответа не было.
Когда появились релизные сборки Window Server 2016, в которой повторилась данная проблема, я отправил ещё одно письмо, обращающее внимание на недопустимость подобного для серверной платформы. Ответ был аналогичным:
Спасибо за дополнительную информацию. К сожалению, это всё ещё похоже на проблему в FAR Manager. Также это могло бы являться DOS-атакой локально аутентифицированного пользователя, но мы не находим это достаточным для обеспечения поддержки в рамках задач безопасности.
Анализ
Ради интереса я посмотрел, проявляется ли эта проблема в других версиях Windows – оказывается, нет. Ни в Windows 10 1511, ни в Windows Server 2016 TP5 она не наблюдалась.
Краткий обзор кода в WinDBG выявил весьма интересную вещь. Функция RxSelectAndSwitchPagingFileObject, которая, собственно, и вызывала Bugcheck 0x27, не сильно изменилась по сравнению с Windows 10 1511. Но в предыдущей версии при обнаружении ошибок они просто игнорировалась, а в новой был явно добавлен вызов KeBugCheckEx. Видимо, разработчики никак не могли исправить какие-то свои баги и решили работать «по бразильской системе» — если что, то система просто упадёт, и тогда удастся найти причины каких-то внутренних (возможно, и не фатальных) ошибок.
Однако в реальности получается странная ситуация — пользователи находят данную ошибку и описывают последовательность её воспроизведения, а техническая поддержка стоит барьером — «это не наша проблема». До разработчиков, подозреваю, информация так и не доходит.
В Windows Server 2016 TP5, кстати, этой функции вообще не было. Однако в релизной версии она появилась и абсолютно также вызывает синий экран, как и в Windows 10 Anniversary. Стоит отметить, что с выхода Windows Anniversary Update было несколько обновлений модуля rdbss.sys, но данную проблему они не решили.
Со стороны FAR Manager ситуация такова, что он активно использует Native API, и для операций с каталогами использует не классические функции модуля kernel32 (FindFirstFile/FindNextFile), а функции модуля ntdll (NtQueryDirectoryFile). Возможно, здесь и получается какая-то неожиданная комбинация параметров/вызовов, которую разработчики rdbss.sys не учли (система падает на NtClose, когда идёт очистка открытого объекта файла).
Надеюсь, данная статья предупредит системных администраторов о новой напасти и позволит избежать неожиданных падений удалённых серверов. Также лелею жалкую надежду, что представители Microsoft, присутствующие на Harbahabr, донесут необходимую информацию до разработчиков rdbss.sys через стену «технической поддержки».
Самые серьёзные проблемы операционной системы Windows вызывают появление синего экрана, который ранее часто называли «синим экраном смерти». Выявить причину таких ошибок получается не всегда, поэтому пользователи предпочитают переустановку ОС. Чтобы помочь разобраться с этой проблемой, не прибегая к кардинальным способам решения, Microsoft опубликовала руководство, в котором разделила советы на базовые и расширенные.
Основные рекомендации по устранению синего экрана:
- Если вы подключили к ПК новое оборудование, удалите его. Перезагрузите ПК и проверьте, решена ли проблема.
- Запустите ПК в безопасном режиме. Это основной режим устранения неполадок ОС Windows. Чтобы перезагрузиться в безопасный режим, удерживайте клавишу Shift и выберите «Перезагрузка» в меню «Пуск».
- Проверьте наличие проблем в диспетчере устройств. Найдите записи с восклицательными знаками. Можно попробовать обновить драйвер, если это не поможет, тогда попробовать отключить или удалить устройство.
- Убедитесь, что на основном разделе жесткого диска достаточно свободного места. Microsoft рекомендует оставлять 10-15% от общего хранилища.
- Установите обновления ОС Windows.
Если ни один из вышеперечисленных способов не помог решить проблему, Microsoft рекомендует восстановить Windows с помощью одного из доступных вариантов.
Расширенные рекомендации по устранению синего экрана:
- Проверьте журнал «Просмотр событий» на наличие проблем. Запустить его можно, введя соответствующий запрос в поиск. В нём нужно поискать критические ошибки, которые произошли примерно в то же время, когда случился сбой.
- Убедитесь, что оперативная память не является причиной ошибки. Введите в поиск «Средство проверки памяти Windows» и запустите приложение. Проверьте результаты в системном журнале «Просмотр событий».
- Проанализируйте дамп памяти (для специалистов и продвинутых пользователей). Эта процедура подробно описана на сайте Microsoft.
Вся эта информация не является новой, хотя Microsoft только сейчас опубликовала её на сайте поддержки. Она может быть полезной неопытным пользователям, которые не знают, что делать при появлении синего экрана.
Источник
[the problem]
Establishing an Remote Desktop Connection via Remote Desktop Protocol (RDP) to another system using Windows 10 build 1709 causes the session to crash shortly after being created. The error given is generic. The event log shows that the faulting application name mstsc.exe version 10.0.16299.15 crashed with an exception code of 0x0000409 and because of module ntdll.dll version 10.0.16299.64.
Error: Remote Desktop Connection has stopped working
[the solution]
The issue is caused by a printer driver where when the affected printers are redirected as part of the RDP session, the session crashes unexpectedly.
- The long term fix should be to apply all missing updates and upgrade to the latest build.
- The short fix is to stop redirecting printers as part of the RDP connection profile.
That’s it.