Windows 11 Pro RDP sessions become stuck and cannot be reconnected — even local console login gets blocked

furkan hocaoglu 0 Reputation points
2026-08-11T12:17:34.7233333+00:00

I am experiencing a persistent Remote Desktop session problem on a Windows 11 Pro PC.

I connect remotely to this PC using the built-in Windows Remote Desktop protocol, usually through Tailscale. The same issue occurs regardless of whether the RDP client is a MacBook or another Windows PC, so it does not appear to be client-specific or related to Tailscale.

After a clean boot, everything works perfectly. RDP connects immediately, Windows Search/Start menu accepts keyboard input normally, and applications work correctly.

However, after disconnecting and reconnecting, the RDP session eventually becomes stuck. Windows then reports that another session is already using the account and asks whether I want to disconnect/sign out that session.

When this happens, several other problems appear:

  • Reconnecting can remain stuck on “Please wait” for a very long time.
  • Task Manager shows multiple sessions for the same local user account (rdp).
  • Multiple explorer.exe processes appear under different Session IDs.
  • Windows Start/Search stops accepting keyboard input.
  • Some applications that normally work correctly freeze when opening login dialogs (for example CHITUBOX).
  • Most importantly, even when I physically use the PC, Windows sometimes reports that another session is using the account and prevents the local console from cleanly taking over the session.
  • logoff <session ID> and reset session <session ID> have both become stuck when attempting to terminate the problematic session.

A forced shutdown using the PC’s physical power button followed by booting the PC results in a clean system and RDP works perfectly again.

Strangely, cutting AC power using a smart plug and then restoring power does NOT reliably produce the same result. The machine can be completely without power for hours or even days, yet after booting I can encounter the same RDP/session problem again.

I have already configured the following Group Policy settings:

  • Restrict Remote Desktop Services users to a single Remote Desktop Services session: Enabled
  • Automatic reconnection: Enabled
  • Limit number of connections: 1
  • Configure keep-alive connection interval: Enabled (1 minute)

I also tested Set time limit for disconnected sessions = 1 minute. This prevents the stuck-session problem because Windows logs off the disconnected session, but it is not an acceptable solution for me: it closes all running applications and projects. I need the disconnected session to remain alive so that I can reconnect later and continue working exactly where I left off.

Ideally, the behavior should be:

  1. Connect to the PC using RDP with the local rdp account.
  2. Work normally and leave applications/projects running.
  3. Disconnect the RDP client without signing out.
  4. Reconnect later, potentially from another device.
  5. Windows should reconnect to the same existing session, with all applications still running.
  6. If I return to the physical PC, the local console should also be able to take over the same user session normally.

Instead, the existing session eventually becomes unusable and blocks both subsequent RDP connections and sometimes the local console.

What could cause an RDP session on Windows 11 Pro to become stuck in this state and refuse reconnection even when the single session per user policy is enabled?

Is there a specific LocalSessionManager / TerminalServices event log, service, registry setting, credential/session configuration, or known Windows 11 issue I should investigate?

I would prefer to diagnose the underlying cause rather than automatically logging off disconnected sessions, because preserving running applications is essential for my use case. I am experiencing a persistent Remote Desktop session problem on a Windows 11 Pro PC.

I connect remotely to this PC using the built-in Windows Remote Desktop protocol, usually through Tailscale. The same issue occurs regardless of whether the RDP client is a MacBook or another Windows PC, so it does not appear to be client-specific or related to Tailscale.

After a clean boot, everything works perfectly. RDP connects immediately, Windows Search/Start menu accepts keyboard input normally, and applications work correctly.

However, after disconnecting and reconnecting, the RDP session eventually becomes stuck. Windows then reports that another session is already using the account and asks whether I want to disconnect/sign out that session.

