RDS Problem reconnecting to a session

Question

Hello,

I am having a problem on my RDS farm (Windows Server 2019) :

After a session is locked, manually by the user or automatically by GPO, when the user tries to reconnect and enters their password, his session does not open and the screen freezes. There is the usual login page, with the logo and the name of the user, but there is no loading circle with the message "Welcome". See the screenshot below.

The problem is encountered by a large number of users with no correlation between their hardware, whether through connections with thin clients or hard clients. The problem appears every day but not at set times.

The RDS farm was installed recently and this problem appeared quite soon after the farm was put into production.
The problem appears on both the RemoteDesktop collection and the RemoteApp collection.

The scenario of the problem :

On the Broker, before the user tries to reconnect, the session appears in Disconnected status.
When the user tries to reconnect and the screen freezes, the session appears in Active status.

From the Broker server, a right click -> Disconnect on the user has no effect.
To unblock the user, the "Windows Logon User Interface Host" process (LogonUI.exe) for the session concerned must be terminated manually. Then, the session is unblocked and the connection to the session works perfectly. The user reconnects to his session and retrieve the documents and applications he had opened, and he reconnects to the same session server.

In the event viewer on the session server, the following errors appear when the user tries to reconnect and screen freeze :

Disconnect trace: CUMRDPConnection Disconnect trace: 'calling spGfxPlugin-> PreDisconnect ()' in CUMRDPConnection :: PreDisconnect at 4595 err = [0x80004004], Error code: 0x80004004

The network characteristics detection function has been disabled due to Reason Code: 2 (Server Configuration).

'Failed GetConnectionProperty' in CUMRDPConnection :: QueryProperty at 2884 err = [0x80004001]

The network characteristics detection function has been disabled due to Reason Code: 1 (Client not supported) ..

'Failed CreateVirtualChannel call on this Connections Stack' in CUMRDPConnection :: CreateVirtualChannel at 2498 err = [0xffffffff]

RDP_SEC: An error occurred while transitioning from FStatePassthrough in response to FEventCheckAndCompleteReadsFailed (error code 0x8007139F).

I have taken the following actions but it still does not work :

-Added registry keys on all session servers:

-HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ SysProcs : csrss.exe = 0
-HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ SysProcs : winlogon.exe = 0
-HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ WinStations : fEnableRemoteFXAdvancedRemoteApp = 0
-HKLM \ SOFTWARE \ Microsoft \ Terminal Server Client : UseURCP = 0
-HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows NT \ Terminal Services : VisualExperiencePolicy = 2

-Farm servers, computers updated with the latest Windows KB.

Thank you in advance for your help.

Answer 1

Hi, anyone have any idea?

Thanks you

Answer 2

Did you find a solution to this? Been struggling with something similar myself, though is RDS 2022 and I do not get any event errors when the user login process is stuck. I found myself ending user processes 1-by-1 and like you came across "Windows Logon User Interface Host" process (LogonUI.exe) being the issue, so my work-around has been ending that process for affected users. Hoping there's a way to prevent this issue.

Answer 3

Same here, the exact problem as joshadmin-6306 describes it. Anyone got a solution or suggestion on how to further troubleshoot this?

Answer 4

Unfortunately we are dealing with the same issue with 2022

If a user logs off the RDS correctly there is no issue, if the session is disconnected then you can just be left with a black screen.
Terminating LogonUI.exe for the user (potentially multiple times) will then release the user from the black screen and present a working session again.

The other issue is that the disconnected/blackscreen challenge isn't overly consistent, we can replicate it but it may take us 1-3 logins to be presented with the issue.

There was mention of a similar issue in a recent windows 11 patch
https://support.microsoft.com/en-au/topic/september-20-2022-kb5017383-os-build-22000-1042-preview-62753265-68e9-45d2-adcb-f996bf3ad393

If anyone has a solution I am very keen on implementing a solution as it is very disruptive.

Answer 5

We're seeing the exact same problem as described by the OP. It is severely impacting our ability to work as many of our users depend on terminal services for 90% of their job function. Hope someone is able to come up with a meaningful solution very soon or I'm going to be rebuilding some terminal servers on 2016 rather than 2022.