Fix STATUS_INVALID_UNWIND_TARGET 0xC0000029 Crash

When You'll See This Error

You'll hit STATUS_INVALID_UNWIND_TARGET (0xC0000029) as a bug check (BSOD) or an application crash. The trigger is almost always during structured exception handling — when Windows tries to unwind the call stack after an exception but finds an invalid target address. I've seen it most often on Windows 10 20H2 and Windows 11 after a driver update, or when a third-party antivirus driver intercepts exception handling.

What's Actually Happening

When an exception occurs (like an access violation), the kernel walks the stack looking for a handler — a __try/__except block or a filter. The unwind operation needs to jump to a valid function start. If the target address points into the middle of a function, or to memory that's been freed or corrupted, you get this error. It's a safety check — Windows won't jump to a random address. The root cause is almost always a corrupt binary, a bad driver that stomped on exception metadata, or memory corruption from faulty RAM.

The culprit here is almost always a third-party driver. Rarely it's a corrupted system file or bad hardware. Don't waste time on simple reboots — you need to identify the specific driver or binary involved.

Step-by-Step Fix

Get the crash dump. If you're getting BSODs, configure Windows to keep mini dumps. Go to System Properties > Advanced > Startup and Recovery > Settings and set "Write debugging information" to "Small memory dump (256 KB)". Reproduce the crash.
Analyze the dump with WinDbg. Open the dump file in WinDbg (WinDbg Preview from the Microsoft Store is fine). Run !analyze -v. Look for the line that says IMAGE_NAME or MODULE_NAME. That's the file causing the unwind target to be invalid. I've seen xxx.sys (some driver) or ntoskrnl.exe (rarely). If it's a driver, that's your target.
Run Driver Verifier. Open verifier.exe as Administrator. Select "Create standard settings" and click Next. Then "Select driver names from a list". Click "Provide a list of all drivers currently loaded on this machine" and wait for the list. Check ONLY the driver identified in step 2. If you don't have a clear candidate, start with all non-Microsoft drivers. Reboot and let Verifier stress the driver. If it crashes again, you'll get a more precise dump.
Update or remove the bad driver. If you identified the driver (say acpi.sys or blahwifi.sys), find its version. Go to Device Manager, find the device, right-click Properties > Driver. Check the date and version. If it's an OEM driver, download the latest from the manufacturer. If it's third-party (like a VPN or antivirus filter driver), disable or uninstall the software temporarily.
Run SFC and DISM. Even if it's a driver problem, corrupted system files can trigger this. Open a command prompt as Administrator. Run sfc /scannow. Then DISM /Online /Cleanup-Image /RestoreHealth. This fixes core OS files that might have corrupt exception handling tables.
Check for memory corruption. Run Windows Memory Diagnostic (mdsched.exe). Let it reboot and run the extended test. Bad RAM causes unpredictable behavior, including corrupt unwind targets. If you see any errors, replace the RAM stick.
Test your application in isolation. If the crash happens with a specific app (say a game or CAD tool), try running it with all background services disabled. Use msconfig to do a clean boot. If the crash stops, re-enable services one by one to find the conflict.

If It Still Fails

You've done the heavy lifting but the error persists? Look at the stack trace more carefully. Run k in WinDbg after the analysis to see the call stack. If you see nt!KiExceptionDispatch or nt!RtlUnwind at the top, the issue is deep in kernel exception handling. That usually means a corrupted SSDT (System Service Descriptor Table) from a rootkit or a very broken driver. In that case, boot from a clean Windows USB and run a repair install. That replaces the kernel and all system drivers without touching your data.

If you're running a VM (Hyper-V, VMware), make sure VM integration tools are up to date. Old integration drivers can inject bad unwind targets into the guest. I've fixed this error on three separate Server 2019 hosts just by updating VMware Tools to version 11.3.5 or later.

Skip chasing registry keys for this one — it's almost never a registry issue. Don't bother with system restore either. The error is too specific to the running code. Focus on the driver or binary that's actually in the dump.