When this happens, several other problems appear:

  • Reconnecting can remain stuck on “Please wait” for a very long time.
  • Task Manager shows multiple sessions for the same local user account (rdp).
  • Multiple explorer.exe processes appear under different Session IDs.
  • Windows Start/Search stops accepting keyboard input.
  • Some applications that normally work correctly freeze when opening login dialogs (for example CHITUBOX).
  • Most importantly, even when I physically use the PC, Windows sometimes reports that another session is using the account and prevents the local console from cleanly taking over the session.
  • logoff <session ID> and reset session <session ID> have both become stuck when attempting to terminate the problematic session.

A forced shutdown using the PC’s physical power button followed by booting the PC results in a clean system and RDP works perfectly again.

Strangely, cutting AC power using a smart plug and then restoring power does NOT reliably produce the same result. The machine can be completely without power for hours or even days, yet after booting I can encounter the same RDP/session problem again.

I have already configured the following Group Policy settings:

  • Restrict Remote Desktop Services users to a single Remote Desktop Services session: Enabled
  • Automatic reconnection: Enabled
  • Limit number of connections: 1
  • Configure keep-alive connection interval: Enabled (1 minute)

I also tested Set time limit for disconnected sessions = 1 minute. This prevents the stuck-session problem because Windows logs off the disconnected session, but it is not an acceptable solution for me: it closes all running applications and projects. I need the disconnected session to remain alive so that I can reconnect later and continue working exactly where I left off.

Ideally, the behavior should be:

  1. Connect to the PC using RDP with the local rdp account.
  2. Work normally and leave applications/projects running.
  3. Disconnect the RDP client without signing out.
  4. Reconnect later, potentially from another device.
  5. Windows should reconnect to the same existing session, with all applications still running.
  6. If I return to the physical PC, the local console should also be able to take over the same user session normally.

Instead, the existing session eventually becomes unusable and blocks both subsequent RDP connections and sometimes the local console.

What could cause an RDP session on Windows 11 Pro to become stuck in this state and refuse reconnection even when the single session per user policy is enabled?

Is there a specific LocalSessionManager / TerminalServices event log, service, registry setting, credential/session configuration, or known Windows 11 issue I should investigate?

I would prefer to diagnose the underlying cause rather than automatically logging off disconnected sessions, because preserving running applications is essential for my use case.

Windows for business | Windows Client for IT Pros | User experience | Remote desktop services and terminal services
0 comments No comments

1 answer

