Windows Server 2025 RDS: reconnect to a disconnected session stuck on “Please wait” until logoff after an interrupted auto-reconnect (Winlogon 4008). Server 2022 recovers from the same event.

Question

Windows Server 2025 RDS: reconnect to a disconnected session stuck on “Please wait” until logoff after an interrupted auto-reconnect (Winlogon 4008). Server 2022 recovers from the same event.

Sergii Pavlenko 0

Hello everyone,

We are facing a strange issue while migrating our RDS farm from Windows Server 2022 to Windows Server 2025, and I’ve run out of ideas, so I hope someone has seen this before.

Some background first. During the migration we run both farms side by side in the same datacenter. The old one runs Windows Server 2022 with User Profile Disks, the new one runs Windows Server 2025 with the latest cumulative update, FSLogix and an HA Connection Broker. Both farms serve the same users with the same laptops on the same network, and automatic reconnection is enabled on both.

The problem: occasionally, and at random, a user’s session on the new farm cannot be reconnected after it was disconnected. Most disconnects and reconnects work fine. It usually happens when the laptop went to sleep during lunch, or when the user walked over to another building. When they come back and reconnect, they land on “Please wait” inside their existing session and it never goes away. Every reconnect to that session after that ends up the same way, from any device. Logging the session off fixes it, but the user loses whatever was open. The applications keep running perfectly fine in the background the whole time. On the 2022 farm this never happens.

The strangest part is that the session itself is not dead. As an admin logged on to the same host, I can open Task Manager, go to Users, right-click the stuck user and choose Connect (it asks for that user’s password). The stuck session then comes up instantly on my connection, fully working, with all the user’s applications. But as soon as anyone connects to that session again with a normal RDP connection from outside, it hangs on “Please wait” again.

I caught quite a few of these sessions live and went through the logs. In every case I could fully trace, the session breaks at the same moment: the client’s automatic reconnect starts attaching to the session and is abandoned halfway. Sometimes the network drops a few seconds in. Sometimes the UDP channel never comes up and the server waits in “Waiting for graphics subsystem” for 60 seconds until the client gives up. The clearest case was on a host already switched to TCP only. In the RdpCoreTS log and the Application log it went like this:

13:33:24.825 the laptop connects. It is an automatic reconnect (GetSessionIdFromArcInfo).
13:33:25.348 the laptop closes this connection itself (TCP socket READ failed, error 64).
13:33:25.354 6 ms later the server still assigns this already closed connection to the user’s session, and right away logs event 67, “The RemoteFX protocol connection encountered an error (0x80004004)”.
13:33:25.436 the laptop opens a second connection, also an automatic reconnect.
13:33:25.824 Winlogon logs 4008 in the Application log, “The Windows logon process has failed to connect the user session”.
13:33:26 the second connection attaches fine at the transport level, and LSM even logs “Session reconnection succeeded”, but the user sits on “Please wait” from here on.

In the Winlogon/Operational log (event 811) the difference is clear. On a normal reconnect there is notification 9 followed by 5. I checked with Win+L that 4 is lock and 5 is unlock. Once the session is broken, every reconnect shows 9 followed by 8 about 30 ms later, and never 5. Sometimes nothing is logged at all. So it looks like Winlogon never unlocks the session again.

What makes me think this is a 2025 problem: the 2022 farm gets exactly the same event. It logs 4008 every day, with the same pattern of an automatic reconnect being cut off, but there the next reconnect simply works and the user carries on. I also see RemoteFX error 67 on 2025 at the moment of the abort, and never on 2022.

I took process dumps while a session was stuck. LogonUI sits in logoncontroller!CLogonController::DoModal waiting, Winlogon sits in winlogon!StateMachineRun / SignalManagerWaitForSignal, and LSM and TermService are completely idle. Nothing is busy and nothing looks deadlocked. Everything is waiting for something that never comes. LogonUI has no third-party DLLs loaded, and all credential providers are the Windows defaults.

Other things I tried on a stuck session:

Killing LogonUI.exe removes “Please wait”, but the user then gets a black screen.
Ctrl+Alt+End does nothing.
Disconnecting the session from the server side and reconnecting doesn’t help.

What we already tried or ruled out:

The first thing I tried was the well-known fix that comes up in almost every thread about “Please wait” on reconnect: “Select network detection on the server” set to turn off both Connect Time Detect and Continuous Network Detect. It is applied on all session hosts but it didn’t help at all.
Keep-alive interval is set to 1 minute. Sessions go to Disconnected properly after a drop, so it’s not a stale active session.
“Use only TCP” to rule out UDP issues. It still happened on a TCP-only host.
Different visual effects and transparency settings make no difference. It happens with the performance-tuned settings and with the Windows defaults, and with transparency both on and off.
FSLogix is not involved. I reproduced it on a standalone 2025 server that has no FSLogix at all.
Different clients: Windows mstsc, Windows App on macOS, and a minimal .rdp file with one monitor, fixed resolution and all redirections off. I also tried from another server on the same network as the session host. Same result every time.
Graphics negotiation (RdpCoreTS event 162) is identical on 2022 and 2025.
The September 2026 RDS issue (KB5122871, fixed by KB5129235) is not it. Our problem started before that and is still there with the latest updates.

