Fix STATUS_BAD_LOGON_SESSION_STATE (0XC0000104) fast

What's happening with 0XC0000104?

I know this error is infuriating. You're trying to access a network share, RDP into a server, or run an application that uses your current Windows logon session — and boom, STATUS_BAD_LOGON_SESSION_STATE (0XC0000104). The message says it all: your logon session is in a weird state, and Windows won't let the operation proceed.

This usually happens after a password change where you didn't fully log off, or when a Kerberos ticket expires mid-session. I've seen it on Windows 10 22H2 and Windows 11 23H2 after overnight lock screens. The session is still alive but stale — Windows thinks you're logged in, but the authentication tokens are garbage.

Let's fix it, starting with the dumbest thing that works.

Fix 1: The 30-second restart (works 50% of the time)

Try this first. It's not dramatic, but I've seen it fix the error more times than you'd think.

1. Press Ctrl+Alt+Del and select Sign out.
2. Wait 10 seconds (the session needs to fully die).
3. Log back in with your password — not a PIN, not Hello face scan. Use the actual password.

If that gives you the error on logon, do a full reboot instead. Restart, not shut down. Windows 10 and 11 use Fast Startup by default, which can preserve the broken session state. A restart forces a clean session creation.

Fix 2: Clear cached credentials (5 minutes)

If the reboot didn't kill it, the problem is likely a stuck cached credential from an old password. This happens when you changed your domain or Microsoft account password and Windows didn't update the cached copy. The logon session still holds the old hash.

1. Open Credential Manager — press Win+R, type control keymgr.dll, hit Enter.
2. Click Windows Credentials.
3. Look for any entries that match the resource you're trying to access. Generic, weird named ones too. If you see something like TERMSRV/your-server-name or a network share path — delete them.
4. Also check Windows LSA secrets at the bottom. Yes, that's scary looking. Right-click and remove anything that seems related to your domain or server.

After deleting, reboot again (yes, again) and try the operation. I've had cases where a single stale RDP credential caused this error on every subsequent logon. Clearing it fixed it instantly.

Fix 3: Nuke the logon session via PowerShell (15+ minutes, advanced)

This is the nuclear option. If you're still seeing the error, the session object itself is corrupted in the LSA (Local Security Authority) subsystem. You need to kill it manually.

Step 1: Identify the bad session

Open PowerShell as Administrator. Run this command to list all active logon sessions:

query session

You'll see a list like console, rdp-tcp#0, etc. Look for your session — it's usually the one with your username. Note the ID number (e.g., 1, 2, 3).

Step 2: Log off that session

Run this, replacing SESSIONID with the actual number:

logoff SESSIONID

This sends a force logoff. If it fails with Access denied, it means another user's session is interfering or you're trying to log off your own session while in it. In that case, you need to kill it differently.

Step 3: Kill the LSA process (last resort)

If logoff doesn't work, the session is stuck deep. You'll need to restart the Local Security Authority Subsystem Service. This is drastic — it logs off everyone on the machine, including you.

1. Open Task Manager (Ctrl+Shift+Esc).
2. Go to the Services tab.
3. Find LSM (Local Session Manager) or LSASS.EXE under Processes.
4. Right-click LSASS.EXE and select End process. Windows will warn you this will crash the system. Confirm.

The machine will blue screen and restart. That's fine. After reboot, the error should be gone. I've used this on Windows Server 2019 and Windows 11 when nothing else worked.

When none of this works

If you're still stuck after killing the session, you might have a deeper issue: a corrupt user profile or a domain controller time sync problem. Check that your system time is within 5 minutes of the domain controller — Kerberos gets fussy beyond that. If you're on a standalone machine, create a new local user account and migrate your files. Sorry, sometimes that's the cleanest fix.

One last thing — don't bother with SFC or DISM for this error. They fix system files, not logon session state. Save yourself 20 minutes.