Содержание
- Error code 0x102 rdp
- Описание проблемы
- 🆘 Что есть в логах?
- Исправляем ошибку «Произошла внутренняя ошибка»
- Дополнительные методы решения
- Дополнительные настройки RDP клиента
- Удаление кэша подключений
- Обновление 07.12.2022
- Временное решение
- Решено проблема с remote desktop
- akbars
- akbars
- NanoSuit
Error code 0x102 rdp
Добрый день! Уважаемые читатели и гости, IT блога Pyatilistnik.org. В прошлый раз мы с вами поговорили, про отложенный запуск служб в Windows, сегодня я хочу вам показать еще один не приятный момент в работе терминальных служб удаленного рабочего стола, а именно ошибка подключения «Произошла внутренняя ошибка«, после чего подключение разрывается. Такое я встречал уже в Windows Server 2012 R2 и 2016. Давайте разбираться в чем дело.
Описание проблемы
Есть сервер с операционной системой Windows Server 2012 R2, сотрудник пытается к нему подключиться, через классическую утилиту «Подключение к удаленному рабочему столу», в момент авторизации, выскакивает окно с ошибкой «Произошла внутренняя ошибка».
В английском варианте ошибка звучит вот так:
После этого у вас разрывается соединение. Когда мы видели моргающий экран по RDP, там хотя бы вы попадали на сервер и могли открыть диспетчер устройств, тут сразу все обрубается на корню. Давайте смотреть, что можно сделать.
🆘 Что есть в логах?
Если посмотреть журналы событий на удаленном сервере, куда вы пытаетесь подключиться, то там порядок событий будет такой:
- 1️⃣ Первым будет идти событие ID 131 «The server accepted a new TCP connection from client IP-адрес:60050.». Тут вы увидите IP-адрес с которого идет попытка входа.
- 2️⃣ Далее событие ID 65 «Connection RDP-Tcp#11 created «.
- 3️⃣ Затем событие 141 «PerfCounter session started with instance ID 11». Тут сессии будет назначен ID.
- 4️⃣ За ним будет идти ID 142 «TCP socket READ operation failed, error 1236».
- 5️⃣ Потом вы увидите ID 72 «Interface method called: OnDisconnected»
- 6️⃣ И же после этого вам покажут, что сервер разорвал подключение: «ID 102 The server has terminated main RDP connection with the client.»
- 7️⃣ В событии ID 145 так же появляются подробности «During this connection, server has not sent data or graphics update for 0 seconds (Idle1: 0, Idle2: 0).».
- 8️⃣ Могут быть события с ID 148 «Channel rdpinpt has been closed between the server and the client on transport tunnel: 0.» или «Channel rdpcmd has been closed between the server and the client on transport tunnel: 0.» или «Channel rdplic has been closed between the server and the client on transport tunnel: 0.»
- 9️⃣ Ну и вишенка на торте, ошибка ID 227 «‘Failed to get property Disconnect Reason’ in CUMRDPConnection::Close at 2212 err=[0x80070057]»
Исправляем ошибку «Произошла внутренняя ошибка»
Так как по RDP подключиться не получается, то первым делом нужно проверить отвечает ли порт, по умолчанию это 3389. О том, как проверить порт на удаленном сервере я вам описывал, там все сводилось к выполнению команды Telnet, ознакомьтесь. Если порт отвечает, то делаем следующее.
Нужно удаленно перезапустить службу на этом сервере, чтобы сам сервер не перезагружать, так как в этот момент, он может выполнять важные задачи, можно использовать утилиту «Управление компьютером». Открыть ее можно через команду вызова оснастки, вызываем окно «Выполнить», через одновременное нажатие клавиш WIN и R, в котором пишем:
В открывшейся оснастке, щелкните в самом верху по пункту «Управление компьютером» правым кликом мыши, и выберите пункт «Подключиться к удаленному компьютеру».
Выберите пункт «Другим компьютером» и укажите его DNS имя, или найдите его через кнопку обзор.
Когда вы подключитесь к нужному серверу, перейдите в пункт «Службы и приложения — Службы», в списке сервисов найдите службу удаленных рабочих столов (Remote Desktop Services), и перезапускаем ее. После этого ошибка подключения по RDP «Произошла внутренняя ошибка», у вас должна пропасть.
Так же вы можете использовать оболочку PowerShell запущенную от имени пользователя, у которого есть права на удаленный сервер, где будет перезапускаться служба RDP. Выполните:
Дополнительные методы решения
Если вам не помог первый метод, перезапускающий службу удаленных рабочих столов, то можно попробовать выполнить правку реестра. Открываете редактор реестра Windows, если у вас физического доступа к серверу нет или он далеко и вам лень до него идти, то можно попробовать подключиться к реестру удаленного сервера.
Для этого в окне «Редактор реестра» пункт меню «Файл — Подключить сетевой реестр».
В открывшемся окне «Выбор компьютера» указываем его DNS-имя или ip-адрес и нажимаем ок. У вас будет установлено подключение к удаленному реестру сервера, что испытывает проблемы.
Находим ключ CheckMode по пути
Выставляем ему значение о, чтобы отключить у программы КриптоПРО CSP проверку контрольных сумм. Еще один важный момент, если у вас старая версия КриптоПРО, то это так же может быть источником, проблем, недавний пример, это ошибка «Windows installer service could not be accessed». Для этого удаляем правильно КриптоПРО CSP и ставим последнюю доступную версию.
Еще можно попробовать изменить значение вот такого ключа реестра:
Найдите ключ SessionImageSize и задайте ему значение 0x00000020.
Дополнительные настройки RDP клиента
Например ошибка «An internal error has occurred» у меня встретилась на Windows Server 2022 и там мне помогло в настройках клиента RDP отключение некой опции. Перейдите в дополнительные настройки клиента для удаленного подключения, где н вкладке «Experiens (Взаимодействие)» вам нужно убрать галку с опции «Восстановить подключение при разрыве (Reconnect if the connection is droped)«
На каких-то сайтах предлагалось именно активировать данный пункт.
Удаление кэша подключений
Еще одним методом решения внутренней ошибки подключения по RDP может выступать поврежденный кэш, который хранится на локальном компьютере пользователя. Для его отображения вам необходимо включить отображение скрытых папок и удалить содержимое папки:
Обновление 07.12.2022
В декабре я вновь столкнулся с внутренней ошибкой, она еще стала проявлять себя вот так:
В логах сервера очень много ошибок:
Она возникает, при каждой попытке войти на рабочий стол, это и есть проблема в моем конкретном случае. Устраните ее, и ошибка с подключекнием уйдет . Перезагрузка не нужна.
На клиентской машине откуда я пытался произвести подключение было три события:
Код 2808 — Ваш сеанс служб удаленных рабочих столов завершен. Соединение с удаленным компьютером было потеряно, возможно, из-за проблем с сетевым подключением. Попробуйте снова подключиться к удаленному компьютеру. Если проблема не исчезнет, обратитесь к сетевому администратору или в службу технической поддержки.
Так как у меня это была виртуальная машина, то я смог легко подключиться через консоль. В случае с ошибкой «Отключение RDP ClientActiveX (Причина= 2308)«, я отключил на сервере и клиенте autotuninglevel:
Не забываем перезагрузиться.
Это не помогло, далее я выполнил еще несколько рекомендаций. Я установил на сервер валидный SSL сертификат для RDP сессии. В ошибке 0x907, RDP соединение разрывалось, так как клиентская система не доверяла самоподписному сертификату удаленного сервера. Это нужно поправить, ссылку я указал, обязательно проверьте, кто сейчас выступает в роли активного:
Еще я создал параметр реестра MaxOutstandingConnections. В Windows по умолчанию есть ограничения на количество сетевых подключений, так например в серверной версии, это параметр равен 3000, в десктопной 100. Из-за нестабильной сети, они могут быстро забиваться. Одно из решений проблемы с внутренней ошибкой подключения, является увеличение этого значения. В командной строке в режиме администратора выполните:
New-ItemProperty -Path «HKLM:SYSTEMCurrentControlSetControlTerminal Server»
-Name MaxOutstandingConnections -Value 10000 -PropertyType DWORD -Force
После этого нужно перезагрузиться.
Временное решение
Пока вы не уберете ошибку «Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D», описанную выше, вы можете понизить уровень безопасности вот такими манипуляциями, это устранит «An internal error has occurred».
На обычном сервере все это помогло, а вот на ноде RDSH ошибка оставалась. Тут я решил проверить догадку с уровнем безопасности «Configure security settings». На моей ферме был уровень «Согласования (Negotiate)«
Я пошел на сервер, где были проблемы подключения и решил проверить один параметр локальной политики gpedit.msc.
Тут попробуйте выставить уровень RDP. В результате у меня после этих настроек все заработало. Теперь нужно понять, что изменилось. В настройках RDS фермы указано, что мы используем уровень согласование:
Источник
Решено проблема с remote desktop
Участник
Участник
Сведения об ошибке:
Причина ошибки: Неизвестное имя пользователя или неверный пароль.
Состояние: 0xC000006D
Подсостояние: 0xC000006A
Сведения о процессе:
Идентификатор процесса вызывающей стороны: 0x1260
Имя процесса вызывающей стороны: C:Program Files (x86)Kaspersky LabKaspersky Endpoint Security for Windowsavpsus.exe
Участник
Не удается найти описание для идентификатора события 0 из источника igfxCUIService2.0.0.0. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере.
Если событие возникло на другом компьютере, возможно, потребуется сохранить отображаемые сведения вместе с событием.
К событию были добавлены следующие сведения:
akbars
Случайный прохожий
Участник
Да но при чем тут RDP ?
Есть еще event id 10000 RestartManager
Запуск сеанса 2 — 2021-09-08T06:32:14.183987300Z.
Все равно не ясно что не так.
akbars
Случайный прохожий
Участник
Участник
NanoSuit
Специалист
Я где то читал что RDP часто глючит в последних версиях Windows 10 или в некоторых случаях вообще не работает.
Посмотрите может в этом дело:
Когда клиент удаленного рабочего стола теряет подключение к Удаленному рабочему столу, ему не удается сразу же повторно подключиться. Пользователю отображается одно из таких сообщений об ошибке:
- Клиенту не удалось подключиться к серверу терминалов из-за ошибки системы безопасности. Убедитесь, что вы вошли в сеть, и повторите попытку подключения.
- Удаленный рабочий стол отключен. Из-за ошибки безопасности клиент не смог подключиться к удаленному компьютеру. Убедитесь в том, что вы вошли в сеть, и повторите попытку подключения к серверу.
При повторном подключении клиента Удаленных рабочих столов сервер RDSH подключает клиента к новому, а не исходному сеансу. Но при проверке состояния сервера RDSH сообщается, что исходный сеанс еще активен и не был отключен.
Чтобы устранить эту проблему, можете включить политику Настроить интервал проверяемых на активность подключений в папке групповой политики, выбрав Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовПодключения. Если вы включите эту политику, нужно будет задать интервал проверки активности. Интервал проверки активности позволяет определить, как часто (в минутах) сервер проверяет состояние сеанса.
Эту проблему также можно устранить, изменив параметры аутентификации и настройки. Вы можете изменить их на уровне сервера или с помощью объектов групповой политики. Чтобы изменить параметры, выберите Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовБезопасность.
- Откройте на сервере узла сеансов Удаленных рабочих столов соответствующее средство настройки.
- В области Подключения щелкните правой кнопкой мыши имя подключения и выберите Свойства.
- В диалоговом окне Свойства для этого подключения на вкладке Общие в разделе Безопасность выберите метод защиты.
- Выберите нужное значение для параметра Уровень шифрования. Можно выбрать значение Низкий уровень, Совместимый с клиентом, Высокий уровень или FIPS-совместимый.
src
Источник
Hi,
Thanks for posting in TechNet.
1. The error code 0x102 means «The wait operation timed out.» The issue may be network related. Please help check the smsts.log and smspxe.log for more information.
2.General speaking, Microsoft does not recommend using DHCP options, the recommended and supported method for PXE booting client computers on remote subnets is to use IP Helpers. Notice that, in certain instances, configuring DHCP options 60, 66, and 67 may
make it appear that the PXE boot process is proceeding further along than it did before these options were configured. However, in most cases, the process is actually proceeding along an incorrect path.
IP Helpers aren’t required if the DHCP server, the client computer, the ConfigMgr server that is running Windows Deployment Services (WDS), and the PXE-enabled Distribution Point (DP) are all on the same subnet or VLAN.
IP Helpers must be configured on the routers if any of the DHCP server, the client computer, or the Configuration Manager server that is running WDS and the PXE-enabled DP are on separate subnets or VLANs. This is usually the case in most environments.
IP Helpers are necessary because the PXE request that is generated by the client computer is a broadcast that doesn’t travel outside the local subnet or VLAN. If the DHCP server or the WDS/PXE-enabled DP aren’t on the same subnet or VLAN as the client computer,
they will not see or hear the PXE request broadcast from the client. Therefore, the servers will not respond to the PXE request. To have the PXE request broadcast travel between subnets or VLANs, the PXE request broadcast has to be forwarded by the router
to DHCP and WDS/PXE Service Point servers so that they can correctly respond to the client’s PXE request.
For more information, please refer to:
Troubleshooting PXE boot issues in Configuration Manager
Use PXE to deploy Windows over the network with Configuration Manager
Thanks for your time.
Best regards,
Simon
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.
-
Marked as answer by
Tuesday, June 9, 2020 11:02 AM
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
keithslater opened this issue
Oct 24, 2017
· 9 comments
Comments
Having problems getting connected to a SQL Server. Here is the command I’m using for testing —
sqlcmd -S 10.10.0.81,1434 -U username -P password -d database
I have assigned the static port 1434 to the named instance 10.10.0.81SQLEXPRESS.
I have tested this connected via Navicat and it connects successfully through the IP and port. The port is wide open to all internal IPs.
unixODBC 2.3.1
Not sure what else to try at this point.
@keithslater, to connect to a named instance on a static port, you need to use port number. Please see here. You can also check the related issues: #442, #340, #190, #175.
I understand that. My example shows me using the port 1434.
@keithslater, your problem may come from many places. It is difficult to pinpoint where the problem comes from. Here’s a list of solution for you to try out:
-
Make sure SQL Server is not listening on a dynamic port (see here).
-
Make sure ODBC is installed properly. What is the output for:
1. odbcinst -j
2. odbcinst -q -d -n "ODBC Driver 13 for SQL Server"
3. sudo find /usr 2>/dev/null -name "libodbc*"
4. php -i | grep "Configure Command"
-
Disable any firewall, as mentioned in connection failed #190.
-
Make sure SQL Server is listening to the right port. Run the following to make sure the correct port is being listened to.
USE MASTER
GO
xp_readerrorlog 0, 1, N'Server is listening on'
GO
odbcinst -j
unixODBC 2.3.4
DRIVERS............: /usr/local/etc/odbcinst.ini
SYSTEM DATA SOURCES: /usr/local/etc/odbc.ini
FILE DATA SOURCES..: /usr/local/etc/ODBCDataSources
USER DATA SOURCES..: /home/anvil/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
odbcinst -q -d
[PostgreSQL]
[MySQL]
[ODBC Driver 13 for SQL Server]
sudo find /usr 2>/dev/null -name "libodbc*"
/usr/lib64/libodbc.so
/usr/lib64/libodbc.so.2
/usr/lib64/libodbcdrvcfg2S.so.2
/usr/lib64/libodbcdrvcfg2S.so.2.0.0
/usr/lib64/libodbcinst.so
/usr/lib64/libodbcinst.so.2
/usr/lib64/libodbcinst.so.2.0.0
/usr/lib64/libodbcminiS.so.2
/usr/lib64/libodbcminiS.so.2.0.0
/usr/lib64/libodbcmyS.so
/usr/lib64/libodbcmyS.so.2
/usr/lib64/libodbcmyS.so.2.0.0
/usr/lib64/libodbcnnS.so
/usr/lib64/libodbcnnS.so.2
/usr/lib64/libodbcnnS.so.2.0.0
/usr/lib64/libodbc.so.2.0.0
/usr/lib64/libodbcpsqlS.so
/usr/lib64/libodbccr.so.2
/usr/lib64/libodbcpsqlS.so.2
/usr/lib64/libodbccr.so
/usr/lib64/libodbcdrvcfg1S.so
/usr/lib64/libodbccr.so.2.0.0
/usr/lib64/libodbcdrvcfg2S.so
/usr/lib64/libodbcdrvcfg1S.so.2
/usr/lib64/libodbctxtS.so
/usr/lib64/libodbcpsqlS.so.2.0.0
/usr/lib64/libodbctxtS.so.2
/usr/lib64/libodbcdrvcfg1S.so.2.0.0
/usr/lib64/libodbctxtS.so.2.0.0
/usr/lib64/libodbcminiS.so
/usr/local/lib/libodbcinst.so.2.0.0
/usr/local/lib/libodbcinst.so.2
/usr/local/lib/libodbcinst.so
/usr/local/lib/libodbcinst.la
/usr/local/lib/libodbc.so.2.0.0
/usr/local/lib/libodbc.so.2
/usr/local/lib/libodbc.so
/usr/local/lib/libodbc.la
/usr/local/lib/libodbccr.so.2.0.0
/usr/local/lib/libodbccr.so.2
/usr/local/lib/libodbccr.so
/usr/local/lib/libodbccr.la
php -i | grep «Configure Command»
returns nothing.
Double checking the port but I can connect to it on the port via Navicat.
@keithslater, looks like you have 2 different unixODBC installed. I’m not sure if this is the source of the problem, but after you’ve checked the port number of your SQL Server, you can try to uninstall your current unixODBC, and then install the latest unixODBC version using apt-get. You can revisit issue 231 to see how to uninstall and install unixODBC properly.
Which IP (IP1 to IPAll) did you change? Make sure the IP you’re configuring is the one you want to use. One thing you can try is to change the TCP Port in IPAll to 1434.
So IP2 had the IP address listed I was trying to connect on 10.10.0.81 with the static port configured 1434. So from what I can tell, IP2 was configured correctly.
However, IPAll had the dynamic port listed that I was able to actually connect on.
We’re going to change IP2 back to dynamic and move the static port to IPAll. Hopefully that should fix the issue. Not exactly sure why it didn’t work.
Switching the static port to IPAll fixed the issue.





























