Guide Fortnite & Rust — EAC Update Nuking SVM Hypervisors (0xd1 BSOD)

[byte_corvus]

Lately, the EAC-EOS branch used in Fortnite and Rust has been hitting back hard against custom virtualization. If you are rolling your own SVM hypervisor — especially a Type 1 build — you might have noticed a hard crash during the "Waiting for game" sequence.

The behavior is consistent: the HV runs perfectly fine on Apex or Arc Raiders, but as soon as the EOS-specific EAC service initializes, it triggers a bugcheck. We are looking at a classic 0xd1 IRQL conflict that likely stems from how the anti-cheat is probing memory or handling specific intercepts under ring-1.

The Crash Logic

The dump shows a failure in EasyAntiCheat_EOS.sys. The driver is attempting to access a paged or invalid address while the system is at an IRQL that is way too high. Take a look at the analysis below:

Spoiler: WinDbg !analyze -v Log

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.

Arguments:
Arg1: fffffffff6542627, memory referenced
Arg2: 000000000000000e, IRQL
Arg3: 0000000000000001, value 1 = write operation
Arg4: fffff8058c3af9cf, address which referenced memory

PROCESS_NAME: System
IMAGE_NAME: EasyAntiCheat_EOS.sys
FAILURE_BUCKET_ID: AV_EasyAntiCheat_EOS!unknown_function
BUCKET_ID_FUNC_OFFSET: 26f9cf
IP_IN_PAGED_CODE: EasyAntiCheat_EOS+26f9cf
fffff805`8c3af9cf 0001 add byte ptr [rcx],al

Technical Breakdown

1. Target: EasyAntiCheat_EOS.sys (Version 3.2.0.0).
2. The Problem: The bugcheck occurs when the anti-cheat is likely performing integrity checks or timing measurements. Since the crash doesn't happen without the HV, it is highly probable that EAC is detecting an inconsistency in how the HV handles a specific MSR, CPUID leaf, or a nested page fault.
3. IRQL Conflict: The IRQL is at 0xE (14), which is extremely high for standard driver operations. This usually indicates the code is running inside a critical section or an interrupt handler when it hits the invalid memory address.
4. Emulation Issues: If you are not correctly emulating every single instruction that causes a VMEXIT, or if your timing checks (RDTSC/RDTSCP) are returning anomalous values, EAC might be intentionally triggering a path that leads to this crash as a form of detection-response.

Suggested Fixes & Direction

If you are going around in loops with this, check your intercepts. EAC has been known to use CR access and specific MSRs to verify if they are running in a guest environment.

1. Verify NPT (Nested Page Tables) configuration — ensure you aren't accidentally marking a region as paged that EAC expects to be resident.
2. Check your handling of the RCX register during the faulting instruction add byte ptr [rcx], al. If RCX is being corrupted during a VMEXIT/VMLOAD cycle, you will get this exact crash.
3. Debug your timing offsets. If the delta between instructions is too large due to VMEXIT overhead, EAC might be redirecting execution to a garbage address.

Anyone else digging into the latest EOS build specifically? Drop your crash logs or your current intercept setup below if you've found a bypass for this specific IRQL check.