You're staring at a server log with RPC_S_FP_UNDERFLOW (0x000006EA) and the RPC server process just ate itself. Annoying, but fixable.
Here's the actual fix: your RPC server thread has floating-point exceptions unmasked, and a marshalled call produced a value small enough to underflow — typically a denormalized number turning into zero in an operation that Intel's FPU flags. The client sends the call, the server's MIDL-generated stub touches a float or double, the FPU raises an underflow trap, and because the exception isn't caught, RPC tears down the call and returns 0x6EA to the client.
The Immediate Fix
If you own the server binary, mask FP exceptions at thread startup. In C/C++ on Windows, that's a one-liner with _controlfp:
#include <float.h>
// Call once per thread, before any RPC dispatch
_controlfp(_MCW_EM, _MCW_EM);What that does: _MCW_EM is the exception mask, and setting it to itself with the mask argument clears every FP exception bit — invalid, denormal, divide-by-zero, overflow, underflow, precision. The thread no longer traps on underflow. It just quietly returns a zero or denormal.
If you can't recompile — say it's a vendor's COM+ component or a legacy EXE you inherited — you have two options. First, check whether the component has an interface method taking a struct with float or double fields and the client sends a very small value (below ~1.18e-38 for float). Patch the caller. Second, wrap the call in a try/except SEH block on the client side, but that only catches the symptom; the server still dies.
For 32-bit legacy apps running on Windows Server 2019 or 2022, make sure you didn't accidentally set the FPU control word in a worker thread and then hand dispatch to a thread pool that resets it. The exception mask is per-thread state in Windows, not per-process. A thread pool worker spawned after your _controlfp call has the default mask, which is exactly why this thing seems intermittent.
Why That Actually Works
The reason step 3 works is that RPC_S_FP_UNDERFLOW is not an RPC error in the usual sense — it's a hardware FPU exception surfacing through the RPC transport. The 0x6EA code is documented under winerror.h as RPC_S_FP_UNDERFLOW, but the underlying cause sits in the DCOM/RPC server's thread state. When the server stub marshals a float argument, the value gets pushed through an x87 or SSE register. If the FPU control word has the underflow exception unmasked, the FPU raises #U. RPC's structured exception handler sees an unhandled exception in the stub and converts it to the RPC_S_FP_* family.
Setting the mask stops the exception from firing at the FPU level. No trap, no SEH, no 0x6EA. The math still happens — you just get 0 or a denormal instead of a hard stop.
Intel and AMD differ here. On older AMD K6/K7 chips, underflow could trigger on operations Intel masks by default. If you're seeing 0x6EA on an AMD EPYC generation you migrated to, that's not a coincidence.
Less Common Variations
1. 64-bit server, 32-bit RPC client
The WoW64 layer maintains its own FPU control state. A 32-bit client calling a 64-bit RPC server through the interop marshaller can inherit a stale control word. The fix is to set the mask explicitly on both sides, or use RPCRT4!NdrServerCall2 breakpoints in WinDbg to confirm where the trap fires.
2. RPC over named pipes with custom marshalling
If you're hand-rolling marshalling instead of using MIDL, you can genuinely corrupt a double on the wire. A truncated 4-byte read into an 8-byte double gives you garbage, which after arithmetic can underflow. This one isn't an FPU mask issue — your wire format is wrong. Fix the marshalling, don't mask the symptom.
3. COM+ / MTS legacy components
Component Services on Windows Server 2012 R2 and 2016 sometimes shows 0x6EA in the event log with a COM+ catalog ID. Restart the COM+ System Application service, then re-register the component with regsvr32 /i. The FPU state gets set inside CoInitializeEx, and a bad catalog entry can skip it.
4. Intermittent on VM migrations
Moving a live RPC server VM between hosts with different CPU microarchitectures without proper CPU masking can flip denormal handling. Set --cpu host-passthrough in libvirt, or "Expose hardware assisted virtualization" with the same CPU model in vSphere. Denormals-as-zero (DAZ) and flush-to-zero (FTZ) bits differ across generations.
Preventing It
The durable fix is to mask FP exceptions at the entry point of every thread that will dispatch RPC calls. Not just server startup. Thread pools, task schedulers, IOCP workers — every single one. Put the _controlfp call in a thread-start hook or in a small wrapper that runs before the thread body.
Second, log the incoming float values on the client for the RPC method that's failing. Nine times out of ten you'll find a calculation upstream producing 1e-45 or similar. An underflow is often a sign that some earlier operation — a division, a squared distance, an exponential decay — went to zero faster than expected. Masking the exception stops the crash but the math is still wrong, and your physics engine or scoring algorithm will quietly give bad results.
Third, if this is a third-party binary you can't recompile, run it under Application Verifier with the Basics + Exceptions checks and reproduce. You'll get a stack trace pointing at the exact stub function. From there you can decide whether to shim the interface or replace the component.
And finally: don't confuse this with RPC_X_BAD_STUB_DATA (0x6F7). That one is a marshalling size mismatch. 0x6EA is narrower — it's specifically the FPU underflow path. Mixing them up will send you down the wrong rabbit hole for hours.