Fix EXCEPTION (0XC000008C) Array Bounds Exceeded

This error is infuriating — especially when it only happens in production

Exception code 0xC000008C (STATUS_ARRAY_BOUNDS_EXCEEDED) means your program tried to access an array element at an index that's outside the allocated range. You're reading or writing memory that doesn't belong to that array. The result: a hard crash. I've seen this trigger most often when processing a file with unexpected data or iterating over a collection that changed size mid-loop.

The fix: add bounds checking before every access

Open your code. Find the array access that's causing the crash. If you're using raw arrays or std::vector, check the index against the size before using it. Here's the pattern I use everywhere:

// Before: risky
int arr[10];
arr[idx] = 42; // crash if idx >= 10

// After: safe
if (idx >= 0 && idx < 10) {
    arr[idx] = 42;
} else {
    // log or throw - don't silently skip
    throw std::out_of_range("Index " + std::to_string(idx) + " out of bounds");
}

For std::vector, use .at() instead of [] — it throws an exception you can catch:

try {
    vec.at(idx) = 42;
} catch (const std::out_of_range& e) {
    // handle gracefully
}

If you're stuck with an old codebase that uses [], wrap every access in a helper function that checks bounds. Painful, but it works.

Why this happens

0xC000008C is an SEH exception thrown by Windows when the CPU's bounds check flag is set — your compiler inserted a bound check and it failed. This usually happens because of one of three things:

• Off-by-one in loops: You wrote for (int i = 0; i <= size; i++) instead of i < size. That extra iteration hits one past the end.
• Corrupted index variable: Something else in your code overwrote the loop counter — common in threaded code or after a buffer overflow elsewhere.
• Data-driven size mismatch: You read a size value from a file or network packet, but the actual data doesn't match. Classic case: reading a BMP file where the header says 1000 pixels but the file is only 100 bytes.

The real fix is to never trust indices computed from external data without validating them first.

Less common variations

Sometimes the error shows up in unexpected places:

• STL containers in debug builds: MSVC's debug CRT adds extra bounds checking. Your release build might work fine, but debug crashes. Check for _ITERATOR_DEBUG_LEVEL or _SECURE_SCL settings. If you're passing iterators across DLL boundaries with different settings, you'll get this error.
• Managed/unmanaged interop: Passing a .NET array to a C++ DLL via P/Invoke — if the size doesn't match, the native code walks off the end. Use Marshal.SizeOf carefully here.
• Stack arrays in recursive functions: A deep recursion can blow the stack, and the topmost local array gets clobbered. The exception code might be 0xC000008C even though the real problem is stack overflow.
• SIMD or vectorized loops: Auto-vectorization can unroll loops and access elements beyond the last valid index if the loop count isn't a multiple of the vector width. Add a scalar remainder loop to handle tail elements.

I spent three days once chasing 0xC000008C in a 20-year-old MFC app. Turned out someone had redefined a macro that changed array indexing from 0-based to 1-based in a single header. Check your #defines.

How to prevent it going forward

Stop using raw arrays unless you absolutely must. std::array or std::vector are safer and give you .size() without guessing. If you're stuck with C, write a macro:

#define SAFE(arr, idx) ((idx) >= 0 && (idx) < sizeof(arr)/sizeof(arr[0]) ? (arr)[idx] : (abort(), (arr)[0]))

Enable compiler warnings — /W4 on MSVC, -Wall -Wextra on GCC/Clang. Turn on address sanitizers in debug builds (/fsanitize=address on Clang, /RTC1 on MSVC). They catch this exact error before your customers do.

And for the love of all that is holy, validate every index that comes from user input or file data. A simple if (idx >= max) check costs nothing. A crash costs everything.