EasyAntiCheat_EOS Repeatedly Triggers BSOD 0x1a (MEMORY_MANAGEMENT)

I can independently reproduce what appears to be the same crash signature on completely different hardware.

My system:

ASUS ROG laptop

Intel 14th Gen Core i9

NVIDIA RTX 4080 Laptop GPU

32 GB RAM

Windows 11 25H2, OS Build 26200.8875

Game: Apex Legends

I have captured multiple independent BSODs.

My WinDbg results match this report extremely closely.

MEMORY_MANAGEMENT 0x1A

Arg1:

0x61941

Arg3:

0x9

Failure bucket:

0x1a_61941_PAGE_TABLE_RESERVED_BITS_SET_IMAGE_hardware_ram

Failure hash:

c6e5c6cf-692e-7852-5dc5-b74944540fc0

The kernel path in my dumps is also the same:

EasyAntiCheat_EOS

HalpPerfInterrupt / performance profiling interrupt

EtwpProfileInterrupt

EtwpTraceStackWalk

RtlWalkFrameChain

RtlpxLookupFunctionTable

KiPageFault

MmAccessFault

BugCheck 0x1A

Most importantly, the interrupted Easy Anti-Cheat execution points in two separate dumps are:

Crash 1:

EasyAntiCheat_EOS+0x28f278

Crash 2:

EasyAntiCheat_EOS+0x28f27b

The second offset exactly matches the +0x28f27b reported here, while the first differs by only three bytes.

I also performed an additional register and paging-hierarchy verification against my kernel MEMORY.DMP.

At the page-fault trap frame, the fault occurs at:

nt!RtlpxLookupFunctionTable+0x35f

The faulting instruction is:

mov rax, qword ptr [r10]

At that point:

r10 = FFFFF3F9FCFE7F80

The memory at r10 contains:

0000000000200063

The interrupted Easy Anti-Cheat execution address was:

EasyAntiCheat_EOS+0x28f278

Virtual address:

FFFFF8027CB2F278

Running the WinDbg command:

!pte FFFFF8027CB2F278

produces:

PXE at FFFFF3F9FCFE7F80

PPE at FFFFF3F9FCFF0048

PDE at FFFFF3F9FE009F28

PTE at FFFFF3FC013E5978

The PXE contains:

0000000000200063

Therefore, on my system:

r10 equals the PXE address associated with the interrupted EasyAntiCheat_EOS code address.

The value at r10 also equals the contents of that PXE.

This independently reproduces the core paging-hierarchy address relationship described in the original report.

One terminology clarification: in my dump, r10 points specifically to the PXE, or top-level paging-hierarchy entry, associated with the interrupted EAC code address rather than the final leaf PTE.

I also disassembled this EAC code region and confirmed that the two offsets seen in my separate crashes are adjacent instructions:

EasyAntiCheat_EOS+0x28f278:

mov eax, dword ptr [r14]

EasyAntiCheat_EOS+0x28f27b:

push rcx

This occurs across both launch-time and in-game crashes. At least one of my captured dumps occurred while Apex was already running rather than during the protected-game launcher stage.

Additional testing on my system:

MemTest86 completed with zero errors.

WHEA-Logger shows zero hardware-error events.

Other demanding games remain stable during extended sessions.

Other games using Easy Anti-Cheat can initialize EAC and run normally.

Apex and Easy Anti-Cheat have been reinstalled.

Intel and NVIDIA drivers have been updated.

The issue has reproduced independently of using Steam versus EA App.

This appears to be an independent reproduction of the same crash class on a different OEM laptop and different CPU/GPU configuration.

The additional paging-hierarchy analysis does not by itself prove which component originally corrupted the paging hierarchy. However, it shows that a second independent machine reproduces the same BugCheck signature, failure hash, performance/ETW stack, EAC code region, and direct relationship between the interrupted EAC address and the paging-hierarchy entry being accessed when the fault is detected.

Given the identical BugCheck parameters, identical failure hash, matching ETW/performance-interrupt stack, matching EasyAntiCheat_EOS instruction region, and the independently reproduced paging-hierarchy relationship, I would appreciate this being escalated to the Apex/EAC engineering team for investigation as a reproducible Easy Anti-Cheat / Windows kernel interaction rather than being treated as an isolated hardware-memory failure.

I have two original WinDbg analysis logs and an additional register/PXE verification log available. A kernel MEMORY.DMP is also available privately if engineering requires it.