Quick answer
A thread called ExitThread or TerminateProcess on itself in a way Windows won't allow — the fix is to find the crashing process, update or roll back whatever driver or app is doing it, and cleanup the bad DLLs it left behind.
What this error actually means
Windows has rules about how a thread is allowed to die. When a thread calls ExitThread with a nonzero exit code, or when TerminateProcess is pointed at the current process, the kernel expects the thread to be in a clean state — no pending I/O, no user APC queued, no critical section still held. If the thread is mid-operation and tries to pull the plug on itself anyway, the kernel raises STATUS_CANT_TERMINATE_SELF, which Win32 surfaces as error 0x0000022B (decimal 555).
You'll usually see it in one of three places: a crash dialog from a background app, an event log entry under Application with source Application Error, or a bugcheck (BSOD) with 0x0000022B in the minidump. The message is misleading — the thread didn't "fail to terminate" because Windows is broken. It failed because the code asked it to terminate at a point where that's illegal.
Real-world trigger: it shows up a lot after antivirus or EDR products update in place. The old kernel filter driver is still loaded, the new user-mode service loads against it, and when the service tries to exit cleanly during the update, its thread is still holding a callback into the driver. Boom — 0x22B.
Step-by-step fix
Step 1: Identify which process is throwing it
- Press Win + R, type
eventvwr.msc, hit Enter. Event Viewer opens. - In the left pane expand Windows Logs and click Application.
- In the right pane click Filter Current Log. In the Event IDs box type
1000,1001,1002. Click OK. - Sort by Date and Time descending. Look for the newest red Error entry. The General tab lists the faulting application name, version, and the faulting module (usually a
.dll).
After you click OK, the list reloads and you should see only application errors. If the list is empty, the error isn't being logged — jump to Step 3 and check the System log instead.
Step 2: Update the faulting module
Note the DLL name from Step 1. Nine times out of ten it belongs to a third-party driver or security product. Common offenders I've seen in the field: mfehidk.sys (McAfee), SymEFASI64.sys (Symantec), atc.sys (older ASUS Aura), and nvlddmkm.sys on stale NVIDIA builds from 2022.
- Open an elevated Command Prompt (right-click Start → Terminal (Admin)).
- Run
wmic service get name,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v "C:\\Windows"to list non-Microsoft auto-start services. Any of them match your faulting module? Uninstall or update that product first. - Reboot. Recheck the Application log after 10 minutes of normal use.
Step 3: If nothing's logged, use Driver Verifier
Driver Verifier forces every driver to be honest. Enable it briefly and the offending one will bluescreen with a minidump you can read.
verifier /standard /all
verifier /querysettings
After running the first command you should see a confirmation that verification is enabled. Reboot. Reproduce the error. Windows will bugcheck with the driver name on the blue screen. When you're done, turn it off before you forget:
verifier /reset
Leaving Driver Verifier on will tank performance and cause crashes on healthy systems. Don't skip the reset.
Step 4: Clear the crash artifacts
Old .dmp files and stale WER reports can re-trigger the same faulting app on next launch if the app caches crash state. Clean them out:
del /q %LOCALAPPDATA%\CrashDumps\*
del /q %ProgramData%\Microsoft\Windows\WER\ReportQueue\*
del /q %ProgramData%\Microsoft\Windows\WER\ReportArchive\*
You should see no output if the folders were empty. If you get "Access is denied" on any file, it's still held open — close the faulting app and try again.
Alternative fixes
Roll back the last Windows update
If 0x22B started right after a Patch Tuesday, the update is the trigger. Go to Settings → Windows Update → Update history → Uninstall updates. Pick the most recent cumulative rollup, click Uninstall, and reboot. This is especially common on the KB5034441 recovery partition updates from early 2024, which broke several backup agents.
Run an SFC and DISM pass
Corrupted system DLLs can also produce this error. Run both in order from an elevated prompt:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
DISM takes 5–15 minutes. SFC will report either "did not find any integrity violations" (good) or "found corrupt files and successfully repaired them" (also fine — reboot and test).
Check for the error in a specific app's own log
SQL Server, IIS worker processes, and .NET services write their own logs. 0x22B in %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log\ERRORLOG usually means a CLR stored procedure is hammering Thread.Abort(). Rewrite it to use CancellationToken instead — Thread.Abort is the number one cause of self-termination errors in managed code and Microsoft has deprecated it since .NET 5.
Prevention
Don't install two security products at once. Endpoint protection hooks the same kernel callbacks, and when one unloads during an update the other's thread state gets torn apart — that's your 0x22B. Pick one AV, whitelist it in Windows Defender, and let it be. Also, keep GPU and chipset drivers current; stale nvlddmkm.sys and amdkmdag.sys builds are a recurring source when apps with hardware acceleration exit during a display mode change.