Содержание
- Устранение неполадок с подключениями к Удаленному рабочему столу
- Проверка состояния протокола RDP
- Проверка состояния протокола RDP на локальном компьютере
- Проверка состояния протокола RDP на удаленном компьютере
- Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере
- Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере
- Изменение блокирующего объекта групповой политики
- Проверка состояния служб RDP
- Проверка состояния прослушивателя протокола RDP
- Проверка состояния прослушивателя RDP
- Проверка состояния самозаверяющего сертификата протокола RDP
- Проверка разрешений для папки MachineKeys
- Проверка порта прослушивателя протокола RDP
- Проверка того, что другое приложение не пытается использовать тот же порт
- Проверка блокировки порта протокола RDP брандмауэром
- Rdp закрывается после подключения windows 10
- Лучший отвечающий
- Вопрос
- Ответы
- Все ответы
- Rdp закрывается после подключения windows 10
- Вопрос
- Ответы
- Все ответы
- Rdp закрывается после подключения windows 10
- Вопрос
- Ответы
- Все ответы
Устранение неполадок с подключениями к Удаленному рабочему столу
Выполните приведенные ниже действия, если клиенту Удаленного рабочего стола не удается подключиться к удаленному рабочему столу, и отсутствуют сообщения или другие признаки, по которым можно определить причину.
Проверка состояния протокола RDP
Проверка состояния протокола RDP на локальном компьютере
Сведения о том, как проверить и изменить состояние протокола RDP на локальном компьютере, см. в разделе How to enable Remote Desktop (Как включить удаленный рабочий стол).
Проверка состояния протокола RDP на удаленном компьютере
В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.
Чтобы проверить и изменить состояние протокола удаленного рабочего стола на удаленном компьютере, используйте подключение сетевого реестра:
Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере
Если не удается включить протокол RDP в пользовательском интерфейсе или для fDenyTSConnections возвращается значение 1 после его изменения, объект групповой политики может переопределять параметры на уровне компьютера.
Чтобы проверить конфигурацию групповой политики на локальном компьютере, откройте окно командной строки с правами администратора и введите следующую команду:
Когда команда будет выполнена, откройте файл gpresult.html. Выберите Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовПодключения и найдите политику Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.
Если для параметра этой политики задано значение Включено, групповая политика не блокирует подключения по протоколу RDP.
Если же для параметра этой политики задано значение Отключено, проверьте результирующий объект групповой политики. Ниже показано, какой объект групповой политики блокирует подключения по протоколу RDP. 
Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере
Чтобы проверить конфигурацию групповой политики на удаленном компьютере, нужно выполнить почти такую же команду, что и для локального компьютера.
Изменение блокирующего объекта групповой политики
Эти параметры можно изменить в редакторе объектов групповой политики (GPE) и консоли управления групповыми политиками (GPM). Дополнительные сведения об использовании групповой политики см. в статье Advanced Group Policy Management (Расширенное управление групповыми политиками).
Чтобы изменить блокирующую политику, используйте один из следующих методов.
Проверка состояния служб RDP
На локальном компьютере (клиентском) и удаленном компьютере (целевом) должны быть запущены следующие службы:
Для локального или удаленного управления службами можно использовать оснастку MMC. Вы также можете использовать PowerShell для управления службами в локальном или удаленном расположении (если удаленный компьютер настроен для приема удаленных командлетов PowerShell).
На любом компьютере запустите одну или обе службы, если они запущены.
Если вы запускаете службу удаленных рабочих столов, нажмите кнопку Да, чтобы служба перенаправителя портов пользовательского режима служб удаленного рабочего стола перезапустилась автоматически.
Проверка состояния прослушивателя протокола RDP
В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.
Проверка состояния прослушивателя RDP
Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.
Чтобы подключиться к удаленному компьютеру, выполните следующий командлет:
Введите qwinsta. 
Если в списке содержится rdp-tcp с состоянием Listen, прослушиватель протокола удаленного рабочего стола работает. Перейдите к разделу Проверка порта прослушивателя протокола RDP. В противном случае перейдите к шагу 4.
Экспортируйте конфигурацию прослушивателя RDP с рабочего компьютера.
Чтобы импортировать конфигурацию прослушивателя протокола RDP, откройте окно PowerShell с разрешениями администратора на затронутом компьютере (или откройте окно PowerShell и подключитесь к этому компьютеру из удаленного расположения).
Чтобы создать резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:
Чтобы удалить резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:
Чтобы импортировать новую запись реестра и перезапустить службу, воспользуйтесь такими командлетами:
Замените именем экспортированного REG-файла.
Проверьте конфигурацию, попытавшись еще раз подключиться к удаленному рабочему столу. Если подключиться все равно не удается, перезагрузите затронутый компьютер.
Проверка состояния самозаверяющего сертификата протокола RDP
Проверка разрешений для папки MachineKeys
Проверка порта прослушивателя протокола RDP
На локальном компьютере (клиентском) и удаленном компьютере (целевом) прослушиватель протокола RDP должен ожидать передачи данных через порт 3389. Другие приложения не должны использовать этот порт.
В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.
Чтобы проверить или изменить порт протокола RDP, используйте редактор реестра:
Для управления службами удаленного рабочего стола можно использовать другой порт. Но мы не рекомендуем делать это. В этой статье не описано, как устранять проблемы, связанные с этим типом конфигурации.
Проверка того, что другое приложение не пытается использовать тот же порт
Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.
Введите следующую команду:
Найдите запись для TCP-порта 3389 (или назначенного RDP-порта) с состоянием Ожидает вызова.
Идентификатор процесса службы или процесса, использующих этот порт, отобразится в столбце «Идентификатор процесса».
Чтобы определить, какое приложение использует порт 3389 (или назначенный порт протокола RDP), введите следующую команду:
Найдите запись для номера процесса, связанного с портом (в выходных данных netstat). Службы или процессы, связанные с этим идентификатором процесса, отобразятся в столбце справа.
Если порт используется приложением или службой, отличающейся от служб удаленных рабочих столов (TermServ.exe), устранить конфликт можно с помощью одного из следующих методов:
Проверка блокировки порта протокола RDP брандмауэром
С помощью средства psping проверьте, доступен ли затронутый компьютер через порт 3389.
Перейдите на другой компьютер, на котором такая проблема не возникает, и скачайте psping отсюда: https://live.sysinternals.com/psping.exe.
Откройте окно командной строки с правами администратора, перейдите в каталог, где установлено средство psping, и введите следующую команду:
Проверьте выходные данные команды psping на наличие таких результатов:
Запустите psping на нескольких компьютерах, чтобы проверить возможность подключения к затронутому компьютеру.
Проверьте, блокирует ли этот компьютер подключения от всех остальных компьютеров, некоторых других компьютеров или только одного компьютера.
Рекомендуемые дальнейшие действия:
Источник
Rdp закрывается после подключения windows 10
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Проблема в LAN сети комы воткнуты в один коммутатор.
Сначало не запускалась служба termsrv.dll
Заменил файл с другого компа той же марки(фирменный) и тот же ОС (Windows 7 Проф. x86)
Сейчас наблюдается такая картина, заходишь или на менее чем на 1 сек показывается раб. стол или сразу выкидывает без какой либо ошибки.
Пробовалось с разных ОС и машин, ситуация аналогичная!
Ответы
Все ответы
В журнале событий смотрели, регистрируется что-нибудь по этому поводу?
Проблема изначально, или раньше все работало нормально?
Проверку целостности системных файлов выполняли? (sfc /scannow от админа в cmd)
Установлены ли все последние обновления, RDP версии 8.1?
Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий.
на ошибки дсики проверял, Все ОК!
sfc проверял, но он говорит что то то не удалсь все востановить.
проблема выше наиписал когада началась, до этого не было.Правда как раз еще до этого обновления не поставились и шел длительный возврат к предыддущей версии.
В системном журнале видно «аудит входа» и тут же «аудит выхода»! Больше ничего не узрел!
sfc проверял, но он говорит что то то не удалсь все востановить.
Приложите в следующем сообщение результат выполнения следующего вызова:
Попробуйте исправить возникшую ситуацию сторонней утилитой SFCFix.exe и сообщите результат выполнения.
Важно перед запуском утилит со сторонних ресурсов проверяйте их на наличие вирусов.
sfc проверял, но он говорит что то то не удалсь все востановить.
Приложите в следующем сообщение результат выполнения следующего вызова:
Попробуйте исправить возникшую ситуацию сторонней утилитой SFCFix.exe и сообщите результат выполнения.
Важно перед запуском утилит со сторонних ресурсов проверяйте их на наличие вирусов.
Попытался выполнить данные команды
1-ой команды log http://rghost.net/6qqdzygzM
2-ой команды log или типа того(вывод результатов) http://rghost.net/7jxjrpHHS
но для в 2-ой команды диска дистрибутива Windows не было пока под рукой
хотя DaemonTools Lite дистрибутив лиц. подсовывал, но он ничего не сделал.(В eng. увы не силен)
Какие будут рекомендации, т.к. еще раз пробовал sfc /scannow без резульатов, на компе только админы,юзеров акк. нет.
2-ой команды log или типа того(вывод результатов) http://rghost.net/7jxjrpHHS
но для в 2-ой команды диска дистрибутива Windows не было пока под рукой
Уточните пожалуйста, запускали утилиту SFCFix в привилегированном режиме (Run as Administrator)?
У Вас имеются повреждения в образе, и да также не соответствует/поврежден termsrv.dll.
Попробуйте вспомнить какие действия Вами были произведены перед возникновением проблемы описанной Выше.
Я на машине админ, но на всякий запутстил от Администратора,результат тот же!
Была поптыка выполнить обновления с помощбю проекта UpdatePack7 для Windows 7 SP1
После 1-ой установки и перезагрузки долго устанваливались 100% висело минут 10.
Было решено ребутнуть(зря), и еще раз так же. Далее начался откат обновленией и это было минимум час.
Я заменял вручную из дистибутива файла install.win файл termsrv.dll но результат тот же.
sfc /scannow так же говорит что проверено все 100%, но не все востановлено!
Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить
некоторые из них.
Сведения см. в журнале CBS.log windirLogsCBSCBS.log. Например:
C:WindowsLogsCBSCBS.log
Все средства востановления системы(точки востанвления, бекапы, корзины) отключены были сразу после установки(через интерфейс) ОС.
Источник
Rdp закрывается после подключения windows 10
Вопрос
Помогает подождать пару мин и войти заново с паролем.
В какую сторону копать?
В журнале событий обнаружил следующие сведения в этот период:
Удаленные вызовы 2 к базе данных SAM были отклонены за прошлые 1200 сек регулирования окна.
Для получения дополнительных сведений см. http://go.microsoft.com/fwlink/?LinkId=787651.
Ответы
Все ответы
Убедитесь, чтобы у Вас были установлены актуальные графические драйвера.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Драйвера последние. Скачанные с сайта Nvidia.
Попробую установить другую версию
Удалил существующие драйвера на видеокарту Nvidia. Стало гораздо лучше. Наблюдаю.
Удалил существующие драйвера на видеокарту Nvidia. Стало гораздо лучше. Наблюдаю.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Заменил на версию что предоставила Nvidia 21.21.13.4201.
Драйвера что были до удаления установились автоматически с windows.
Не помогло. Сегодня вечером словил ту же ошибку.
На днях попробую поработать на встроенной видеокарте Intel. Отпишу о результатах
Пробовали обновить биос на вашем оборудовании? Так же вы не ответили используются ли принтеры на ней. Пробовали на ней выполнить sfc /scannow && Dism /online /cleanup-image /restorehealth && Dism.exe /Online /Cleanup-Image /StartComponentCleanup && ChkDsk /r
Так же советую почитать еще возможные варианты решения вот тут.
Модератор: Ссылка на сайт с пиратским контентом удалена.
BIOS обновлен до последней версии.
Я не понял совет изначально. Я установил приложение «Удаленный рабочий стол (Майкрософт)» на компьютер к которому я подключаюсь. И ничего не изменилось.
Вопрос: при использовании «Удаленный рабочий стол (Майкрософт)» экран «размыт» при подключении (изменение параметров разрешения в настройках программы не очень помогает). Как быть?
Источник
Rdp закрывается после подключения windows 10
Вопрос
Помогает подождать пару мин и войти заново с паролем.
В какую сторону копать?
В журнале событий обнаружил следующие сведения в этот период:
Удаленные вызовы 2 к базе данных SAM были отклонены за прошлые 1200 сек регулирования окна.
Для получения дополнительных сведений см. http://go.microsoft.com/fwlink/?LinkId=787651.
Ответы
Все ответы
Убедитесь, чтобы у Вас были установлены актуальные графические драйвера.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Драйвера последние. Скачанные с сайта Nvidia.
Попробую установить другую версию
Удалил существующие драйвера на видеокарту Nvidia. Стало гораздо лучше. Наблюдаю.
Удалил существующие драйвера на видеокарту Nvidia. Стало гораздо лучше. Наблюдаю.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Заменил на версию что предоставила Nvidia 21.21.13.4201.
Драйвера что были до удаления установились автоматически с windows.
Не помогло. Сегодня вечером словил ту же ошибку.
На днях попробую поработать на встроенной видеокарте Intel. Отпишу о результатах
Пробовали обновить биос на вашем оборудовании? Так же вы не ответили используются ли принтеры на ней. Пробовали на ней выполнить sfc /scannow && Dism /online /cleanup-image /restorehealth && Dism.exe /Online /Cleanup-Image /StartComponentCleanup && ChkDsk /r
Так же советую почитать еще возможные варианты решения вот тут.
Модератор: Ссылка на сайт с пиратским контентом удалена.
BIOS обновлен до последней версии.
Я не понял совет изначально. Я установил приложение «Удаленный рабочий стол (Майкрософт)» на компьютер к которому я подключаюсь. И ничего не изменилось.
Вопрос: при использовании «Удаленный рабочий стол (Майкрософт)» экран «размыт» при подключении (изменение параметров разрешения в настройках программы не очень помогает). Как быть?
Источник
Я обновился до Windows 10 на ПК дома. Но теперь всякий раз, когда я RDP к нему, и нажмите Отключить, вместо этого он выходит из системы. Поэтому, когда я снова подключаюсь, он снова входит в систему, и все открытые приложения закрываются.
Я уже проверил настройки в реестре, и время ожидания никогда.
В Windows 7 этого не произошло, и я мог отключиться и оставаться в системе.
Может кто-нибудь помочь, пожалуйста?
Я попытался закрыть RDP на виртуальной машине Windows 10, и я не могу продублировать вашу проблему.
Возможно, разница в том, что я применил это исправление реестра, потому что я получал сообщение «соединение не может быть установлено, потому что аутентификация не включена»:
В Windows 10 Microsoft изменила настройки RDP по умолчанию. Они изменили значение по умолчанию для
SecurityLayerс 0 до 2. Даже если вы войдете в пользовательский интерфейс и отключите: «Разрешить подключения только с компьютеров, на которых запущен удаленный рабочий стол с аутентификацией на уровне сети (рекомендуется)», это значение по-прежнему не меняется на 2.Простое исправление:
- Открыть RegEdit
- Перейдите к этому ключу:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminalServerWinStationsRDP-Tcp- Измените
SecurityLayerна ноль- Перезагрузка и готово
Отключите политики «Ограничения времени сеанса» на ПК с Windows 10 дома.
- Откройте
gpedit.msc - Перейдите к:
Конфигурация компьютера Административные шаблоны Компоненты Windows Службы удаленных рабочих столов Узел сеансов удаленных рабочих столов Ограничения по времени сеансов - Отключите любые активные политики.
- Перейдите к:
Конфигурация пользователя Административные шаблоны Компоненты Windows Службы удаленных рабочих столов Узел сеансов удаленных рабочих столов Ограничения по времени сеансов - Отключите любые активные политики.
- Перезагрузите компьютер.
Вместо отключения просто закройте приложение RDP. Это позволит вам войти в систему на удаленном компьютере.
Кроме того, вы заметите, что перезагрузка и выключение не являются частью ваших возможностей. Это вам придется обработать командой shutdown.
Я полагаю, что это проблема Windows 10, или, возможно, Microsoft назовет это исправлением, так как это предотвращает мертвые сеансы и потенциально останавливает вход других пользователей из-за истечения срока действия лицензий TS.
Вы можете попробовать последнюю версию клиента удаленного рабочего стола здесь:https://support.microsoft.com/en-us/kb/2923545, если вы находитесь на предварительном просмотре инсайдера и установили последнее обновление, удалите последнее обновление, у меня было много проблем IMHO. Если нет, проверьте, есть ли в Windows последние исправления.
- Remove From My Forums
-
Общие обсуждения
-
Добрый вечер! Появилась проблема с RDP сессией на одном из компьютеров. Подключение проходит как обычно, в штатном режиме, однако после 10-20 секунд сессии приложение закрывается с ошибкой.
Сигнатура проблемы:
Имя события проблемы: APPCRASH
Имя приложения: mstsc.exe
Версия приложения: 6.1.7601.18540
Отметка времени приложения: 53c720ab
Имя модуля с ошибкой: StackHash_d13e
Версия модуля с ошибкой: 6.1.7601.19018
Отметка времени модуля с ошибкой: 5609fdaf
Код исключения: c0000374
Смещение исключения: 000c3f83
Версия ОС: 6.1.7601.2.1.0.256.48
Код языка: 1049
Дополнительные сведения 1: d13e
Дополнительные сведения 2: d13e264c2f42a8858e639f780c6a652c
Дополнительные сведения 3: 64a8
Дополнительные сведения 4: 64a881467867dc2b349b8d4634ef1cd2Ознакомьтесь с заявлением о конфиденциальности в Интернете:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0419Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:
C:Windowssystem32ru-RUerofflps.txtЗаметил, что в разделе «имя модуля с ошибкой» значение после «StackHash» постоянно разные.
Проверил системные файлы стандартными методами, установил последние обновления — не работает.
Помогите решить проблему, переустанавливать не вариант…
-
Изменен тип
12 ноября 2015 г. 8:28
Тема переведена в разряд обсуждений по причине отсутствия активности
-
Изменен тип
This is my xrdp config:
[Globals]
ini_version=1
fork=true
port=3389
use_vsock=false
tcp_nodelay=true
tcp_keepalive=true
security_layer=negotiate
crypt_level=high
certificate=
key_file=
ssl_protocols=TLSv1.2, TLSv1.3
autorun=
allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
max_bpp=128
use_compression=yes
new_cursors=true
use_fastpath=both
blue=009cb5
grey=dedede
ls_top_window_bg_color=009cb5
ls_width=350
ls_height=430
ls_bg_color=dedede
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50
ls_label_x_pos=30
ls_label_width=65
ls_input_x_pos=110
ls_input_width=210
ls_input_y_pos=220
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30
[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
[Channels]
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true
[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20
I am trying to connect with mstsc to this machine (this is after fresh pc restart, noone has logged in):
while in this login box, no disconnect happens:
after I put there correct login/password, I get black screen first and then mstsc window closes. I tried to connect from KDE remote connection application, but it also failed same way. xrdp.log doesn’t seem to contain anything interesting:
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
[20190606-04:14:36] [DEBUG] return value from xrdp_mm_connect 0
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC started connecting
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connecting to 127.0.0.1 5910
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC tcp connected
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC security level is 2 (1 = none, 2 = standard)
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC password ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending share flag
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving server init
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name length
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending encodings
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending framebuffer update request
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending cursor
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connection complete, connected ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connected ok
[20190606-04:14:36] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
[20190606-04:14:36] [DEBUG] Closed socket 18 (AF_INET 127.0.0.1:47744)
[20190606-04:14:37] [DEBUG] Closed socket 20 (AF_UNIX)
[20190606-04:14:37] [DEBUG] Closed socket 12 (AF_INET 127.0.0.1:3389)
[20190606-04:14:37] [DEBUG] xrdp_mm_module_cleanup
[20190606-04:14:37] [DEBUG] VNC mod_exit
[20190606-04:14:37] [DEBUG] Closed socket 19 (AF_INET 127.0.0.1:40224)
How can I fix that?
asked Jun 5, 2019 at 21:18
3
Try this:
Stop xrdp with
sudo service xrdp stop
Edit the xrdp start script:
sudo nano /etc/xrdp/startwm.sh
In this file, replace the lines
test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession
with
startxfce4
(You can comment out lines by adding # at the start)
Restart xrdp with
sudo service xrdp start
Select Xrdp as the session, and log in.
answered Jan 20, 2021 at 21:26
The Bic PenThe Bic Pen
4034 silver badges6 bronze badges
5
I solved the issue myself, hopefully someone else will find it usefull. I took a look at ~/.xsession-errors, it contained:
(imsettings-check:16467): IMSettings-WARNING **: 04:42:56.491: Could not connect: Connection refused
(imsettings-check:16467): GLib-GIO-CRITICAL **: 04:42:56.491: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed
GLib-GIO-Message: 04:42:56.807: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
** (process:16260): WARNING **: 04:42:56.824: Could not make bus activated clients aware of XDG_CURRENT_DESKTOP=GNOME environment variable: Could not connect: Connection refused
and then I’ve googled a rootcause, miniconda installation has broken PATH in .bashrc file, I have removed this line and it has fixed it:
export PATH="/home/stiv/miniconda3/bin:$PATH"
UPDATE: Later I’ve found x2go, which works way more reliable and faster then XRDP.
answered Jun 5, 2019 at 21:48
stivstiv
1,3315 gold badges19 silver badges32 bronze badges
6
-
sudo apt-get update -
sudo apt install xrdp -
sudo apt-get install xserver-xorg-core -
sudo apt-get install xorgxrdp -
nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf -
Copy the polkit below to
02-allow-colord.conf
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.color-manager.create-device" || action.id == "org.freedesktop.color-manager.create-profile" || action.id == "org.freedesktop.color-manager.delete-device" || action.id == "org.freedesktop.color-manager.delete-profile" || action.id == "org.freedesktop.color-manager.modify-device" || action.id == "org.freedesktop.color-manager.modify-profile") && subject.isInGroup("{group}"))
{
return polkit.Result.YES;
}
});
-
sudo ufw allow 3389/tcp -
sudo /etc/init.d/xrdp restart -
sudo systemctl status xrdp -
sudo systemctl enable xrdp -
Log out of your session.
-
Try with RDP
answered Dec 6, 2019 at 15:07
3
The user account you are trying this with, are they a member of the sudo or wheel groups? With Kali 2020 edition, any user that is apart of sudo will disconnect immediately, I had to kill all processes of that user ( pkill -u <username> ) and then delete the user account and recreate it. I am still tracking down the exact reason why this is occurring when I have time. But thought I share my experience.
αғsнιη
39.8k15 gold badges67 silver badges110 bronze badges
answered Dec 12, 2020 at 17:26
2
You must do following additional actions:
To Configure Xrdp, first add
exec gnome-session
to the end of the configuration file
/etc/xrdp/xrdp.ini
Or use following command to add “exec gnome-session” to the end of the “/etc/xrdp/xrdp.ini” configuration file
sudo bash -c 'echo "exec gnome-session" >> /etc/xrdp/xrdp.ini'
Restart xrdp to load the new configuration
sudo systemctl restart xrdp
Reference:
How to: Install Xrdp (Remote Desktop) on CentOS 8 – (How to: Use Windows to remote control CentOS 
answered May 2, 2021 at 9:51
1
I came across this issue trying to connect to a work machine running xrdp on red hat enterprise Linux 7. I had installed miniconda and datalad in its base environment in my home folder on the remote machine and that broke windows remote desktop. The solution was surprisingly simple. I uninstalled datalad and reinstalled it in a new environment via SSH. I was then able to reconnect to the machine via windows remote desktop without any issues.
answered Apr 27, 2021 at 18:02
I have spent many days over the past few years with the intermittent problems of accessing a Linux server from a Windows 10 PC. Different approaches to Server xrdp.ini modifications appear to straighten out the issue, but non permanently. After failing with fresh RHEL8 and Centos8 installs, all failing with a PC RDP logon, I observed the following common error. After a fail from the PC, the error, observed from a «semi» successful re-logon from the same PC was observable in systemctl status xrdp which presents the litany of the failed items.
However, when observed directly on the server itself using a screen, keyboard and mouse( I have the Dell R430 in next to me), the systemctl status xrdp, appears clean with no problems.
Each fresh logon to RDP, with Xvnc, apparently launches a separate rdp session/process.
The conclusion I have reached is that the problem is focused on the PC and somehow a SSL failure. It is persistent on the PC UNTIL IT IS rebooted.
The server does not require a restart.
Of course, REBOOTING the PC is impractical, but it is repeatedly successful.
answered Jun 1, 2021 at 14:18
I troubleshooted this too, and, it seems that just installing the xrdp package on it’s own is not enough, because (1) dependent packages will not get installed, (2) startwm.sh issues. I didn’t arrive at a perfect solution. I notice one of the other answers is using xfce4 which I would like to use to. In the end, I defaulted to something more lightweight, i.e. icewm, i.e.
sudo yum update
sudo yum install xrdp
sudo yum install tigervnc-server
sudo yum install xterm
sudo yum install icewm
sudo vi /usr/libexec/xrdp/startwm.sh
And, effectively, my startwm.sh script has the following at the top, i.e. I’ve circumvented or replaced the default behavior:
#!/bin/bash -xe
/bin/xterm &
exec /bin/icewm
answered Jul 20, 2021 at 23:08
This is my xrdp config:
[Globals]
ini_version=1
fork=true
port=3389
use_vsock=false
tcp_nodelay=true
tcp_keepalive=true
security_layer=negotiate
crypt_level=high
certificate=
key_file=
ssl_protocols=TLSv1.2, TLSv1.3
autorun=
allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
max_bpp=128
use_compression=yes
new_cursors=true
use_fastpath=both
blue=009cb5
grey=dedede
ls_top_window_bg_color=009cb5
ls_width=350
ls_height=430
ls_bg_color=dedede
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50
ls_label_x_pos=30
ls_label_width=65
ls_input_x_pos=110
ls_input_width=210
ls_input_y_pos=220
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30
[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
[Channels]
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true
[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20
I am trying to connect with mstsc to this machine (this is after fresh pc restart, noone has logged in):
while in this login box, no disconnect happens:
after I put there correct login/password, I get black screen first and then mstsc window closes. I tried to connect from KDE remote connection application, but it also failed same way. xrdp.log doesn’t seem to contain anything interesting:
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
[20190606-04:14:36] [DEBUG] return value from xrdp_mm_connect 0
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC started connecting
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connecting to 127.0.0.1 5910
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC tcp connected
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC security level is 2 (1 = none, 2 = standard)
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC password ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending share flag
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving server init
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name length
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending encodings
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending framebuffer update request
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending cursor
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connection complete, connected ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connected ok
[20190606-04:14:36] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
[20190606-04:14:36] [DEBUG] Closed socket 18 (AF_INET 127.0.0.1:47744)
[20190606-04:14:37] [DEBUG] Closed socket 20 (AF_UNIX)
[20190606-04:14:37] [DEBUG] Closed socket 12 (AF_INET 127.0.0.1:3389)
[20190606-04:14:37] [DEBUG] xrdp_mm_module_cleanup
[20190606-04:14:37] [DEBUG] VNC mod_exit
[20190606-04:14:37] [DEBUG] Closed socket 19 (AF_INET 127.0.0.1:40224)
How can I fix that?
asked Jun 5, 2019 at 21:18
3
Try this:
Stop xrdp with
sudo service xrdp stop
Edit the xrdp start script:
sudo nano /etc/xrdp/startwm.sh
In this file, replace the lines
test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession
with
startxfce4
(You can comment out lines by adding # at the start)
Restart xrdp with
sudo service xrdp start
Select Xrdp as the session, and log in.
answered Jan 20, 2021 at 21:26
The Bic PenThe Bic Pen
4034 silver badges6 bronze badges
5
I solved the issue myself, hopefully someone else will find it usefull. I took a look at ~/.xsession-errors, it contained:
(imsettings-check:16467): IMSettings-WARNING **: 04:42:56.491: Could not connect: Connection refused
(imsettings-check:16467): GLib-GIO-CRITICAL **: 04:42:56.491: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed
GLib-GIO-Message: 04:42:56.807: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
** (process:16260): WARNING **: 04:42:56.824: Could not make bus activated clients aware of XDG_CURRENT_DESKTOP=GNOME environment variable: Could not connect: Connection refused
and then I’ve googled a rootcause, miniconda installation has broken PATH in .bashrc file, I have removed this line and it has fixed it:
export PATH="/home/stiv/miniconda3/bin:$PATH"
UPDATE: Later I’ve found x2go, which works way more reliable and faster then XRDP.
answered Jun 5, 2019 at 21:48
stivstiv
1,3315 gold badges19 silver badges32 bronze badges
6
-
sudo apt-get update -
sudo apt install xrdp -
sudo apt-get install xserver-xorg-core -
sudo apt-get install xorgxrdp -
nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf -
Copy the polkit below to
02-allow-colord.conf
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.color-manager.create-device" || action.id == "org.freedesktop.color-manager.create-profile" || action.id == "org.freedesktop.color-manager.delete-device" || action.id == "org.freedesktop.color-manager.delete-profile" || action.id == "org.freedesktop.color-manager.modify-device" || action.id == "org.freedesktop.color-manager.modify-profile") && subject.isInGroup("{group}"))
{
return polkit.Result.YES;
}
});
-
sudo ufw allow 3389/tcp -
sudo /etc/init.d/xrdp restart -
sudo systemctl status xrdp -
sudo systemctl enable xrdp -
Log out of your session.
-
Try with RDP
answered Dec 6, 2019 at 15:07
3
The user account you are trying this with, are they a member of the sudo or wheel groups? With Kali 2020 edition, any user that is apart of sudo will disconnect immediately, I had to kill all processes of that user ( pkill -u <username> ) and then delete the user account and recreate it. I am still tracking down the exact reason why this is occurring when I have time. But thought I share my experience.
αғsнιη
39.8k15 gold badges67 silver badges110 bronze badges
answered Dec 12, 2020 at 17:26
2
You must do following additional actions:
To Configure Xrdp, first add
exec gnome-session
to the end of the configuration file
/etc/xrdp/xrdp.ini
Or use following command to add “exec gnome-session” to the end of the “/etc/xrdp/xrdp.ini” configuration file
sudo bash -c 'echo "exec gnome-session" >> /etc/xrdp/xrdp.ini'
Restart xrdp to load the new configuration
sudo systemctl restart xrdp
Reference:
How to: Install Xrdp (Remote Desktop) on CentOS 8 – (How to: Use Windows to remote control CentOS
answered May 2, 2021 at 9:51
1
I came across this issue trying to connect to a work machine running xrdp on red hat enterprise Linux 7. I had installed miniconda and datalad in its base environment in my home folder on the remote machine and that broke windows remote desktop. The solution was surprisingly simple. I uninstalled datalad and reinstalled it in a new environment via SSH. I was then able to reconnect to the machine via windows remote desktop without any issues.
answered Apr 27, 2021 at 18:02
I have spent many days over the past few years with the intermittent problems of accessing a Linux server from a Windows 10 PC. Different approaches to Server xrdp.ini modifications appear to straighten out the issue, but non permanently. After failing with fresh RHEL8 and Centos8 installs, all failing with a PC RDP logon, I observed the following common error. After a fail from the PC, the error, observed from a «semi» successful re-logon from the same PC was observable in systemctl status xrdp which presents the litany of the failed items.
However, when observed directly on the server itself using a screen, keyboard and mouse( I have the Dell R430 in next to me), the systemctl status xrdp, appears clean with no problems.
Each fresh logon to RDP, with Xvnc, apparently launches a separate rdp session/process.
The conclusion I have reached is that the problem is focused on the PC and somehow a SSL failure. It is persistent on the PC UNTIL IT IS rebooted.
The server does not require a restart.
Of course, REBOOTING the PC is impractical, but it is repeatedly successful.
answered Jun 1, 2021 at 14:18
I troubleshooted this too, and, it seems that just installing the xrdp package on it’s own is not enough, because (1) dependent packages will not get installed, (2) startwm.sh issues. I didn’t arrive at a perfect solution. I notice one of the other answers is using xfce4 which I would like to use to. In the end, I defaulted to something more lightweight, i.e. icewm, i.e.
sudo yum update
sudo yum install xrdp
sudo yum install tigervnc-server
sudo yum install xterm
sudo yum install icewm
sudo vi /usr/libexec/xrdp/startwm.sh
And, effectively, my startwm.sh script has the following at the top, i.e. I’ve circumvented or replaced the default behavior:
#!/bin/bash -xe
/bin/xterm &
exec /bin/icewm
answered Jul 20, 2021 at 23:08
Пытаюсь настроить RemoteApp для удаленного запуска Maya на тормозном ноуте, но после тщательной настройки, приложение все равно не запускается.
В журнале RemoteConnectionManager пишет, что произошла Успешная проверка подлинности пользователя (1149). В журнале безопасности:
- Специальный вход (4672)
- Вход в систему (4624)
- Выход из системы (4634) через секунду.
Чет уже хз где дальше смотреть… Версия RDP на хосте — 6.1, ось — Win7x64 Ultimate.
Upd: [РЕШЕНО]
«Важное дополнение к этому способу: «Столкнулся с проблемой. Всё сделал по инструкции, запустил батник, всё установилось хорошо. Подключаюсь со второго компьютера — тут же сбрасывает. Закинул старый файл, всё стало как было изначально (работать может только один пользователь). Нашел обновление, которое содержало файл termsrv.dll. Путем вычислений оказалось, что при установке обновления KB2984972 возможность работы нескольких пользователей оказывается невозможной. Вдруг кому пригодится.»