Quick answer
For advanced users: run qwinsta to find the duplicate session, then rwinsta <sessionID> to kill it, or just reboot the machine if that fails.
Why this happens
I remember the first time this error popped up on a Windows Server 2016 box I managed. A user had disconnected from an RDP session without logging off, and the next connection attempt threw 0XC00000EE. The message, when it appears, says something like "The logon session already exists." That's exactly it—Windows thinks you're still logged in under the same session name. This usually happens when a remote desktop session or a service that creates a named logon session gets interrupted—network drop, forced shutdown, or a hung process—and the session entry stays in the security subsystem. The logon session isn't properly closed, and the next attempt to create a session with the same name (usually your username, but sometimes a service account) collides with the stale one.
This is more common on Windows Server (2008 R2 through 2019) and Windows 10/11 Pro when you use RDP, but I've also seen it with scheduled tasks that run under a service account and try to spawn interactive processes. The key is that the session manager (LSASS) keeps a record of the logon session even after the process ends, and it only clears it on a clean logoff or a reboot—unless you force it.
Fix steps
Step 1: Identify the duplicate session
First, open a Command Prompt as Administrator. You'll use qwinsta to list all sessions. Run:
qwinstaLook for your username (or the service account name) that appears more than once, or a session with a status of Disc (disconnected) that matches your current session name. Note the session ID—it's the number in the second column. In my experience, the stale session usually has a lower ID and is disconnected, while the new attempt fails because it tries to reuse the same name.
Step 2: Kill the stale session
Once you have the session ID of the stale session, reset it with:
rwinsta <sessionID>Replace <sessionID> with the actual number. For example, if the stale session ID is 2, you'd type rwinsta 2. This forces Windows to drop the logon session, which should clear the error. If you get an "Access denied" error, make sure you're truly running as Administrator—UAC sometimes needs an extra click. After running rwinsta, try your logon again. Works most of the time.
Step 3: If that doesn't work, reboot
If rwinsta won't clear it (I've seen it hang when the session is in a weird state), you need to reboot the machine. It's blunt, but it's the only reliable way to flush all logon sessions from memory. If you can't reboot right away, and this is a server, you might be able to schedule a reboot during a maintenance window. Just be aware that until you reboot, the error will keep occurring for that user.
Alternative fixes when the main one fails
Sometimes the issue isn't a user session but a service logon. If the error appears when a service tries to start, check the Service Control Manager (services.msc) and look for any service running under the same account that might have a hung process. Stop the service, then start it again. That usually resets the logon session.
Another workaround: if you're connecting via RDP and you have physical or console access, log on locally first. This sometimes forces the stale session to be recognized and cleaned up, but it's hit or miss. I've also had success with using a different username (like logging on as a temporary admin) to get in and then reset the stale session from inside.
For Windows Server, you can also try tscon to disconnect a session, but that only helps if the session is currently connected, not stale.
Prevention tips
The best way to avoid this error is to make sure users log off instead of just closing the RDP window. Set a group policy to end disconnected sessions after a timeout—that way, even if someone forgets, the session gets cleaned up automatically. In Group Policy Management, go to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits, and set "Set time limit for disconnected sessions" to something like 10 or 15 minutes. That's saved me from a lot of midnight calls.
Also, if you're running services that create logon sessions (like a custom Windows service), make sure they handle shutdown gracefully—implement a proper OnStop method that cleans up any impersonation or logon handles. The error is less likely to happen when the service exits cleanly.
Note: If you're on Windows 10/11 Home, you don't have RDP server support, but you might still see this error with local user switches. The same
qwinstaandrwinstacommands work on those editions, but you'll likely need to be in Safe Mode with Networking to run them if you're locked out.
That's the whole fix. I know the error code looks scary, but it's really just a stale session. Start with qwinsta, kill the duplicate, reboot if you have to. And set that timeout policy—you'll thank yourself later.