0X00000553

ERROR_LOGON_SESSION_EXISTS (0X00000553) Fix

This error pops up when a logon session ID is already in use. Usually caused by orphaned sessions or misconfigured services. Here's the fix.

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.

  1. Press Ctrl+Alt+Delete and select Sign out. Wait 30 seconds.
  2. 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 session

You'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  rdpwd

Look 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 ID

So 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\Lsa

Step 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, StartTime

LogonType 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-WmiObject

Replace [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.

Related Errors in Windows Errors
0X000002DA Error 0x000002DA: Wake System Bug Fixed (Real Fix) 0XC00D1005 Fix NS_E_WMP_JPGTRANSPARENCY (0XC00D1005) in 2 Steps 0X000000C9 Fix ERROR_RELOC_CHAIN_XEEDS_SEGLIM (0x000000C9) on Windows 0x0000009F Fix Power Management Driver Failure on Windows 10/11

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.