Fixing EXCEPTION 0X80000004 STATUS_SINGLE_STEP in Windows Debugging

Quick answer: In most debuggers, just hit 'Continue' (F5 in Visual Studio) or ignore the exception. If it keeps crashing your program, disable hardware breakpoints or remove any anti-debug code that sets the Trap Flag.

What the Heck Is This?

EXCEPTION (0X80000004) is STATUS_SINGLE_STEP. It happens when the CPU's Trap Flag (TF) is set in the EFLAGS register. Every instruction after that triggers this exception. It's how debuggers do step-into — they set TF, run one instruction, catch this exception, and repeat.

You'll see it most often when:

• You're stepping through code in Visual Studio or WinDbg
• An anti-debug tool or packer (like Themida or VMProtect) sets TF to detect debuggers
• A driver or kernel-mode code leaves TF on by accident
• You're using Intel's ICE (In-Circuit Emulator) breakpoints — rare these days

If you're not stepping and it pops up, something set TF behind your back.

Fix Steps

Step 1 — Just Ignore It (Most Cases)

If you're in a debugger and you didn't ask for single-step, just press F5 or 'Go'. The debugger handles it automatically. This isn't really a bug — it's a feature of how CPUs work. Don't waste time chasing it if your program runs fine after continuing.

Step 2 — Check for Hardware Breakpoints

Hardware breakpoints can leave TF set. In Visual Studio, go to Debug > Windows > Breakpoints (or hit Ctrl+Alt+B). Look for any hardware breakpoints (marked with a little chip icon). Delete them all, then try again.

In WinDbg, run bl to list breakpoints. If you see any with Address that aren't software (e breakpoints), those are hardware. Clear them with bc *.

Step 3 — Kill Anti-Debug Tricks

If you're debugging a packed or protected EXE, the protector sometimes sets TF to trap you. The fix: patch out the anti-debug code before you start. Use a tool like ScyllaHide (x64dbg plugin) or OllyDbg's hide-debug plugin to mask your debugger. Or, in a pinch, NOP out the pushf; ... popf sequence that plays with TF.

Step 4 — Reset the Trap Flag Manually

If you're in kernel mode or writing a driver, you can clear TF with inline assembly. In C/C++:

__asm pushfd
__asm and dword ptr [esp], 0xFFFFFEFF
__asm popfd

Or with intrinsics on x64 (no inline asm):

#include <intrin.h>
unsigned long long eflags = __readeflags();
eflags &= ~0x100; // clear TF bit 8
__writeeflags(eflags);

Put this at the start of your handler or at a point where you know TF is set.

Alternative Fixes if the Main Ones Fail

Try a different debugger. x64dbg handles single-step exceptions more gracefully than older versions of OllyDbg. Or switch to WinDbg for kernel-level stuff — it lets you set exception filters.

Set exception filter in Visual Studio. Go to Debug > Windows > Exception Settings. Find 'Win32 Exceptions' and check '0xC0000004' (that's the same as 0x80000004 in NTSTATUS form). Uncheck it to tell VS to stop breaking on this exception.

Check for bad driver or hardware. Rare, but a faulty motherboard or CPU (especially from overclocking) can cause false single-step traps. Run Prime95 or MemTest86 to rule it out. If that's the case, drop your overclock or replace the hardware.

Prevention Tips

• Don't leave hardware breakpoints active after you're done debugging — they can trigger on other threads.
• If you write anti-debug code for your own apps, handle STATUS_SINGLE_STEP properly (call SetUnhandledExceptionFilter or override the vectored exception handler).
• When working with packers or protectors, always use a dedicated anti-anti-debug tool. Saves hours of headache.

Bottom line: 0x80000004 is usually noise. Only sweat it if your app crashes or you can't continue. In 14 years, I've seen maybe 3 cases where it was a real bug — and each one was a kernel driver leaving TF on. 99% of the time, hit F5 and move on.