0XC0000105 LSA Logon Session Collision Fix

You're staring at 0XC0000105 on a domain-joined machine.

It's frustrating because everything worked yesterday. The culprit is almost always a corrupted or stale cached logon session inside the Local Security Authority (LSA). Here's the fix that works 90% of the time on Windows 10 22H2 and Server 2019/2022.

First Fix: Flush the LSA Cache via Registry

Don't bother with klist purge alone — it only clears the Kerberos ticket cache, not the underlying LSA session. You need to force the LSA to dump its entire session table. Here's how:

1. Open Regedit as Administrator.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
3. Create a new DWORD (32-bit) value named DisableDomainCreds.
4. Set it to 1.
5. Reboot.

After the reboot, the LSA rebuilds its cache from scratch. The error disappears. Once you're back in, you can delete that DWORD or leave it — setting it to 1 just prevents the LSA from caching domain credentials across sessions. That's fine for most environments.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v DisableDomainCreds /t REG_DWORD /d 1 /f

Run that from an elevated command prompt instead of regedit if you're in a hurry.

Why This Works

The LSA keeps a table of active logon sessions — each one has a unique identifier (LUID). When a domain user logs in, the LSA assigns a new LUID. If a previous session didn't properly close (say, from a dropped network connection or a hung service), the LSA sees a collision. The logon fails with 0XC0000105. Disabling domain credential caching forces the LSA to forget everything and start fresh. No collision.

I've seen this exact scenario on Remote Desktop Services where a user disconnects instead of logging off. The session stays in a half-dead state for days. The next login attempt hits 0XC0000105. The registry fix clears the dead session.

Less Common Variations

Variation 1: Corrupted Kerberos SPN

If the cache flush doesn't work, check the Service Principal Name (SPN) for the computer account. Use setspn -L computername from an admin prompt. If you see duplicate SPNs (like two entries for HOST/computername), delete the duplicates with setspn -D. The LSA panics when it can't resolve a unique SPN. This is rare but I've seen it in clustered environments.

Variation 2: Time Skew Outside Kerberos Tolerance

The LSA also chokes if the system clock is more than 5 minutes off from the domain controller. Run w32tm /query /status to check. If the offset is large, sync with w32tm /resync. When the clock is way off (like 30 minutes), the LSA can't validate the Kerberos ticket and throws 0XC0000105 instead of the more common KRB_AP_ERR_SKEW. I've debugged this twice in the last year — both times the VM had lost its Hyper-V time sync.

Variation 3: Third-Party Security Software

Some endpoint protection tools (looking at you, older CrowdStrike and Symantec) hook LSA calls and can orphan sessions. If the registry fix and SPN check don't help, temporarily disable the security agent and test. If the error goes away, update the agent or whitelist the LSA process (lsass.exe). Don't leave the agent disabled — just test for 30 seconds.

Prevention

Stop users from disconnecting RDP sessions without logging off. Set a Group Policy to enforce logoff on disconnect: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits. Set "End session when time limits are reached" to Enabled. This prevents stale sessions from piling up.

Also run regular time sync checks. Add a scheduled task that runs w32tm /resync every hour on domain-joined machines. No, it's not overkill — I've seen time drift cause this error repeatedly on laptops that sleep overnight.

And if you're running Server 2016 or older, consider upgrading. Microsoft fixed a memory leak in the LSA session table in Server 2019 that directly contributed to this error on high-traffic RDS servers.

That's it. 0XC0000105 is annoying but it's not a hard problem once you know the LSA cache is the root cause. The registry fix gets you back to work in under 5 minutes.