Fix STATUS_UNFINISHED_CONTEXT_DELETED 0XC00002EE

A Windows security context got deleted mid-handshake. Usually happens with old SMB connections or busted Kerberos tickets. Restarting services or flushing caches fixes it.

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)

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