STATUS_INVALID_DISPOSITION (0XC0000026) Fix for C++ Exception Handlers

You're running a Windows application — maybe a game, a simulation tool, or a custom-built C++ server — and boom. The process dies with 0XC0000026. You check the event log or your debugger and see STATUS_INVALID_DISPOSITION. This one tripped me up the first time I hit it back in my help desk days. I was debugging a physics engine and spent an hour thinking it was a memory leak. Nope.

What triggers this error?

This error fires when an exception handler — specifically one inside a __try / __except block — returns an invalid disposition code. In structured exception handling (SEH) on Windows, your handler must return one of three values:

• EXCEPTION_EXECUTE_HANDLER (1) — tells Windows to run the handler code and continue.
• EXCEPTION_CONTINUE_SEARCH (0) — passes the exception up the call stack.
• EXCEPTION_CONTINUE_EXECUTION (-1) — retries the faulting instruction.

If your handler returns anything else — say a random integer, or you forgot to return a value at all — Windows throws 0XC0000026.

I see this most often in code like this:

__try {
    // risky operation
    int* p = nullptr;
    *p = 42;
}
__except (someFunction()) {
    // handler
}

If someFunction() returns TRUE (which is 1) by accident, or returns an uninitialized variable, you get the error. Also common when the handler expression itself crashes — like dereferencing a null pointer while evaluating the disposition.

Root cause in plain English

Windows expects a strict contract from your exception filter: return exactly one of the three constants. When you return something else, Windows says "I don't know what you want me to do" and terminates the process. It's not a bug in Windows — it's your code breaking the rules.

The real culprit is almost always one of these:

• A filter expression that returns a non-standard integer.
• A function used as a filter that returns bool instead of int with the correct constant.
• The filter expression itself throws an exception, leaving Windows with no valid disposition.
• Stack corruption near the filter evaluation point — maybe a buffer overflow in a previous call.

Step-by-step fix

1. Find the failing exception handler. Open the crash dump in WinDbg or Visual Studio. Run !analyze -v in WinDbg. Look for the stack frame that contains the __except block. The call stack usually shows the function with the active handler.
2. Inspect the filter expression. Inside that function, look at the __except(...) line. That expression must return one of the three EXCEPTION_* constants. If it's a function call, check the function's return type — it should be int, not bool or DWORD. I've seen people write __except (TRUE) which returns 1 — that's EXCEPTION_EXECUTE_HANDLER, but if you meant EXCEPTION_CONTINUE_SEARCH, you're toast.
3. Verify all paths return a valid value. If the filter is a function, make sure every code path returns one of the three constants. Example of a broken filter:

int MyFilter(int code) {
    if (code == EXCEPTION_ACCESS_VIOLATION)
        return EXCEPTION_EXECUTE_HANDLER;
    // Missing return! Falls through.
}

Fixed version:

int MyFilter(int code) {
    if (code == EXCEPTION_ACCESS_VIOLATION)
        return EXCEPTION_EXECUTE_HANDLER;
    return EXCEPTION_CONTINUE_SEARCH;
}

4. Check for exceptions inside the filter. The filter expression runs in a special context. If it throws an exception itself (say, by accessing memory that's also corrupt), Windows can't evaluate the disposition. Wrap the filter logic in a try-catch or use __try/__except inside the filter, though that's rare. Simplest fix: make the filter a simple inline expression that can't fail.
5. Use /EHa compiler flag if mixing C++ exceptions and SEH. In Visual Studio, go to Project Properties > C/C++ > Code Generation > Enable C++ Exceptions. Set it to Yes with SEH Exceptions (/EHa). Without this flag, mixing try/catch and __try/__except can cause undefined behavior, including this error.
6. Rebuild and test. Recompile with all warnings enabled (/W4 at minimum). The compiler might warn about missing return values. Run your test case that triggered the crash.

What to check if it still fails

If the steps above don't fix it, look for deeper issues:

• Stack corruption. Use Application Verifier to enable page heap. If a buffer overflow corrupts the stack near the filter evaluation, the return value could get scrambled. Run appverif /enable TestApp.exe /flags 0x100 (heap checks) and reproduce the crash.
• Optimization bugs. Build with /Od (no optimization) and test. I once saw a release build with /O2 that inlined a filter function incorrectly, causing a wrong return. Turning off optimization confirmed it.
• Third-party DLLs. If the crash happens in a DLL you didn't write, check if it uses SEH with invalid filters. Tools like Dependency Walker or Process Monitor can identify the module involved.
• Nested exception handlers. If you have nested __try/__except blocks, the inner handler's disposition might be misinterpreted. Trace through the call stack and see which exact block is active.

I've fixed this error more times than I can count. It's almost always a simple return value mistake. Check that filter — you'll find it in five minutes.