STATUS_UNFINISHED_CONTEXT_DELETED (0XC00002EE) Fix

Quick answer

Run klist purge as admin, then restart Workstation and Netlogon services. If it's a server, reboot it. That clears the busted security context.

Why you're seeing this

This error pops up when Windows tries to complete an authentication handshake — usually over SMB or Kerberos — but the security context (the temporary data structure holding the session keys) got deleted before the handshake finished. Think of it like a phone call where someone hangs up while you're mid-sentence. The most common scenario: a domain-joined machine tries to access a file share on a server, but the Kerberos ticket expired or a network hiccup killed the connection. I fixed this last month for a client whose file server kept dropping connections after a power outage — the LSASS cache got corrupted.

Fix steps (in order)

1. Flush Kerberos tickets. Open Command Prompt as Administrator and run klist purge. This nukes all cached tickets. If you're on a domain, might need to re-authenticate after.
2. Restart key services. Run net stop workstation && net start workstation, then net stop netlogon && net start netlogon. The Workstation service handles SMB connections; Netlogon manages secure channel to the domain controller.
3. Clear SMB cache. In an admin PowerShell, run net session /delete to drop all active SMB sessions. Then Remove-SmbSession -Force -ErrorAction SilentlyContinue for good measure.
4. Check LSASS health. Open Event Viewer, go to Windows Logs > System. Look for LSASS errors (source: LSASS or Security-Kerberos). If you see crashes, you might have a corrupted LSA policy — run sfc /scannow to fix system files.
5. Reboot. If none of the above worked, shutdown /r /t 0. Sometimes it's the only way to reset the kernel's security context pool.

Alternative fixes if the main ones fail

Check domain controller connectivity

Run nltest /dsgetdc:yourdomain.local. If it fails, your machine can't reach a DC. Fix DNS first — this error often masks a DNS resolution failure.

Repair LSA cache

If the issue persists after rebooting, your LSASS process might have a corrupt cache. Boot into Safe Mode with Networking, run lsass.exe /regserver from an admin command prompt, then reboot normally. Had to do this on a Windows Server 2019 that wouldn't authenticate anyone.

Disable SMB signing (temporary test only)

In advanced cases, SMB packet signing can cause timing issues. Disable it for testing: open gpedit.msc > Computer Config > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always) > set to Disabled. Reboot, test. If it works, re-enable and look for the real culprit (usually a misconfigured firewall or third-party antivirus).

Prevention tips

• Keep your Windows up to date — Microsoft patched several LSASS bugs in KB5031356 and later.
• Avoid flaky network paths between clients and domain controllers. Use redundant DNS servers and static IPs for DCs.
• If you see this error repeatedly on a server, monitor LSASS memory usage with Performance Monitor. Sudden spikes often indicate a resource leak that needs a full reboot.
• Third-party antivirus that hooks LSASS (like old Symantec Endpoint Protection) loves to break security contexts. If none of the above helps, try disabling the AV temporarily.

Real talk: I've seen this error most often after someone force-killed an SMB session or a domain controller rebooted mid-authentication. It's almost never a hardware fault — it's a software state problem. Flush, restart, reboot. If that fails, you've got deeper issues.