So my questions are:

Is this a known issue in Server 2025, where Winlogon fails to connect a session after an aborted automatic reconnect and then never completes any reconnect to it again?
Is there a fix, or any supported setting, that makes 2025 recover from this like 2022 does?
Is there a supported way to bring such a session back for the user without logging them off? Moving a working connection into it through Task Manager proves the session is still alive.

Sorry for the long read. I’ve tried to explain the issue in detail, with all my findings, and I really hope someone can help.
I don’t want to stop halfway through the migration and rebuild the farm on the proven Windows Server 2022, which has never shown a single sign of this issue.

0 comments

3 answers

Your answer

Answer 1

Welcome to Microsoft Q&A!

Thank you for taking the time to share such a detailed investigation.

Based on everything you have tested, I agree that disabling Automatic Reconnection would only avoid the path that triggers the problem. It would not explain why the affected session on Server 2025 does not recover afterward, so I would not consider that a resolution to the behavior you are investigating.

The important distinction in your findings is that the RDP connection itself appears able to reconnect to the existing session, while the Windows logon/session state does not complete the corresponding transition.

The sequence you captured is particularly useful:

An Automatic Reconnection attempt begins and is interrupted.
Winlogon subsequently records event 4008.
Local Session Manager can report that the session reconnection succeeded.
Winlogon does not subsequently reach the normal unlock sequence you observe during a successful reconnect.
Further external RDP connections reach Please wait, although the user's applications remain running in the existing session.

The fact that Task Manager > Users > Connect can attach an administrator's connection to that same session and immediately display the working desktop is also important. It indicates that the user session and its applications have not simply terminated. However, as you have confirmed, that operation does not restore the session's ability to accept a subsequent normal RDP reconnect.

Given the amount of isolation you have already performed, I would not recommend continuing to change UDP/TCP transport settings, FSLogix, visual settings, keep-alive, or network-detection policies. The evidence now points toward a possible session reconnection/Winlogon state problem that requires deeper investigation.

At present, I cannot confirm from the published Windows Server 2025 known-issues documentation that this exact sequence has been identified as a known Windows Server 2025 issue. Likewise, I cannot find a publicly documented supported mechanism that resets this particular Winlogon/session state while preserving the user's running session.

Your Windows Server 2022 comparison is very valuable because it demonstrates a behavioral difference under apparently equivalent failure conditions. However, that comparison alone would not be enough to state that this is a confirmed Windows Server 2025 product defect. Establishing that would require analysis of the reproduction traces by Microsoft Support and, if necessary, the responsible product engineering team.

Unfortunately, for the same reason, I do not have a supported in-session recovery that I can recommend beyond what you have already tested. Task Manager > Users > Connect can be useful for emergency access, but it does not repair the session for the user's next external connection. I would also avoid terminating LogonUI, resetting the session, or manipulating Winlogon processes in production because these actions are not a documented recovery method for this condition and could leave the session unusable or result in loss of the user's work.

Therefore, if the session reaches this state, logging off the affected session remains the reliable way to return the user to a clean logon state until the underlying cause can be identified.

I realize this is probably not the definitive answer you were hoping for, particularly when you need to make a decision about continuing the Server 2025 migration. However, based on the troubleshooting you have already completed, I believe you have reached the point where further investigation goes beyond what can be reliably provided through a Microsoft Q&A thread.

Microsoft Q&A is a community technical Q&A platform. Within the forum, I can help with documented product behavior, configuration, published known issues, and supported troubleshooting guidance. However, a case such as this requires analysis of TSS/ETL traces, process dumps, and the internal Winlogon/RDS state at the exact point of failure. That level of debugging cannot be performed or validated through the forum.

I also do not want to speculate about undocumented Windows internals or present an assumption about the Winlogon notification sequence as an official root cause. Unless a behavior, defect, fix, or workaround has been publicly documented by Microsoft, or confirmed through the appropriate support/product channel, there is no reliable way in Microsoft Q&A to state whether the behavior is a product regression or what code-level condition is responsible for it.

For this reason, the one next step I recommend is to open a Microsoft Support case and provide the reproduction data you have already collected.

If possible, reproduce the interrupted Automatic Reconnection while that trace is running and retain the exact timestamps for the interrupted reconnect, Winlogon event 4008, and the subsequent connection that becomes stuck at Please wait. Include the RdpCoreTS, LocalSessionManager, RemoteConnectionManager, Winlogon/Application and Winlogon/Operational evidence, together with the dumps you have already collected.

I would also provide the equivalent Server 2022 reproduction where the interrupted reconnect occurs but the following reconnect succeeds. That side-by-side comparison should be especially useful in determining whether the behavior represents a Server 2025-specific regression.

Your investigation is already very thorough. At this stage, I would preserve the environment in which you can reproduce the problem rather than introduce additional configuration changes before collecting the support trace.

I am sorry that I cannot provide a definitive fix from the forum. In this case, however, escalating the reproducible trace to Microsoft Support is the most appropriate way to obtain the product-level analysis needed to determine whether a servicing fix or another supported mitigation is required.

