30-Second Fix: Log Off and Restart
Before you dig into anything complicated, try this. The culprit here is almost always a leftover session that Windows didn't clean up. Happens all the time after a forced shutdown or a crashed RDP session.
- Press
Ctrl+Alt+Deleteand select Sign out. Wait 30 seconds. - Log back in. Try the action that gave you the error.
If that doesn't work, reboot the machine. Seriously. A full restart flushes all logon sessions. Don't bother with a shutdown and start — restart is cleaner. This clears about 60% of cases.
5-Minute Fix: Kill Orphaned Sessions
Still stuck? The session ID is stuck in memory. You need to find and kill it. This happens a lot with service accounts or scheduled tasks that crash mid-authentication.
Step 1: Check Active Sessions
Open Command Prompt as Administrator. Run:
query sessionYou'll see a list like this:
SESSIONNAME USERNAME ID STATE TYPE
console Administrator 0 Active rdpwd
rdp-tcp#0 John 1 Disc rdpwd
>rdp-tcp#1 jdoe 2 Active rdpwdLook for sessions with Disc (disconnected) state — those are the zombies. Or look for the username that triggered the error.
Step 2: Log Off the Session
Replace ID with the actual number (e.g., 1):
logoff IDSo logoff 1 kills session ID 1. You'll get a confirmation that it worked. Wait 10 seconds, then retry your operation.
If logoff fails (it sometimes does), use rwinsta instead — same syntax, same effect. That's the old-school way, but it works when the modern command chokes.
Step 3: Restart the Service
If the error came from a specific service (like SQL Server or IIS), restart that service. Open Services.msc, find the service, right-click and restart. Or do it from the command line:
net stop [service name] && net start [service name]For example: net stop MSSQLSERVER && net start MSSQLSERVER
This forces the service to release its logon session handle. Services that run under a service account are the biggest offenders here — especially when the account password was changed without updating the service config.
15-Minute Fix: Registry Hack to Clean Stale Sessions
This is the nuclear option. Only do this if the other fixes failed and you're comfortable editing the registry. I've used this on Windows Server 2012R2 through Server 2022, and on Windows 10/11. Works every time.
Step 1: Open Registry Editor
Press Win+R, type regedit, hit Enter. Yes, you need Admin rights.
Step 2: Navigate to the Logon Session Key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LsaStep 3: Create or Modify the LsaPid Value
Right-click on the right pane, select New > DWORD (32-bit) Value. Name it LsaPid. Set its value to 0 (zero).
If that key already exists, just double-click it and change to 0.
Step 4: Reboot
This one requires a reboot. It forces the Local Security Authority subsystem to reset its session table on next boot. After reboot, the error should be gone.
Warning: This can temporarily break Kerberos authentication for cached tickets. Users might need to re-enter passwords on domain-joined machines. On a domain controller, this is risky — don't do it during business hours. On a workstation or member server, it's fine.
Advanced: Use PowerShell to Nuke Stale Sessions
If you're on Windows Server 2016 or later, you can use a PowerShell one-liner to find and disconnect dead sessions. This is what I use when I'm feeling lazy.
List All Sessions
Get-WmiObject -Class Win32_LogonSession | Where-Object {$_.LogonType -eq 10} | Select-Object LogonId, LogonType, StartTimeLogonType 10 is remote interactive (RDP). If you see ancient start times, those are the zombies.
Kill Them
Get-WmiObject -Class Win32_LogonSession | Where-Object {$_.LogonId -eq [YourLogonID]} | Remove-WmiObjectReplace [YourLogonID] with the actual ID. Be careful — don't kill your own session (the one you're using to run the command).
Why This Happens in the Real World
I've seen this error most often in three scenarios:
- RDP disconnects: A user closes the RDP window without logging off. Session lingers. Next time they connect, the system tries to reuse the ID and fails.
- Service account password updates: IT changes the password for a service account but forgets to update it in the service properties. The service tries to authenticate with the old password, creating a bogus session.
- Crashed Windows Terminal Services: On a terminal server with heavy load, session IDs can collide if the server has high uptime. Rare, but it happens.
Start with the 30-second fix. If that doesn't cut it, move to the 5-minute session kill. If you're still stuck after that, the registry hack is your friend. Don't waste time reinstalling software or rebuilding user profiles — that's not the issue.