0xC0000421: App Verifier found a real bug — here's what to do

App Verifier caught an invalid memory access or handle misuse in your process. 99% of the time it's a bug in a third-party DLL or driver, not your app.

Quick answer (for advanced users)

Open regedit, delete HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\your.exe or run gflags /p /enable your.exe /full to see which DLL is causing the violation. Then remove or update that DLL.

What this error actually means

You're staring at a STATUS_VERIFIER_STOP (0xC0000421) crash — a stop code the Application Verifier fires when it detects a program doing something it shouldn't. Think of App Verifier as a paranoid security guard: it watches every memory allocation, every handle open, every lock taken. When it sees a double-free, a use-after-free, a bad handle, or a thread synchronization slip-up, it halts the process immediately with this code.

The trigger is almost always a third-party DLL injected into your process — antivirus hooks, GPU overlays, audio enhancers, or those old printer drivers that were never updated past Windows 7. Your code might be innocent, but the DLL it loads is not.

Why this happens

Application Verifier is enabled per-image in the registry under Image File Execution Options. You might have enabled it manually via gflags.exe or it was enabled by a developer tool (Visual Studio debugger, WinDbg, or the Windows Driver Kit). Once active, Verifier hooks low-level functions (HeapAlloc, CloseHandle, CreateThread) and runs sanity checks on every call. The moment a violation occurs, it calls DbgBreakPoint and returns the STATUS_VERIFIER_STOP exception to whoever is debugging.

The real fix isn't to turn off Verifier — it's to find what's causing the violation. But if you just want the crash gone, here's the straightforward path.

Fix steps

Check which process is crashing — Look at the error dialog or Event Viewer. The crash is tied to a specific executable name, like notepad.exe or chrome.exe.
Run eventvwr.msc, go to Windows Logs > Application, find the Event ID 1000 or 1001 entry. It will name the faulting module.
Identify the violating DLL —
If you have WinDbg or Visual Studio attached, the call stack will show the Verifier's stop reason. If you don't, enable full App Verifier logging: gflags /p /enable your.exe /full then reproduce the crash. The log file (%USERPROFILE%\AppData\Local\Temp\verifier.log) will contain the precise check that failed (e.g., "AVRF_STOP_ALWAYS_BAD_HANDLE").
Update or remove the offending DLL —
If the violation is in nvidiaopengl.dll, update your GPU drivers. If it's mfplat.dll from an audio utility, uninstall that software. Use Process Explorer (from Sysinternals) to see which DLLs your process loads — sort by company name and look for anything from Acme Audio Enhancer or OldPrinterCo.
Disable App Verifier for that executable —
Only do this if you can't fix the root cause and it's not your own code. Run gflags /p /disable your.exe as admin. Or in regedit, delete the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\your.exe.
```
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\your.exe" /f
```
Reboot and test —
The change is immediate, but some processes cache the setting. A reboot guarantees clean state.

If the main fix doesn't work

Check for a global Verifier setting —
Run verifier /query to see if Verifier is enabled system-wide (uncommon, but happens if a kernel driver flagged it). If you see settings, run verifier /reset to clear all Verifier rules.
Look for injected DLLs via AppInit or Shell Extensions —
Some DLLs inject themselves into every process via AppInit_DLLs or KnownDLLs. Check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs. If it's non-empty, the DLL listed there is loaded into every user-mode process — and maybe it's the one violating. Remove the value or set LoadAppInit_DLLs to 0.
Use Process Monitor to trace the crash —
Capture with procmon.exe, filter on Process Name = your.exe, and look for registry or file access to a DLL path that fails. A common one: a missing or corrupted DLL that Verifier flags because its import table is broken.

Prevention

Don't leave App Verifier enabled for production executables. It's a developer debugging tool, not a runtime monitor. If you're a developer, only enable it on your own binaries during testing, and clear the setting before shipping. For end users: keep third-party software (especially drivers and shell extensions) updated — old ones are the #1 source of Verifier violations.

Note: If you're developing your own application and you hit this, don't disable Verifier — fix the bug. Run it under WinDbg with .symfix; .reload; g then let it break at the violation. The debugger will show you exactly which source line caused it.