Forum Discussion

kris1975's avatar
kris1975
Copper Contributor
Jun 30, 2026

Issue with winlogon on Remote Desktop Services:

We are investigating intermittent session establishment failures on Windows Server 2019 servers used as CyberArk PSM / RDS hosts.

At unspecified intervals, new privileged sessions fail to establish or are disconnected during the initial session/logon phase. The issue is intermittent and affects new sessions. Existing sessions may continue to work.

 

The strongest and most consistent correlation identified so far is:

Microsoft-Windows-TerminalServices-LocalSessionManager/Operational – Event ID 36

Application / Microsoft-Windows-Winlogon – Event ID 4005

 

We observed that TerminalServices-LocalSessionManager Event ID 36 can occur without a subsequent Winlogon Event ID 4005. However, every observed Winlogon Event ID 4005 is correlated with TerminalServices-LocalSessionManager Event ID 36 in the same incident window.

 

This suggests that Event ID 36 is a consistent precursor or required condition for the Winlogon 4005 cases.

 

Environment

 

Operating system: Windows Server 2019

Role: CyberArk PSM / RDS session host

Issue type: intermittent failure during new RDP/PSM session initialization

Impact: affected users cannot establish privileged sessions or are disconnected during session startup

 

Similar issue exists on previous windows server 2012 R2 and was fixed : August 16, 2016 – KB3179574 (During virtual channel management, a deadlock condition occurs that prevents the RDS service from accepting new connections.)

https://support.microsoft.com/en-us/topic/august-2016-update-rollup-for-windows-8-1-and-windows-server-2012-r2-d472b5d5-4b3a-8e6e-c22a-f62fed604caf

I'm looking forward for any ideas how to resolve this issue. Many thanks!!

1 Reply

  • Hi kris1975, I’d correlate the failed sessions by exact timestamp across LocalSessionManager, Winlogon, Security, and User Profile Service logs. Event 4005 often points to the logon process failing after the session starts, so I’d also check profile loading, GPO processing, credential provider/CyberArk components, and any antivirus exclusions on the RDS hosts. A test host with the same baseline but without the PSM layer would help separate Windows/RDS from CyberArk-specific behavior.