Fix STATUS_CANT_TERMINATE_SELF (0xC00000DB) on Windows

I know this error is infuriating. You're mid-task, maybe closing an app or shutting down, and suddenly you get a stop code full of underscores that looks like someone fell asleep on the keyboard. 0xC00000DB isn't random, though. Windows is telling you something specific: a thread tried to terminate itself while it was still inside its own cleanup routine.

In plain English, a process was tearing itself down, and a thread inside that process tried to call ExitThread or TerminateThread on itself before the teardown finished. The kernel refuses, and you get a crash. It's a race condition, and it's almost always caused by one of three things: a misbehaving driver, a corrupted system file, or a third-party app that hooks into the shutdown path.

Let's fix it. Start at the top of this list and work down.

Cause 1: A misbehaving driver is racing with shutdown (most common)

I see this most often with antivirus filter drivers, VPN adapters, and older GPU drivers. Real-world trigger: you click Shut Down, the screen sits on "Shutting down..." for 30 seconds, then bluescreens with 0xC00000DB. Or you close a specific app, and it crashes the whole system instead of just itself.

The driver doesn't exit cleanly. It keeps a thread alive that tries to self-terminate while Windows is already unloading it. The kernel catches the contradiction and stops the box.

Step 1: Check the crash dump for the culprit driver

You need to know which driver was on top when it crashed. Grab the minidump from C:\Windows\Minidump and read it with WinDbg or BlueScreenView. BlueScreenView is easier for most people. Look at the driver name in the top frame, not the Microsoft ones. If you see nvlddmkm.sys, iaStorAC.sys, wdfilter.sys, or anything with a vendor name, that's your target.

Step 2: Roll back or update that driver

Don't just update. If the crash started after a recent update, roll back first. Open Device Manager, find the device, right-click, Properties, Driver tab, and hit Roll Back Driver. If that option is greyed out, uninstall the device and reboot so Windows re-detects it.

For GPU drivers specifically, use DDU (Display Driver Uninstaller) in safe mode, then install a known-good version. Don't trust GeForce Experience to clean up after itself. It won't.

Step 3: Temporarily disable third-party filter drivers

Antivirus, VPN clients, and disk encryption tools all install filter drivers that load at boot. If you can't pinpoint the culprit, run this from an admin Command Prompt to see what's loaded:

fltmc filters

Anything not from Microsoft is a candidate. Uninstall it, reboot, and see if the crash stops. If it does, you've found your problem, and you can decide whether to switch tools or just live with the newer version that fixes it.

Cause 2: Corrupted system files in the process teardown path

This one's sneakier. The crash appears randomly, sometimes during a Windows Update, sometimes when you close a game, sometimes at idle. There's no obvious pattern, and the minidump points at ntoskrnl.exe with no third-party driver in sight.

What's happening: a core Windows binary that handles process termination got corrupted. The thread is running corrupted code, so its self-termination logic is broken. Windows can't trust it, and you get the stop code.

Step 1: Run SFC and DISM in the right order

Order matters here. DISM first, then SFC. Running SFC alone on a damaged component store often fails silently or reports "no issues" when there clearly are issues.

Open an elevated Command Prompt (Win + X, then A) and run:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Let DISM finish before you touch SFC. It can take 10-20 minutes. If SFC reports "Windows Resource Protection found corrupt files and successfully repaired them," reboot and test. If it says it found corrupt files but couldn't fix them, you'll need to grab a known-good copy of the file from another Windows install of the same build, or do an in-place repair install.

Step 2: Check for pending update corruption

If the crash happens during Windows Update, the update payload itself might be corrupted. Clear the update cache:

net stop wuauserv
net stop bits
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
net start wuauserv
net start bits

Then retry the update. Nine times out of ten, this clears it. The tenth time, you've got a deeper component store problem and DISM /RestoreHealth with a mounted ISO as the source is the real fix.

Cause 3: A third-party app is hooking ExitThread / TerminateThread

This is the one people miss. Some apps install DLLs that inject into other processes. Screen recorders, RGB controllers, overlay tools (Discord's overlay, Steam's overlay, MSI Afterburner), and older game mods are all guilty. When the host process shuts down, the injected DLL's thread tries to terminate itself mid-cleanup, and boom.

The classic real-world trigger: you close a game, and instead of returning to the desktop, you get 0xC00000DB. Or you exit a full-screen app and the whole system goes down with it.

Step 1: Boot clean to confirm

Run msconfig, go to Services, check "Hide all Microsoft services," then Disable all. Go to Startup, open Task Manager, disable everything. Reboot. If the crash stops, you've confirmed it's a hooking app.

Step 2: Re-enable in halves

Turn half back on, reboot, test. Binary search until you find the one app that triggers it. It's tedious but it's reliable, and it beats guessing.

Step 3: Update or replace the offender

If it's an overlay, disable hardware acceleration in that specific app. Discord's overlay is the most common culprit I see. Steam's overlay is second. If it's an RGB tool like iCUE or NZXT CAM, update to the latest version, because both have shipped fixes for exactly this kind of crash in the last two years.

If the app has no fix and you need it, set it to not start with Windows and launch it manually when you actually need it. That won't always help, but it reduces the exposure.

Quick reference: what to try, in order

One last thing: if you've tried all three and the crash persists, run verifier /standard /all from an admin prompt. Driver Verifier will stress every driver on the system and bluescreen the guilty one within a few hours. Just remember to turn it off with verifier /reset afterward, or you'll be chasing phantom crashes forever. I've seen people leave it on and spend a week debugging drivers that were fine.

That code isn't a mystery. It's Windows telling you a thread couldn't kill itself cleanly. Find the driver or DLL that's racing the shutdown, and you're done.