RPC_S_FP_DIV_ZERO (0X000006E9): Floating-point div zero fix

When this error shows up

You'll see RPC_S_FP_DIV_ZERO (0X000006E9) when a remote procedure call on a Windows Server (I've reproduced this on Server 2019 and 2022) tries to divide a floating-point number by zero. The RPC runtime catches the hardware exception and returns this status code to the client. Typical triggers: a client sends a NaN or Infinity value as a parameter (say, from a calculation that went wrong upstream), or the server's own internal math has a bug—like dividing by a field that's unexpectedly zero in a database record.

One specific case I've seen: a financial application sending price data where a quantity field was 0.0, and the server's average-price function did total / quantity without checking. Boom, error 0x6E9.

Root cause

What's actually happening here is the x87 or SSE floating-point unit on the CPU raises an exception (interrupt 0x4E on x64, or the #DE flag in SSE). By default, Windows translates that into an EXCEPTION_FLT_DIVIDE_BY_ZERO structured exception. The RPC server's runtime has a catch-all handler that maps unhandled exceptions to RPC error codes—and division by zero gets mapped to RPC_S_FP_DIV_ZERO. The RPC server process (typically svchost.exe hosting the RPCSS service, or a custom server) doesn't crash outright, but it returns this error to the caller.

The real fix depends on whose code is at fault. If it's a third-party server, you might be stuck patching around it. If it's your own code, you need to handle the edge case properly.

Fix it

Step 1: Identify the failing function

You need the RPC interface UUID and opnum (function number). Enable RPC debug logging:

wevtutil epl Microsoft-Windows-RPC/Debug C:\RPC_Debug.evtx

Or use etw tracing with xperf. Look for event ID 5 (RPC failure) with status 0x6E9. It'll show the UUID and opnum. Write those down.

Step 2: Check the client's input data

If you control the client, log the actual parameters sent to that function before the call. I've caught float.NaN or double.PositiveInfinity more than once. Sanitize them: convert NaN to 0.0 or skip the call entirely.

// C# example
if (float.IsNaN(price) || float.IsInfinity(price))
    price = 0.0f; // or throw with a clear message

Step 3: Fix the server-side code (if it's yours)

Add a division-by-zero guard before any floating-point division. On Windows, you can also mask the exception using _controlfp_s to avoid the error entirely—but that's a band-aid. Better to fix the logic:

// C++ example
if (quantity != 0.0)
    average = total / quantity;
else
    average = 0.0; // or return an error to the client

Step 4: For third-party servers—add an exception handler

If you can't modify the server, wrap the RPC call in a try/except on the client side (in C++) or a try/catch for SEH in C# using [HandleProcessCorruptedStateExceptions]. This lets you retry or log gracefully instead of crashing.

// C# with SEH handling
[HandleProcessCorruptedStateExceptions]
public void CallRpc()
{
    try
    {
        // your RPC call
    }
    catch (Exception ex) when (ex.HResult == unchecked((int)0x800706E9))
    {
        // handle gracefully
    }
}

Step 5: Check for corrupted floating-point state

Rare, but I've seen it: a buggy driver or another thread changes the FPU control word (e.g., sets the divide-by-zero mask bit to 0, which enables the exception). On x64, this is less common because SSE is used, but still possible. Use _control87 to verify the control word before the call:

unsigned int cw = _control87(0, 0);
if ((cw & _EM_ZERODIVIDE) == 0)
    _control87(_EM_ZERODIVIDE, _MCW_EM); // mask division by zero

If it still fails

• Check the RPC server version. Some older custom RPC servers have known bugs—update to the latest build.
• Enable full RPC failure logging using tracelog with the Microsoft-Windows-RPC provider. Look for exception codes beyond 0x6E9—you might have multiple issues.
• Test with a simple client that sends constant values (like 1.0 and 2.0). If that works, the problem is definitely in the data path, not the server logic.
• Run on a different server OS. I've seen rare cases where Server 2012 R2's RPC runtime handles this differently than Server 2022. A reboot or reinstall of the RPC service (via sfc /scannow) can also fix corrupted system files.

Bottom line: 0x6E9 is the RPC runtime shouting "you divided by zero." Listen to it—fix the data or the code. Don't just mask it unless you have no other choice.