Sort by: Most helpful
  1. Allan Solomon Mejia 3,840 Reputation points
    2026-08-11T20:08:27.2766667+00:00

    Hello @furkan hocaoglu

    Based on the symptoms you've described, I don't think this is primarily a Tailscale, RDP client, or basic network connectivity issue.

    The important indicators are:

    • Multiple sessions appear for the same local account.
    • Multiple explorer.exe processes exist under different Session IDs.
    • Reconnection hangs at Please wait.
    • logoff <sessionID> and reset session <sessionID> also hang.
    • Start/Search and some application authentication dialogs stop functioning.
    • Eventually the local console can also be affected.
    • A reboot temporarily restores normal operation.

    Taken together, this points more toward the Windows session-management stack becoming stuck, potentially involving Local Session Manager (LSM), Remote Desktop Services (TermService), Winlogon/user-session initialization, or another component associated with that session.

    The fact that setting Set time limit for disconnected sessions = 1 minute prevents the issue is particularly useful. It suggests that the problem is associated with preserving/reconnecting the existing session rather than establishing the initial RDP connection. Your requirement to leave the disconnected session running and reconnect to it later is a normal RDP use case; automatically logging it off is therefore a workaround rather than a root-cause fix.

    Microsoft also documents a scenario where an RDP client disconnects but the original session incorrectly remains Active rather than transitioning to Disconnected, preventing the client from correctly reconnecting to that session. Microsoft recommends the RDP keep-alive policy as one mitigation, although you've already enabled it.

    1. Check the session state when the problem occurs

    Before rebooting, run from an elevated console:

    quser
    qwinsta
    

    and:

    Get-Process explorer,winlogon,rdpclip -IncludeUserName |
        Select-Object Id,SessionId,ProcessName,UserName
    

    Compare the Session IDs. If the same account has an old session that remains Active while Windows is attempting to create or reconnect another session, that would be important evidence.

    2. Check the RDP/LocalSessionManager event logs

    I would specifically examine:

    Event Viewer > Applications and Services Logs > Microsoft > Windows

        *TerminalServices-LocalSessionManager*
    
          *Operational*
    
        *TerminalServices-RemoteConnectionManager*
    
          *Operational*
    
        *RemoteDesktopServices-RdpCoreTS*
    
          *Operational*
    

    Also check:

    Windows Logs > System

    Windows Logs > Application

    around the exact time the first reconnect failure occurs.

    Don't focus only on the final failed connection. The useful event may occur several minutes earlier when the original RDP connection transitions from connected to disconnected.

    3. Determine whether TermService can recover the machine

    When the problem occurs and you still have local administrative access, try:

    net stop TermService
    net start TermService
    

    Be aware that this disconnects existing RDP connections.

    If TermService itself cannot stop, or stopping it hangs indefinitely, that would further support the theory that this is a server-side/session-management problem rather than an RDP client problem.

    Microsoft specifically identifies Remote Desktop Services (TermService) and Remote Desktop Services UserMode Port Redirector (UmRdpService) as services to verify when troubleshooting RDP failures.

    4. Check whether Windows is actually performing a full shutdown

    Your observation about the physical power button versus removing AC power is interesting.

    I would temporarily disable Fast Startup while troubleshooting:

    Control Panel

    > Power Options

    > Choose what the power buttons do

    > Change settings that are currently unavailable

    > Turn on fast startup

    Clear that option and then perform:

    shutdown /s /f /t 0
    

    followed by a normal power-on.

    This removes hybrid shutdown/hibernation behavior as a variable when comparing your reboot/shutdown tests.

    5. Test whether the issue follows the user profile

    Create a new local test account, grant it Remote Desktop access, and reproduce the same disconnect/reconnect cycle.

    If the new account remains stable while the rdp account eventually becomes stuck, investigate the original Windows user profile and user-shell components rather than RDP globally.

    If both accounts eventually exhibit the same behavior, the evidence points more strongly toward LSM/TermService or another system-level component.

    6. Don't add more session timeout policies yet

    I wouldn't recommend additional disconnected-session timeout policies at this stage. You've already demonstrated that forcing Windows to log off the session prevents the symptom, but that defeats your requirement to preserve running applications.

    Your existing Restrict Remote Desktop Services users to a single Remote Desktop Services session policy should normally cause subsequent connections for that user to reconnect to the existing session rather than intentionally creating another usable session.

    7. Capture evidence before the next forced reboot

    If the issue reproduces, capture:

    quser > C:\Temp\quser.txt
    qwinsta > C:\Temp\qwinsta.txt
    tasklist /v > C:\Temp\tasklist.txt
    sc queryex TermService > C:\Temp\termservice.txt
    

    and export the TerminalServices/LocalSessionManager event logs.

    If possible, also note the exact UTC time at which:

    • RDP was disconnected.
    • Reconnection was attempted.
    • Please wait appeared.
    • logoff or reset session became stuck.

    That sequence would be much more useful for Microsoft Support than simply reporting that RDP eventually stops responding.

    There is another Microsoft Q&A report describing a very similar Windows 11 condition where RDP eventually hangs at Please wait, no usable new session is established, and rebooting temporarily restores operation. That doesn't prove both cases have the same root cause, but it does make a Windows session-management issue worth investigating.

    If the problem still occurs on a fully updated Windows 11 installation, with a fresh local user profile and Fast Startup disabled, I would consider opening a Microsoft Support case. At that point, especially if TermService, logoff, and reset session are all unable to tear down the affected session, Microsoft may need diagnostic traces or a dump from the affected system to determine which component is preventing the session from transitioning correctly.

    Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

    Was this answer helpful?

    0 comments No comments

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.