Fix DBG_CONTROL_C (0X40010005) – Debugger Interrupted Your App

What Actually Happens When You See 0X40010005

You're running a console app – maybe a C++ service or a Python script launched from Visual Studio – and you press Ctrl+C to stop it. Instead of a clean exit, the debugger throws up that 0X40010005 error. It's not a crash. It's not a bug. It's the debugger saying, "Hey, I caught that interrupt signal. What do you want me to do with it?"

Had a client last month whose C# console app was throwing this every time they hit Ctrl+C during testing. They thought their code was broken. Nope. The debugger just paused execution at the signal handler. Hit Continue (F5) and the app exits normally.

I'll walk you through three fixes, starting with the 30-second solution that works 90% of the time.

Fix 1: The 30-Second Fix – Just Continue

This is the most common fix. When you see the 0X40010005 breakpoint pop up in Visual Studio or WinDbg, do this:

1. Press F5 (or click the Continue button) in the debugger toolbar.
2. The app will resume and finish its shutdown sequence normally.

That's it. The exception is a notification, not an error. Visual Studio treats DBG_CONTROL_C as a first-chance exception – it pauses to let you inspect the state. Continuing lets the OS handle the signal and terminate the process cleanly.

When this won't work: If your app has an infinite loop or hangs during shutdown, you'll see the breakpoint again. In that case, skip to Fix 3.

Fix 2: The 5-Minute Fix – Disable the Break on Ctrl+C

If you're tired of hitting F5 every time you test, tell the debugger to ignore this specific exception. Here's how in Visual Studio (2019 and 2022):

1. Go to Debug > Windows > Exception Settings (or press Ctrl+Alt+E).
2. In the search box, type 40010005.
3. You'll see Win32 Exceptions > 0x40010005 (DBG_CONTROL_C).
4. Uncheck the box next to it.

Now Visual Studio won't break when your app receives Ctrl+C. The app will just exit silently. For WinDbg users, run this command after starting the session:

sxd dbg: 0x40010005

This sets the exception to second-chance only (ignored on first occurrence).

Real-world example: A client was debugging a Windows service that handled shutdown signals. Every time they stopped the service via net stop, Visual Studio broke with 0X40010005. Unchecking that exception in Exception Settings saved them 30 seconds per test cycle.

Fix 3: The 15-Minute Fix – Handle Ctrl+C in Your Code

If you're seeing this because your app has custom shutdown logic (like saving state on Ctrl+C), you need to handle the signal properly. The debugger breaks because no handler is registered or the default handler returns TRUE (which tells Windows to keep running).

In C++ (Windows), add this to your main():

#include <windows.h>

BOOL WINAPI ConsoleCtrlHandler(DWORD dwCtrlType) {
    if (dwCtrlType == CTRL_C_EVENT || dwCtrlType == CTRL_BREAK_EVENT) {
        // Cleanup code here – close files, release resources
        return TRUE; // Signal handled, app will exit
    }
    return FALSE; // Let default handler take over
}

int main() {
    SetConsoleCtrlHandler(ConsoleCtrlHandler, TRUE);
    // Your app logic here
    return 0;
}

In C# (.NET Framework 4.5+), use the Console.CancelKeyPress event:

Console.CancelKeyPress += (sender, e) => {
    e.Cancel = true; // Set to false if you want the app to exit immediately
    Console.WriteLine("Cleanup running...");
    // Do cleanup
    Environment.Exit(0);
};

When you handle the signal properly, the debugger won't show 0X40010005 because your code tells Windows it's taken care of. If you're still seeing it after adding the handler, check that your handler doesn't throw an exception – that will trigger the debugger break.

One more thing: If you're debugging a 3rd-party DLL or a process you can't modify, stick with Fix 2. It's the cleanest workaround without touching someone else's code.

When You Should Actually Worry

If 0X40010005 appears without you pressing Ctrl+C, something else is sending a Ctrl+C signal to your process. Common culprits:

• Another process calling GenerateConsoleCtrlEvent
• A batch script or CI pipeline that kills processes by sending Ctrl+C
• Your own code accidentally calling GenerateConsoleCtrlEvent on itself

In that case, use Process Monitor (ProcMon) to trace who's sending the signal. Filter by your process name and look for CreateProcess events with CTRL_C_EVENT in the stack.

Otherwise, this error is harmless. Ignore it, disable it, or handle it – your call.