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 Reputation points
2026-11-03T16:20:04.03+00:00

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:

  1. 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?
  2. Is there a fix, or any supported setting, that makes 2025 recover from this like 2022 does?
  3. 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.

Windows for business | Windows Server | User experience | Remote desktop services and terminal services
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Sergii Pavlenko 0 Reputation points
    2026-11-03T16:41:25.5333333+00:00

    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?

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-11-03T16:21:29.35+00:00

    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

    1. Open Group Policy Management Console.
    2. Edit a GPO applied to every Server 2025 RD Session Host.
    3. Go to:
      Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections
    4. Open Automatic reconnection and set it to Disabled.
    5. Apply the policy to the hosts.
    6. 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:

    1. On the affected Session Host, open elevated PowerShell.
    2. Start Microsoft’s TSS collection before reproducing:
    .\TSS.ps1 -Scenario UEX_RDSsrv -start -UEX_Logon
    1. Reproduce the interrupted automatic reconnect and one subsequent failed reconnect.
    2. 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

    1. Disable Automatic Reconnection in Remote Desktop Service for Windows Server
    2. Windows Server 2025 known issues and notifications
    3. Resolved issues in Windows Server 2025
    4. April 8, 2025—KB5055523 (OS Build 26100.3775) for Windows Server | Microsoft Support
    5. tscon
    6. tsdiscon
    7. Troubleshoot unexpected RDS session locks or disconnections
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.