Forum Discussion
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!!
2 Replies
Hi Kris,
Given the correlation between TerminalServices-LocalSessionManager Event ID 36 and Winlogon Event ID 4005, I'd focus on what happens during the session initialization rather than Winlogon itself.
A few areas I'd investigate:
- Verify the server is fully patched with the latest Windows Server 2019 cumulative updates, as several RDS stability fixes have been included over time.
- Review whether CyberArk PSM components, endpoint security/EDR, or credential providers are injecting into the logon process. Third-party authentication hooks can sometimes introduce delays or deadlocks during session initialization.
- Monitor LSASS, Winlogon, and TermService resource utilization when the issue occurs. Intermittent CPU, memory, or handle exhaustion can prevent new sessions while existing sessions continue to function normally.
- Capture an ETW trace or use ProcMon during a failure window to identify where the session initialization is stalling. The Event IDs indicate where the failure surfaces, but not necessarily the underlying cause.
- If this only affects new sessions, I'd also review RDS limits (maximum sessions, disconnected session cleanup, ephemeral port exhaustion, and GPOs affecting session creation).
Since you mentioned the issue resembles the old Server 2012 RDS deadlock, it would also be worth opening a Microsoft support case with the ETW traces and memory dumps. Even if the root cause is different, the telemetry will help determine whether you're encountering a regression in the RDS session initialization path or an interaction with a third-party component such as CyberArk.
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.
