0X00010002 Debugger Continued – Real Fix & Cause

If you're staring at the 0X00010002 error in your debugger, you already know how frustrating it is when breakpoints get ignored and execution just keeps rolling. I've been there — working late on a memory corruption bug in a C++ project, and the debugger just says “nope, moving on.” Let's fix that.

The Fix: Your Debugger Is Being Overridden by Someone Else

The most common reason for DBG_CONTINUE (0X00010002) is that two debuggers are attached to the same process, or one debugger is being controlled by another debugger (like a kernel debugger or a parent process debugger). Windows only allows one user-mode debugger per process at a time, but kernel debuggers can still send continue commands that override your user-mode breakpoint.

First thing to check: Is a kernel debugger (like WinDbg in kernel mode) active? If you're on a machine that's been set up for kernel debugging (often done via BCDEDIT), that debugger can swallow your breakpoints. Here's how to turn it off:

bcdedit /debug off
bcdedit /deletevalue {current} debug

Then restart the machine. That's it. I had a client last month who couldn't debug their .NET service because they'd enabled kernel debugging years ago for driver work and forgot. Once we turned it off, breakpoints hit perfectly.

Second check: Are you running under a debugger that's already attached? For example, if you start your app from within Visual Studio, but also attach a second instance of WinDbg to the same process, the first debugger (Visual Studio) might receive the DBG_CONTINUE from the second one. Solution: close all debuggers, restart your app from scratch, and attach only one debugger.

Why This Happens

The DBG_CONTINUE status code is part of the Windows debugging API. When a debugger receives a debug event (like a breakpoint exception), it must reply with either DBG_EXCEPTION_HANDLED (0x00010001) or DBG_CONTINUE (0x00010002). DBG_CONTINUE means “I'm ignoring this exception — let the process handle it.” If another debugger sends that response before your debugger does, your breakpoint is skipped.

In short: something else is telling Windows to ignore the breakpoint. Usually that's a kernel debugger or a parent process debugger. It can also happen if your app has anti-debug code that calls ContinueDebugEvent with DBG_CONTINUE, but that's rarer in normal development.

Less Common Variations

1. The Subprocess Scenario

If you're debugging a process that spawns child processes, and you attach to the child, the parent debugger might still be alive. That parent debugger can send DBG_CONTINUE for events in the child. I've seen this with installer frameworks that run helper EXEs. The fix: debug the child process independently by launching it manually, or use a debugger that can follow forks (like GDB on Linux with set follow-fork-mode child). On Windows, just attach after the child starts.

2. Visual Studio “Just-In-Time” Debugger Interference

Another variant: the Visual Studio Just-In-Time debugger (VSJITDebugger.exe) might be registered as the default debugger for your process. When you hit a breakpoint, VSJITDebugger grabs the event, decides to continue, and your real debugger never gets it. To fix, you can disable JIT debugging or reassign the debugger. Open Visual Studio, go to Tools > Options > Debugging > Just-In-Time, and uncheck the managed/native boxes. Restart your app.

3. Third-Party Profilers or Anti-Virus Hooking

Some profilers (like Intel VTune, AMD CodeXL) and aggressive anti-virus software hook into debug events. They might artificially send DBG_CONTINUE to skip breakpoints they don't understand. If the above fixes don't work, temporarily disable any profilers or AV software (especially if it has “behavior monitoring” features). I worked with a startup whose app would never stop on breakpoints — turned out their AV was intercepting debug events as a “protection” measure.

How to Prevent This from Coming Back

Always check for kernel debugging. Run bcdedit /enum and look for a debug entry. If it's there and you don't need it, disable it.
Use only one debugger instance per process. If you need multiple debuggers, attach them to different processes or use remote debugging instead.
Be careful with parent-child process debugging. Detach the parent debugger before attaching to the child, or use a debugger that supports non-invasive attach (like WinDbg's noninvasive mode: .attach 0n[PID]).
Test on a clean machine. If you suspect third-party interference, spin up a VM with a minimal install of Windows and your dev tools only. That isolates the issue fast.

DBG_CONTINUE is rarely a bug in your debugger — it's almost always a configuration collision. Track down the extra debugger or hook, kill it, and you're back to normal. Remember: one debugger per process, no kernel debuggers for user-mode work, and watch out for subprocesses. That'll save you hours of head-scratching.