References:

Windows Server 2025 known issues and notifications | Microsoft Learn

Collect Data to Analyze and Troubleshoot Remote Desktop Services Scenarios - Windows Client | Microsoft Learn

Troubleshoot Unexpected RDS Session Locks or Disconnections - Windows Server | Microsoft Learn

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Answer 2

Thanks for the answer.
Unfortunately, turning off automatic reconnection isn’t an option for us, since every small network glitch would then disconnect users. Server 2022 handles the same interrupted reconnects just fine, so the real question is still why 2025 doesn’t, and whether there’s a fix.

Task Manager Connect / tscon works for me only as emergency access. The session comes up on my admin connection, but any new reconnect from outside still hangs.

If someone from the RDS team wants to take a look, I can collect a TSS trace (UEX_RDSsrv with UEX_Logon) and share it along with the logs and dumps I already have.

Has anyone else run into this on Server 2025?

Answer 3

Disable RDS Automatic Reconnection on the Windows Server 2025 collection to prevent the interrupted ARC path that triggers the failure; Microsoft does not currently document this exact Winlogon 4008/notification 9→8 condition as a known Server 2025 issue or provide a supported in-place reset for an already affected session.

Containment: disable Automatic Reconnection

Automatic Reconnection is enabled by default. Disabling it server-side prevents clients from using ARC regardless of their local configuration. The change applies only to sessions created after the setting changes; existing sessions retain the setting negotiated when they connected.^1^

Use one of these methods:

Group Policy — preferred for the farm

Open Group Policy Management Console.
Edit a GPO applied to every Server 2025 RD Session Host.
Go to:
Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections
Open Automatic reconnection and set it to Disabled.
Apply the policy to the hosts.
Have users start new sessions—existing sessions do not inherit the change.

The GPO takes precedence over the collection setting.

Collection configuration

If the GPO setting is Not Configured, use:

Server Manager → Remote Desktop Services → Collections → collection → TASKS → Edit Properties → Session → clear “Enable automatic reconnection.”

Alternatively:

Set-RDSessionCollectionConfiguration `
    -CollectionName "YourCollectionName" `
    -AutomaticReconnectionEnabled $false

For a controlled test, disable it on one client by adding this line to its .rdp file:

autoreconnection enabled:i:0

This is containment rather than a confirmed correction to Winlogon. A normal reconnect remains available, but it will perform a fresh connection negotiation instead of resuming through ARC.

Status of the suspected Server 2025 defect

The public Windows Server 2025 issue registry does not currently list the specific sequence you documented: interrupted ARC, Winlogon 4008, subsequent reconnects stuck at Please wait, and recovery only through an administrative session transfer.^2^

The documented September 2026 RDS regression is a different issue: broader RDS instability after KB5122871, resolved by KB5129235 and later updates.^3^ Your timeline, current patch level, idle TermService/LSM state, and successful transport attachment do not match that published failure.

Likewise, the earlier Server 2025 Remote Desktop freeze fixed in KB5055523 involved mouse and keyboard becoming unresponsive shortly after connection—not a persistently unrecoverable Winlogon reconnect state.^4^

Recovering an already affected session

tscon is the supported command-line equivalent of the successful Task Manager → Users → Connect operation. It requires Full Control or Connect permission; when connecting to another user’s session, supply that user’s password interactively.^5^

Run locally on the affected Session Host from an elevated administrative session:

quser
tscon <SessionID> /password:* /v

This can attach the administrator’s connection to the live session without terminating its applications. However, it does not reset the failed Winlogon state, and the documented command behavior does not provide a supported way to hand that repaired connection back through a new external RDP logon. Given your testing, it is therefore a diagnostic or emergency access method—not a durable user recovery.

Do not use reset session, rwinsta, or logoff when preserving applications is required; resetting deletes the session and can cause data loss.^6^

Escalate with a live reproduction

This now needs a Microsoft Support case against Windows Server/RDS. Capture the transition while the session changes from reconnectable to permanently stuck:

On the affected Session Host, open elevated PowerShell.
Start Microsoft’s TSS collection before reproducing:

.\TSS.ps1 -Scenario UEX_RDSsrv -start -UEX_Logon

Reproduce the interrupted automatic reconnect and one subsequent failed reconnect.
Preserve:
- TSS output and exact timestamps.
- Application log entries containing Winlogon 4008.
- Winlogon/Operational 811 notification sequences.
- RdpCoreTS, LocalSessionManager, and RemoteConnectionManager logs.
- quser output and affected session ID.
- Client and server network traces covering both ARC attempts.
- Dumps of Winlogon and LogonUI from the affected session.
- A working Server 2022 trace showing recovery from the equivalent abort.

Microsoft specifically recommends the UEX_RDSsrv plus UEX_Logon TSS scenario when standard RDS lock/disconnection troubleshooting does not resolve the problem.^7^

Your cross-version traces and reproducible Winlogon state transition are the key evidence needed for escalation; further UDP, keep-alive, FSLogix, visual-effects, network-detection, or client testing would repeat conditions already excluded.

References