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.