Floating-point overflow (0xC0000091) — real fixes that work

Cause #1: Old software built with x87 FPU (most common)

This is the one I see most often. Programs compiled 15+ years ago (think Windows XP era games, legacy scientific tools) used the old x87 floating-point unit. Modern processors handle floating-point differently — they default to SSE2 precision. The mismatch triggers 0xC0000091 when the program tries to push a value past what x87's 80-bit registers can represent.

The real fix here isn't patching the code (you probably don't have source). It's telling the program to use SSE2 floating-point handling. You'll need to set a compatibility flag.

Steps (Windows 10/11):

1. Right-click the program's .exe file.
2. Select Properties.
3. Go to the Compatibility tab.
4. Check Run this program in compatibility mode for.
5. Choose Windows XP (Service Pack 2) or Windows 95 — younger titles pick XP SP2, really old ones need 95.
6. Also check Disable fullscreen optimizations (this helps with 32-bit apps).
7. Click Apply then OK.
8. Run the program again. If it still crashes, try the next cause.

Why this works: Windows compatibility shims redirect FPU instructions to use the same precision the program expected. Without it, a calculation like 1.0 / 1e-308 overflows the stack because the default control word changed.

Cause #2: Code compiled with default floating-point control word

If you're a developer and this error shows up in your own app, the problem is usually the default floating-point control word. Visual Studio projects (especially old ones like VS 2008 through 2015) let the FPU mask overflow exceptions. But when you run on a modern CPU, the default control word from the CRT might leave exceptions unmasked.

Here's the specific fix: you need to call _controlfp_s() at the start of your program to mask the overflow exception.

Code fix (C/C++):

#include <float.h>
unsigned int current_word;
_controlfp_s(&current_word, _MCW_EM, _MCW_EM);
// Now floating-point overflows won't throw exceptions.
// They'll return infinity instead.

What this does: _MCW_EM masks all floating-point exceptions (overflow, divide-by-zero, invalid, etc.). After this, 1e300 * 1e300 gives inf instead of crashing with 0xC0000091.

If you're using managed code (.NET), wrap the problematic math in a checked block or use decimal instead of double. But honestly, the real root is usually unmanaged code — a DLL or a plugin written in C++.

Cause #3: Graphics driver or DirectX shader overflow

Less common but I've seen it. Some older DirectX 9 games and shader-heavy apps hit this when a pixel shader tries to compute something like pow(x, y) with huge values. The GPU driver catches it and throws the exception back to the CPU as 0xC0000091.

Fix steps:

1. Update your graphics driver to the latest stable version. Don't use beta drivers.
2. For NVIDIA: use Studio Driver instead of Game Ready — Studio Drivers have stricter FPU handling.
3. If the app is a game, go to its settings and lower Shader Quality to Medium or Low.
4. Disable Anti-aliasing and Anisotropic Filtering — these often amplify floating-point math in shaders.
5. If you're using DXVK or any translation layer (like running DirectX 9 via Vulkan), try turning it off. Those tools can change how the GPU handles precision.

I saw this exact scenario with Deus Ex: Human Revolution (2011) on a GTX 1070 with driver 441.20. Upgrading to 447.13 fixed it. You don't need the very latest, just a version that's mature for your GPU.

Quick-reference summary table

One last tip: don't waste time disabling DEP or running as admin — neither fixes this error. It's a math problem, not a permissions problem.