EA AntiCheat installs and runs a kernel-mode driver (eaanticheat.sys). Kernel drivers operate at Ring 0, the highest privilege level in the OS. At this level there is no isolation between the driver and the Windows kernel, so any bug, invalid pointer, IRQL violation, or incorrect assumption about CPU/firmware behavior can crash the entire system, not just the game.

Microsoft explicitly documents this behavior:

“A bug in kernel-mode code can crash the entire system.”
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/

This is why failures in kernel drivers result in BSODs such as:

IRQL_NOT_LESS_OR_EQUAL
SYSTEM_SERVICE_EXCEPTION
KMODE_EXCEPTION_NOT_HANDLED

Microsoft’s bugcheck documentation confirms that kernel drivers are a primary cause of these crashes:
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-checks--blue-screens-

Kernel anti-cheats are inherently more invasive because they monitor:

Memory mappings / page tables
CPU control registers
Low-level process behavior
Anti-tamper vectors unreachable from user mode

EA AntiCheat’s own driver (eaanticheat.sys) is confirmed as kernel-level, similar to other solutions like Easy Anti-Cheat and BattlEye:

Easy Anti-Cheat (kernel driver model):
https://www.easy.ac/en-us/support/game/guides/anticheat/
BattlEye explanation of kernel access:
https://www.battleye.com/support/faq/

Because these drivers run at Ring 0, they cannot fail gracefully. If the driver makes even one incorrect assumption about memory layout, CPU features, or firmware behavior, Windows has no choice but to bugcheck.

This explains why:

The crashes take down the entire OS, not just BF6
Dump files consistently implicate eaanticheat.sys
Firmware/BIOS updates change system stability
The issue presents across different bugcheck codes

This is not a user configuration problem — it is a kernel driver stability issue. Kernel-level software must be held to a much higher standard of validation and testing, because the blast radius of a defect is the entire system.