ERROR_DBG_EXCEPTION_HANDLED 0X000002FE: Debugger swallowed it

Quick answer for advanced users: this isn't an error you need to fix in your code. It's a status code the debugger generated internally. Uncheck Break when this exception is thrown in Visual Studio's Exception Settings (Ctrl+Alt+E), or in WinDbg use .exr -1 to confirm it's handled and ignore it.

What's actually happening here?

You're staring at ERROR_DBG_EXCEPTION_HANDLED (0X000002FE) in your debugger output window, and probably thinking something broke. I've been there. This tripped me up the first time too, back when I was debugging a memory allocator in Win10 20H2.

The thing is, 0X000002FE isn't a crash or a bug in your program. It's a notification from the Windows debug subsystem to the debugger itself. It says: "Hey, I threw an exception, but the debugger already took care of it — no need to break again."

Think of it like a smoke alarm that got silenced by the fire department before you heard it. You're just seeing the log entry that says "alarm silenced."

This usually pops up when you're debugging a user-mode application or a driver, and something like a memory access violation or integer overflow happens inside a try/catch block or an exception handler registered via AddVectoredExceptionHandler. The debugger catches it first, handles it (maybe sets a new instruction pointer), and then returns DBG_EXCEPTION_HANDLED. The OS logs that with code 0X000002FE.

Common triggers: running a .NET app with first-chance exceptions enabled, stepping through native C++ code with structured exception handling (SEH), or using WinDbg to debug a kernel driver that uses try/except.

How to fix it: step by step

1. Identify the debugger you're using. Visual Studio and WinDbg treat this differently.
2. For Visual Studio (all versions up to 2022):
   • Press Ctrl+Alt+E to open Exception Settings.
   • Uncheck "Break when this exception is thrown" for the specific exception type you see (e.g., System.AccessViolationException or 0xC0000005).
   • If you see the error often, uncheck the whole Win32 Exceptions category — but only do that if you're not debugging memory issues.
3. For WinDbg or WinDbg Preview:
   • Run .exr -1 to dump the last exception record. If it shows Handled as Yes, you're good.
   • Use sxd to suppress specific exception codes. Example: sxd 0x000002fe tells WinDbg to ignore it silently.
   • Alternatively, run sxi 0x000002fe to ignore it entirely and not even log it.
4. If you're using Visual Studio Code with the C++ extension:
   • Open launch.json and add "suppressExceptionNotifications": true under the configuration.
   • Or filter exceptions via the debugger UI (gear icon) -> Exception Settings.

Alternative fixes when the main one doesn't cut it

Sometimes the error keeps showing even after you've unchecked all the right boxes. Here's what else to try:

• Restart the debugger session. Yes, the boring reset. The debugger sometimes caches exception filters. Closing and reopening the debug session forces a clean state.
• Check for stale breakpoints. If you have a breakpoint set inside a try/catch block, the debugger might hit it after the exception is handled. Delete that breakpoint and re-set it on the line after the handler.
• Update your Visual Studio or WinDbg. I've seen older builds of VS 2019 (pre-16.6) mishandle DBG_EXCEPTION_HANDLED and break on it incorrectly. Visual Studio 2022 fixed this, but if you're stuck on an older version, try the Exception Settings workaround more aggressively.
• If you're debugging a kernel driver and seeing this in WinDbg, your exception handler might be returning the wrong value. Check your __except filter expression — it should return EXCEPTION_EXECUTE_HANDLER (1) not EXCEPTION_CONTINUE_SEARCH (0).

Real-world scenario: the one that got me

Back when I was maintaining a legacy COM component on Windows 10 21H2, I kept hitting 0X000002FE every time I stepped over a CoCreateInstance call. Drove me crazy for an hour. Turned out Visual Studio was breaking on a first-chance STATUS_INVALID_PARAMETER exception that COM itself handles internally. Unchecking "Break when this exception is thrown" for 0xC000000D (STATUS_INVALID_PARAMETER) stopped the noise.

Prevention tip: stop it before it starts

You can't prevent the OS from generating this status code — it's baked into the debugger protocol. But you can stop your debugger from showing it by default. Here's a one-time setup:

• Visual Studio: Go to Debug > Windows > Exception Settings, right-click any exception group, and select "Restore Default" after you've unchecked the exceptions you don't want to see. This keeps your custom filters across sessions.
• WinDbg: Save a custom workspace. Set sxi 0x000002fe once, then use .writemem ws to write the workspace. It'll apply every time you open that debuggee.
• General rule: If you're new to a codebase, start with all first-chance exceptions turned off in the debugger. Turn them on one at a time as you hunt specific bugs. Otherwise you'll drown in noise like 0X000002FE.

One last thing: if this error shows up in a release build outside a debugger — that's weird. It shouldn't happen. If it does, you might've shipped a debug build or left a kernel debugger attached. Double-check your build configuration (Release vs Debug) in the project properties.