FC26 ExitType 95 Crash: NVIDIA DPC Deadlock Triggered by EA Javelin

Summary

After extensive kernel-level tracing (xperf/WinDbg), the root cause of the FC26 ExitType 95 (267) crash on my system has been definitively identified.

EA Javelin Anti-Cheat's kernel-mode hooks trigger a spinlock deadlock inside the NVIDIA display driver (`nvlddmkm.sys`), causing a 5.7-second DPC hang that freezes the entire system. Javelin's heartbeat monitor then times out, producing the ExitType 95 crash.

This is NOT a hardware defect, driver bug in isolation, or system misconfiguration. The NVIDIA driver works perfectly in every other game tested (max DPC < 4ms). The deadlock only manifests when EA Javelin is actively hooking GPU-related kernel paths.

Causal Chain

FC26 launches → EA Javelin loads kernel hooks
↓
Javelin hooks intercept GPU syscalls (DX12 / kernel thunks)
↓
NVIDIA driver DPC fires on CPU 0 (nvlddmkm+0xe8fe0)
↓
DPC tries to acquire global spinlock nvDumpConfig+0x20a3d0
↓
Lock is held by another CPU — Javelin's GPU operations on CPU N
↓
DPC spins at DISPATCH_LEVEL (cannot be preempted)
↓
5.7 seconds later: lock released, DPC completes
↓
Javelin heartbeat timed out during freeze → ExitType 95 crash

Why Only EA Games?

The NVIDIA driver's internal spinlock (`nvDumpConfig+0x20a3d0`) is a standard GPU synchronization primitive. Under normal gaming workloads, cross-CPU lock contention at DISPATCH_LEVEL resolves in microseconds. However, EA Javelin's kernel hooks introduce additional GPU operations on other CPUs that change the lock acquisition/release timing, creating a window where the DPC on CPU 0 cannot acquire the lock and spins indefinitely.

No other game triggers this because no other game loads EA Javelin's kernel driver (`eaanticheat.sys`).

Evidence

xperf Kernel Trace — DPC Latency

| Metric | FC26 (Javelin active) | Other AAA Game (no Javelin) |

|--------|----------------------|---------------------------|

| nvlddmkm max DPC | **5,705,596 us (5.7s)** | 4,096 us (4ms) |

| System behavior | Full freeze → crash | Perfectly smooth |

WinDbg Disassembly — The Deadlock

nvlddmkm+0xe9082:

lock cmpxchg dword ptr [nvlddmkm!nvDumpConfig+0x20a3d0], esi

jne nvlddmkm+0xe9082 ; ← SPINS FOREVER at DISPATCH_LEVEL

A DPC cannot be preempted — it owns CPU 0 until it completes or voluntarily yields. With the lock held elsewhere and no preemption possible, CPU 0 is deadlocked.

xperf Sampled Profile — During the 5.7s Hang

While CPU 0 is deadlocked in the DPC, profile samples show:

- `eaanticheat.sys` actively running on CPU 3

- Normal game code (`FC26.exe`) running on other cores

- No nvlddmkm profile hits on CPU 0 — the spinloop is invisible to the profiler, confirming a tight `cmpxchg` spin rather than productive work

Previous Troubleshooting (All Ruled Out)

The following were investigated and conclusively excluded:

- Page file corruption

- GPU TDR (Event 4101) — zero events

- WHEA hardware errors — zero events

- NVMe storage errors — zero events

- fTPM stutter — timing does not correlate

- NVIDIA Overlay, HAGS, HD Audio, power management settings

- AMD iGPU, PCI phantom devices

- HVCI / Memory Integrity, Secure Boot

- EA Anticheat reinstallation

Request

This is a cross-vendor interaction bug between EA Javelin and the NVIDIA driver. I am reporting it to both parties. Specifically, I would ask the EA Anticheat team to:

Review the kernel hook paths that intercept GPU-related operations (DX12 submissions, kernel thunks, or WDDM callbacks) to identify which specific interception pattern triggers the NVIDIA DPC lock contention.
Consider adding a jitter or backoff mechanism to anticheat GPU operations, so they don't contend with the driver's internal DPC spinlocks.
Coordinate with NVIDIA — I am sending a parallel report to NVIDIA with the exact `nvlddmkm.sys` offsets and deadlock location. A joint investigation would be the fastest path to a fix.

I am happy to provide full ETL traces, system configuration details, or run additional diagnostic captures on request.