Proving a kernel crash lives inside a vendor's anti-cheat driver

1. Why this is on a business site

I build automation infrastructure with AI: n8n pipelines, agentic workflows, scraping engines, dashboards. Clients ask, reasonably, what "using AI properly" means when the problem is hard and the answer is not on the first page of Google.

This investigation is the clearest demonstration I have. Not because the AI was always right. It was wrong more than once, and twice in the same direction (it wanted the problem to be my hardware), and the evidence killed every one of those hypotheses. What made it work was the shape of the collaboration:

• I brought raw artifacts (minidumps, event logs, WinDbg output, BIOS screenshots) instead of descriptions.
• The AI parsed binary formats it had no tooling for, computed the memory math, and read the logs for facts I would have missed (a hypervisor start event proving a BIOS change had not taken; a specific launcher message that proves a whole line of troubleshooting was a dead end).
• I held the constraints the AI kept trying to talk itself out of: 140 games run fine, EAC titles run fine, nothing else on the machine crashes.
• Every hypothesis got one clean test, changing one variable, with the result read from a log rather than from a feeling.

That is the workflow I sell. The subject happens to be a game. The method transfers to every "vendor says it's your setup" problem a business has.

3. Background

3.1 The system

3.2 The game

The Crew Motorfest, Ubisoft's open-world racing game, purchased on 25 May 2026 on Steam and launched through Steam into Ubisoft Connect. It is protected by BattlEye, which installs and loads the kernel-mode driver BEDaisy.sys every time the game starts. The player cannot disable it.

One correction to the record up front: my 26 May messages to both vendors call the game "The Crew 2". That was my mistake on a long first day. The game was The Crew Motorfest from the beginning, which is what the Ubisoft case, the Discord thread and every message after 1 June say. The crash analysis is unaffected; the driver is the same, and the dumps do not care what the game is called.

3.3 The constraint that shaped everything

Over 140 other games run on this laptop at maximum settings without a fault. That includes titles substantially heavier on the CPU and GPU than either Crew game, and titles protected by Easy Anti-Cheat, which is also a kernel-mode anti-cheat driver. Nothing else on the system crashes. No application, no driver, no background service.

That single fact does most of the work in this case study. Any hypothesis of the form "your hardware is marginal" or "your Windows is broken" has to explain why the fault appears only when one specific vendor's kernel driver is loaded, and never otherwise. Neither vendor ever addressed it.

The picture inside the BattlEye set is not uniform either. Most other BattlEye-protected titles on this machine run normally. A few show a similar crash, but only after much longer sessions. The two Crew titles are the extreme case: every launch in May, every session since. That spread is itself informative. The common component is the driver; how often its faulting path gets hit appears to depend on the title.

4. The crash, in plain language

A blue screen with stop code 0xBE means a piece of code running in the Windows kernel tried to write to a memory page that is marked read-only. Windows halts immediately rather than let the write corrupt anything. Only kernel-mode code (drivers and the kernel itself) can produce this stop code. Ordinary programs, game launchers and overlays cannot, because they never run in the kernel; at worst they crash themselves.

When Windows can identify the driver, it prints the name on the crash screen. Here it printed BEDaisy.sys every time.

The two numbers Windows records with a 0xBE tell you what happened:

• Argument 1 is the address the driver tried to write to.
• Argument 2 is the page table entry (PTE) for that address. Its low bits are protection flags. A low byte of 0x21 means the page is present (bit 0 set) and not writable (bit 1 clear).

In every dump we opened, Argument 1 landed inside BEDaisy's own loaded image and Argument 2 said the page was read-only. In other words: BattlEye's driver was writing into itself, into a region Windows had mapped read-only, and Windows stopped it. The behavior is consistent with a self-check or anti-tamper routine inside the driver; the exact function is unknown because BattlEye does not publish symbols for it.

Reference: Microsoft's bug check 0xBE documentation (see Sources).

6. Investigation session 1: 26 May 2026 (Windows 11 24H2)

Starting point: every launch blue-screens at the BattlEye service start, before the first frame. The crash screen names BEDaisy.sys and stop code 0xBE. I uploaded the Windows System event logs and, in two batches, ten kernel minidumps from C:\Windows\Minidump\.

6.1 The tooling problem

Claude's sandbox had no WinDbg and no access to Microsoft's symbol server. So the minidumps were parsed by hand: reading the Windows triage-dump header directly (bug check code and the four parameters at fixed offsets), locating the loaded-module list and the string pool inside the dump, reconstructing the module map (base address, size, name length for each driver), and resolving each crash address against that map with a binary search. The event logs (.evtx) were parsed with the python-evtx library to pull Event 1001 (BugCheck) and Event 41 (Kernel-Power) records with timestamps and bug check parameters. Appendix E describes the method.

6.2 First hypothesis, and the first correction

The AI's first read was the textbook one for a 0xBE: a GPU driver or marginal RAM. It proposed DDU, a driver rollback, MemTest86, and checking for an overclock or XMP profile.

I pushed back with the constraint from section 3.3: far heavier games run at maximum settings, EAC-protected games run flawlessly, nothing else crashes. If RAM or VRAM were unstable under load, a heavier game would expose it more, not less.

The AI accepted the correction and dropped the hardware framing. What survived from its argument was one useful piece: varying stop codes still mean memory is being corrupted; the question is by what. The obvious candidate was already in every dump: a kernel driver that exists in memory only while this game runs. A web check confirmed the game requires BattlEye and that the player cannot turn it off.

6.3 A theory from the internet, dismissed on the evidence

A common forum claim is that the crash comes from running "64-bit Steam with 32-bit Uplay". It does not survive contact with the stop code. A 0xBE is a kernel fault; a disagreement between two user-mode launchers can crash the game or the launcher, never the kernel. Community fixes for the game's ordinary (user-mode) crashes were noted for completeness: unlinking extra accounts from the Ubisoft profile (more than three linked accounts, or an Amazon or Facebook link, is a documented crash trigger), and clearing the Ubisoft Connect cache. They address a different failure mode.

6.4 The first batch of dumps

Five minidumps (052626-21609-01, 052626-21671-01, 052626-21734-01, 052626-22406-01, 052626-23203-01): four 0xBE, one 0xA (IRQL_NOT_LESS_OR_EQUAL), each at a different absolute address. BEDaisy.sys was loaded at the moment of every crash. The dumps' string pools also named other third-party drivers as bystanders: logi_joy_vir_hid.x64.sys (Logitech), AppleLowerFilter.sys, AppleKmdfFilter.sys, netaapl64.sys (Apple device support), and others.

6.5 What I did that afternoon (none of it changed the outcome)

At one point the BattlEye Launcher showed Failed to start BattlEye Service (1053) instead of crashing. 1053 is the Service Control Manager's start timeout. The AI read the two symptoms as the same root cause with two faces: when the service manages to start, BEDaisy.sys loads and faults; when it cannot start in time, the launcher reports the timeout. Later, on the June system, the Application log also showed BEService.exe faulting in ntdll.dll with c0000409 (STATUS_STACK_BUFFER_OVERRUN, a fail-fast), a user-mode companion to the kernel-mode fault.

6.6 The second batch of dumps: the finding that closed the diagnosis

Five fresh minidumps from after all of the above, plus logs_4.evtx. The event log placed them at 14:37, 14:58, 15:05, 15:32 and 15:34: essentially every launch attempt that afternoon. Four were 0xBE, one was 0x50 (PAGE_FAULT_IN_NONPAGED_AREA), which is another known BEDaisy stop code.

Resolving the write-target address (Argument 1) against the module map in each dump gave the same answer every time: the address is inside a single 7.5 MB module (size 0x780000) at the same offset, +0x28a2ca. Example from 052626-15187-01.dmp: write target 0xfffff802634fa2ca, module base 0xfffff80263270000. The dump contains exactly one module of that size, it is the crash target, and its name is eleven characters long, which matches BEDaisy.sys exactly.

Two conclusions followed, and both held for the rest of the investigation:

• Deterministic, not random. Same driver, same internal offset, five crashes in a row. Random hardware corruption does not hit the identical address five times. This ended the hardware question for session 1.
• BattlEye writing to itself, not fighting another driver. The Logitech and Apple drivers appeared in the dumps as bystanders, not as the faulting party. The peripheral-driver chase, which the AI had pushed because those are the usual suspects, was a red herring. Uninstalling them ruled them out; it was never going to fix anything.

6.7 Independent confirmation from BattlEye's own launcher

While looking for BattlEye logs I found the launcher's language template file, the master list of every message the BattlEye Launcher can display. Three entries in it matter because I never saw them:

• DisallowedDriver=Disallowed driver: "%.*ls". Please unload it or reboot your system. This is the message BattlEye shows when it blocks a third-party driver. If Logitech, Apple or any other driver had been the problem, this is what would have appeared, not a blue screen.
• WindowsKernelMod=Windows Kernel modification detected. Please repair or reinstall your system. The message for a tampered kernel. Never shown.
• UpdateError=Update failed... The network failure message. Never shown; the update completes, and the crash comes at driver load.

Instead of any of these, the machine hard-crashed inside BEDaisy.sys. The driver died before the launcher could display a diagnostic. That is what a driver faulting on its own looks like, and it is the opposite of BattlEye rejecting something on the system.

6.8 Where session 1 ended

The diagnosis was written up as: a deterministic fault in the current BEDaisy.sys against Windows 11 24H2 build 26100. Two remaining paths were identified:

1. A Windows in-place repair (Settings, System, Recovery, "Fix problems using Windows Update"), non-destructive, roughly an hour. This is also BattlEye's own documented last-resort recommendation for this class of failure. I performed it. No change.
2. Escalation with evidence to both vendors. Both tickets went out the same day (section 11). Two blemishes in those 26 May messages, both mine: a leftover template placeholder ("[Add your CPU / GPU / RAM here.]") that I failed to fill in before sending, and the game misnamed as "The Crew 2". Both are visible in the evidence. The full hardware specification and the correct title were delivered in the 14 June report.

7. Between the sessions: 27 May to 12 June

Two things happened in this window that matter to the record.

The frontline loop. Two weeks in Ubisoft's Discord support with five different agents, working through the standard checklist. Every step was completed and reported. DxDiag and MSInfo were submitted more than once. Not one of the ten minidumps was requested or examined. On 1 June I asked for a remote session so someone could look at the machine directly; it was declined the same evening on policy grounds, with a request for updated DxDiag and MSInfo. On 9 June the thread was locked for inactivity and "missing" files.

The one change that changed anything. A Reddit thread suggested disabling Intel Rapid Storage Technology, which I did in BIOS. After that, the game launched for the first time. The fault did not go away; it moved. Instead of crashing at BattlEye startup, the machine now crashed on in-game transitions, at random intervals between about two minutes and about an hour. (The separate Intel VMD Controller setting stayed enabled through the June teardown, because the Windows install depends on it; see section 8.5.) Session 2 later noted that every perturbation in this period (the storage change, deleting the game config, disconnecting devices) bought a temporary reprieve and nothing more, which is itself a data point: the trigger is timing-dependent inside the driver, not tied to any one component.

The vendor replies in this window are in section 11. In short: BattlEye sent a form checklist on 2 June that repeated what had already been done, and did not respond to the 4 June reply.

In this window Windows moved from 24H2 (build 26100) to 25H2 (build 26200) through routine updates; the machine is kept current at all times. The crash was identical on both builds and has stayed identical through every cumulative update since.

8. Investigation session 2: 13 to 14 June 2026 (The Crew Motorfest, Windows 11 25H2)

Starting point: the full Discord transcript, fresh event logs from five separate boot sessions, a fresh minidump, and a machine that now launched the game and crashed inside it.

8.1 The second wrong hypothesis

This was a new chat, without the first session's context loaded. The AI's opening take, after reading the Discord thread, was correct about one thing and wrong about another.

Correct: nobody on the vendor side had analyzed the dumps, and the dumps were the actual evidence.

Wrong: it read the pattern (varying crash addresses, "works for an hour then dies", every random change helping briefly, crashes on transitions) as the signature of marginal hardware, specifically the well-documented Intel 13th/14th-gen Vmin-shift instability, and proposed that BattlEye was the canary rather than the cause. It backed this with a web search on i9-14900HX instability reports and microcode revisions.

The proposed test was a good one, and that is the point: instead of arguing, we ran it. Cap the maximum processor state to 99% (which disables Turbo Boost entirely), then reduce the CPU power limits, and see whether the crash changes. It did not. Combined with zero WHEA-Logger events across every session, the CPU theory was dead within the first hour of session 2. The AI later stated plainly, when I asked about a warranty claim, that the hardware evidence was weak precisely because the logs were clean and everything else ran.

8.2 The first WinDbg pass

I installed WinDbg and ran !analyze -v on the newest dump. The output (Appendix A) gave the missing detail the hand-parsed dumps could not: the faulting instruction.

• Bug check 0xBE. Argument 1 (write target) fffff80034e489ff. Argument 2 (PTE) 090000106eff8121.
• Faulting frame BEDaisy+0x343926, which resolves to fffff80034f93926, giving a BEDaisy image base of fffff80034c50000.
• The write target is therefore at offset 0x1F89FF (about 2.07 MB) inside BEDaisy's own image.
• The PTE's low byte is 0x21: present, not writable. The target page was mapped read-only at fault time.
• Fault chain: BEDaisy issues the write, nt!KiPageFault, nt!MmAccessFault, nt!MiSystemFault, nt!KeBugCheckEx.
• FAILURE_BUCKET_ID: AV_BEDaisy!unknown_function, FAILURE_ID_HASH: {36b04c21-521f-babb-382f-2a12c3ddef17}.
• Hypervisor.Flags.AnyHypervisorPresent: 1, IsHyperV: 1, VsmAvailable: 1.

Same diagnosis as session 1, now with the instruction pointer and the page protection proven rather than inferred.

8.3 The hypervisor theory, and the discovery that it had never been tested

The hypervisor flags pointed at a plausible mechanism: this laptop runs Docker and WSL2, which keep a Hyper-V hypervisor loaded. BattlEye's driver runs anti-VM and anti-tamper routines; a driver that detects a hypervisor and switches into a self-protection path that writes into its own image would produce exactly this fault. Memory Integrity had been off for two weeks with no change, but Memory Integrity and the hypervisor are different things, and the bare presence of the hypervisor had never been isolated.

First attempt: a second boot entry, "Windows 11 - Gaming (Hypervisor Off)", created with bcdedit and set to hypervisorlaunchtype off. Booted into it, played for two minutes, crashed.

Before treating that as a result, the AI insisted on verifying that the hypervisor had actually been off. It had not. The event log from that session showed lsaiso.exe running (Credential Guard's isolated process, which only exists when virtualization-based security is live) and a successful Microsoft-Windows-Hyper-V-Hypervisor start event at 21:04, in a session whose own boot configuration string read HYPERVISORLAUNCHTYPE=OFF. The explanation was in an earlier Core Isolation screenshot: "Local Security Authority protection: On". A UEFI-locked Credential Guard was force-launching the hypervisor regardless of the boot setting, and regardless of the BIOS virtualization switch.

So the hypervisor theory was not disproven; it had not been tested. Three separate attempts to remove the hypervisor had been silently undone.

8.4 The cheap tests first: E-cores and Hyper-Threading

Rather than fight the firmware lock immediately, the AI proposed the zero-risk test first. The i9-14900HX is a hybrid chip (8 performance cores, 16 efficiency "Atom" cores), and anti-cheat drivers choking on the P/E split is a real, vendor-acknowledged class of problem; it is why Lenovo ships a "Legacy Game Compatibility Mode" in this BIOS.

• BIOS, Active Atom Cores: Disabled. Reboot, play. Crash (0xBE), plus one 0x5C HAL_INITIALIZATION_FAILED on one boot with the cores disabled.
• Hyper-Threading: Disabled. Crash.

Both reverted afterward.

8.5 The full virtualization teardown

With the cheap tests negative, the only untested variable left was the hypervisor, which meant defeating the Credential Guard lock properly. Precaution first: the BitLocker recovery key retrieved and kept on a phone, since these changes can trigger a recovery prompt. Then, in order:

1. Windows Security, Device security, Core isolation: Local Security Authority protection set to Off.
2. Registry (admin Command Prompt), four values set to 0: DeviceGuard\EnableVirtualizationBasedSecurity, DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity\Enabled, DeviceGuard\Scenarios\CredentialGuard\Enabled, Lsa\LsaCfgFlags. Exact commands in Appendix B.
3. Windows features (admin PowerShell) disabled: Microsoft-Hyper-V-All, VirtualMachinePlatform, HypervisorPlatform, Microsoft-Windows-Subsystem-Linux.
4. bcdedit /set hypervisorlaunchtype off.
5. BIOS: Intel Virtualization Technology (VT-x) Disabled; VT-d Disabled.

One trap avoided along the way: the BIOS also exposes an "Intel VMD Controller" setting. It is not virtualization; it is the NVMe storage controller mode the Windows install was built on. Disabling it can make the boot drive disappear (INACCESSIBLE_BOOT_DEVICE). It stayed enabled.

Verification before launching anything: msinfo32 reported "Virtualization-based security: Not enabled". Task Manager showed no lsaiso.exe and no "Secure System" process. For the first time in the entire investigation, the machine was booted with no hypervisor present.

8.6 Session 5: the decisive result

The game crashed at 22:47 with an identical signature: 0xBE, BEDaisy.sys, write target fffff803a21f4cbb, zero WHEA events. With the hypervisor verifiably absent, the anti-VM mechanism was ruled out, and with it the last host-side variable anyone had proposed.

8.7 Per-session forensic evidence

Every crash across the five sessions is bug check 0xBE in BEDaisy, at a different absolute address each time, with zero WHEA-Logger events in any session.

A note on what "different address each time" does and does not mean. In session 1 (May) the module base was resolved inside every dump, which is why a fixed internal offset (+0x28a2ca) could be proven. In session 2 (June) only the newest dump was opened in WinDbg (giving offset 0x1F89FF and instruction +0x343926); the other sessions were compared by the raw Argument 1 values from the event logs, which move with the driver's load address (ASLR) on every boot. Those raw values cannot distinguish "same offset, different base" from "different offset". The honest statement is: the May dumps proved a fixed offset; the June dumps show the same fault class and have not all been resolved to offsets. That is listed as an open item in section 14.

8.8 Reverting

Everything was put back: BIOS virtualization, VT-d, Hyper-Threading and Atom cores re-enabled; the Windows features re-enabled; hypervisorlaunchtype auto; the four registry overrides deleted; LSA protection back on; the extra boot entry removed. Docker and WSL2 returned. Commands in Appendix B.

9. The crash signature, both sessions side by side

The two sessions measured different things (write-target offset in May; instruction and write-target offsets in June) and may have been looking at different BattlEye driver builds, since the driver updates itself at launch. What both sessions agree on, independently, with different tools, is the fault class: BEDaisy writes into a read-only page inside its own image and Windows halts the machine.

12. External corroboration and sources

12.1 The same instruction, on another machine, seventeen months earlier

A Microsoft Q&A thread opened on 12 January 2025 contains WinDbg output from a different user: desktop Intel Core i7-13700KF, RTX 4070 Ti, 32 GB DDR5, ASUS Prime Z790-P, Windows 10 build 19045, no overclock or undervolt, crashing about once a day while playing Rainbow Six Siege (a Ubisoft title protected by BattlEye).

Their dumps show:

My June 2026 dump: 0xBE, BEDaisy+0x343926, PTE 090000106eff8121, AV_BEDaisy!unknown_function, {36b04c21-521f-babb-382f-2a12c3ddef17}.

Same faulting instruction offset inside the driver. Same failure bucket and hash. Same PTE flag pattern (low bits 0x121: present, accessed, global, not writable) on the target page. Different CPU generation and form factor, different motherboard vendor, different operating system, different game. The one thing the two machines share is the BattlEye driver. The thread also carries a 0x50 variant from BEService.exe context, matching the 0x50 in my May dumps. Replies through May 2025 report the same problem with no fix, and Microsoft's community support answer on the thread states that BEDaisy is involved in every one of the crashes and that BattlEye is the likely cause.

A fair counter-argument, stated so it can be answered: that user also had an Intel 13th-gen K desktop CPU, the family named in Intel's instability advisory. Two responses. First, my CPU is a mobile HX part, outside the advisory. Second, and stronger, on my machine the crash was reproduced with Turbo Boost disabled, power limits reduced, E-cores off and Hyper-Threading off, with zero machine-check events and every hardware diagnostic passing. A silicon fault that produces the same instruction offset in a third-party driver, only in that driver, and ignores every clock and power reduction, is not what silicon faults look like.

12.2 Other public reports of the same fault class

• Microsoft Q&A, 3 June 2025: a different user, on their own Lenovo Legion 5i (three months old at the time), blue-screening after about 30 minutes of The Crew Motorfest, with BEDaisy.sys named in their dump. The advisor attributed the error to overclocking or a corrupt game and prescribed verify, reinstall, reinstall BattlEye; the user reported a temporary improvement and noted that earlier fixes had reverted within a week. Another owner, another Legion, a year earlier, same game, same driver. (This is not my machine; it is cited as an independent report.)
• In Ubisoft's Discord support channel, during the two weeks my thread was active, most of the threads about this crash came from gaming-laptop owners. I noted this to BattlEye on 4 June (E-06). Screenshots of those threads were not collected.
• Microsoft Q&A, March 2025: GTA V (BattlEye-protected online mode), BEDaisy.sys 0xBE; the user reports sfc, Windows updates, BattlEye reinstall, memory diagnostics and disabling Intel boost all failed.
• Microsoft Q&A, "Blue Screen Stop Code Bedaisy.sys and Attempted Write to Readonly Memory": a repeat report referencing the same issue months earlier.
• Tom's Hardware forum, December 2019: Escape from Tarkov, 0xBE in BEDaisy.sys. The signature is not new.

None of these threads ends in a documented fix from BattlEye.

12.3 Community reports: what worked for whom

The public threads on BEDaisy.sys crashes and on The Crew titles under BattlEye, collected on 27 August 2026, show one clear pattern and a lot of noise around it. Every 0xBE ATTEMPTED_WRITE_TO_READONLY_MEMORY report that names its CPU sits on an Intel 13th or 14th generation part, and the fixes that recur are all on the CPU side: a motherboard BIOS or microcode update, Turbo Boost off, one P-core ratio step down in Intel XTU, or a lower power profile. Software fixes (BattlEye reinstall, game reinstall, clean Windows install, memtest, sfc, DISM) almost never help with this stop code, though they do resolve a separate class of BattlEye problems (0x50 after a bad BattlEye push, launch refusals, crashes to desktop). The honest reading is that each CPU-side fix worked for some posters and explicitly failed for others, at least one only lasted months, and laptop owners repeatedly say the desktop knobs are not exposed in their firmware. Nothing in any thread mentions Intel RST, VMD or E-cores as a cause or a cure, and the one poster who toggled virtualization-based security saw no change.

Storage. No thread mentions Intel RST, VMD or any storage controller setting, for any stop code. On this machine, disabling RST in BIOS moved the crash from launch to in-game and changed nothing else, which matches the silence: nobody else found storage to be the lever either.

CPU and firmware. This is where the confirmed fixes cluster, and also where the contradictions are. BIOS or microcode updates fixed the r/techsupport 14700KF user, the Microsoft Q&A Z790 user and two posters in the War Thunder guide thread, but did nothing for two r/Rainbow6 commenters, the War Thunder 14900KF poster, or the r/The_Crew 13700KF poster whose BIOS was already current. Turbo Boost off fixed the r/Rainbow6 OP, the Steam R6 poster and the 2018 Tom's Hardware poster (who had a 99 C CPU), only partially helped the ARK poster, and failed for one r/Rainbow6 commenter. Dropping the P-core ratio by one step in XTU fixed the r/Rainbow6 OP and the PUBG OP but failed for a 14900K commenter; disabling one P-core bought another r/Rainbow6 commenter a few months; the 4.7 GHz frequency cap plus Hyper-Threading, DMB, RMF and SA GV off fixed the War Thunder 14900KF poster but caused a no-POST for a follower. Two posters gave up and swapped the CPU, one under warranty, one to a 7800X3D, while another commenter reports the same BSOD on a 7800X3D. On this Legion 9i, BIOS updates, E-cores off and every power-related knob Lenovo exposes changed nothing, and the two laptop posters in these threads (13980HX and 14900HX) say the same: the ratio and voltage controls the desktop fixes depend on are not present in laptop firmware. The i9-14900HX is also outside the scope of Intel's desktop K-SKU advisory, so the "degraded CPU" explanation cannot simply be carried over.

Virtualization and Windows. Windows 11 24H2 is blamed in two threads, but the evidence is thin: the War Thunder 24H2 thread is a match-kick problem fixed by a clean boot, not a BSOD, and in the PUBG thread the OP's crash was eventually fixed by an XTU ratio drop while a PUBG staffer and others ran 24H2 without crashes. The 23H2 rollback helped one PUBG commenter and did not help an r/Rainbow6 commenter. Clean Windows installs failed in at least six threads, including one poster who did six of them. Toggling Secure Boot, virtualization and TPM did nothing for the r/computer poster; the Kernel-mode Hardware-enforced Stack Protection setting only appears as a launch blocker for the 2023 Motorfest beta, not as a BSOD cause. On this machine, Memory Integrity off, VBS off, a verified hypervisor-free boot and the 24H2 to 25H2 move all left the fault untouched.

BattlEye, drivers and peripherals. Reinstalling or wiping BattlEye fixed the Destiny 2 poster and a Tarkov user in 2021, the GTA V Enhanced 0x139 commenter in 2025 and, by their own account, one War Thunder commenter using the permissions and Xbox uninstall-tool trick, but it failed for the PUBG OP, the r/techsupport OP, the 0x139 Microsoft Q&A poster and the Motorfest kernel-security thread. The 2019 Crew 2 thread is the cleanest vendor-side case: a pushed BEDaisy.sys build produced 0x50 on every BattlEye game and cleared two days later with no local change, which is the outcome I am waiting for here. On peripherals, the Fanatec reports in the Crew community are consistent over five years (BSOD the moment BattlEye starts with the wheel or V3 pedals attached), with one confirmed workaround: connect the wheelbase only after the car has loaded and route pedals through the wheelbase. The Focusrite article matters for BattlEye's 2 June 2026 reply to me: Focusrite's support article (created 28 April 2026, updated 24 June 2026) confirms that its MIDI driver could crash the BattlEye kernel module and points to driver 4.144.0 as the fix. The related reports describe 0x139 KERNEL_SECURITY_CHECK_FAILURE on startup, not 0xBE mid-game, and this machine has no Focusrite hardware or driver installed, so that part of the reply does not apply here. The remaining Motorfest threads are a different fault class entirely: the "Keeps crashing" thread is crash to desktop, where the profile-folder rename and the 8-core CPU affinity workaround each helped one poster and affinity failed for another; the "BattlEye fails updating" thread and the guru3D beta report are launch refusals; the December 2024 Legion thread is a freeze. None of those should be read as the kernel fault.

If you have this signature, add your WinDbg output to the Microsoft Q&A thread and your BattlEye ticket. See section 16.

12.4 Sources

13. Where the AI was wrong, and where the human was

This section exists because a case study about "proper AI usage" that contains no mistakes is not believable.

14. Alternatives considered, and open items

14.1 Considered and not taken

14.2 Open technical items

1. Open a new thread in Ubisoft's Discord support channel referencing the locked one and case 26109481, with a link to this page. It is the one step Ubisoft asked for that I have not taken. I do not expect it to reach engineering; a new thread restarts the frontline checklist. It goes in the record so that the record contains every step both vendors asked for, and whatever the new thread produces goes in the vendor log.
2. Run !analyze -v on every June minidump and compute the write-target offset against the module base in each, so the June data reaches the same resolution as the May data (section 8.7).
3. Record the BEDaisy.sys file version and hash at the time of each crash. The driver updates itself at launch; version tracking would show whether the fault survives driver updates as well as OS updates.
4. Capture a full kernel dump (not a minidump) on the next crash, so the trap frame contains all registers. Both vendor reports already offer this.
5. Re-test after each Windows cumulative update and after any visible BattlEye update, and log the result in the update log (Appendix F).

15. Where things stand, and what would resolve it

As of 27 August 2026: the game still crashes. The most recent launch test was on 30 July 2026, the day of the last message to Ubisoft, and it crashed the same way. BattlEye has not replied to the 4 June follow-up or the 14 June engineering report. Ubisoft closed the case on 24 June and has not replied to the 30 July message. The Discord thread is locked. The case portal says "In Progress".

What would resolve it, in order of likelihood:

1. BattlEye engineering opens one of the dumps. They have the failure hash, which their own tooling can match against their crash telemetry. If the January 2025 desktop dumps and my 2026 laptop dumps share a bucket in their system, that is a known issue with a two-year history. It is also not specific to the Crew integration: other BattlEye titles on this machine hit the same crash, at much lower frequency.
2. Ubisoft escalates the case to BattlEye instead of to the Discord frontline. The Ubisoft case number, the BattlEye ticket number and this page contain everything both parties need.
3. A BattlEye driver update that happens to change the code path. Detectable only by re-testing; see Appendix F.

I will update this page when any of the above happens.

Appendix A. WinDbg !analyze -v output (session 2, newest dump)

Verbatim from the analysis submitted to BattlEye on 14 June 2026 (E-07). Register dump and module list omitted.

ATTEMPTED_WRITE_TO_READONLY_MEMORY (be)
Arg1: fffff80034e489ff   Virtual address for the attempted write
Arg2: 090000106eff8121   PTE contents
Arg3: ffffa203274eee50   (reserved)
Arg4: 000000000000000b   (reserved)

FAILURE_BUCKET_ID: AV_BEDaisy!unknown_function
FAILURE_ID_HASH:   {36b04c21-521f-babb-382f-2a12c3ddef17}
MODULE_NAME:       BEDaisy
IMAGE_NAME:        BEDaisy.sys
PROCESS_NAME:      System

STACK_TEXT:
  nt!KeBugCheckEx
  nt!MiSystemFault+0x6b0
  nt!MmAccessFault+0x646
  nt!KiPageFault+0x38b
  BEDaisy+0x343926
  ...

Hypervisor.Flags.AnyHypervisorPresent : 1
Hypervisor.RootFlags.IsHyperV         : 1
Hypervisor.Flags.VsmAvailable         : 1
Hypervisor.Flags.HardwareMbecAvailable: 1

Derived values:

Faulting frame   BEDaisy+0x343926  =  fffff800`34f93926
Image base       fffff800`34f93926 - 0x343926  =  fffff800`34c50000
Write target     fffff800`34e489ff - fffff800`34c50000  =  0x1F89FF  (~2.07 MB into the image)
PTE low byte     0x21  =  0010 0001b  ->  bit 0 (present) = 1, bit 1 (writable) = 0

Other Argument 1 values observed across the June sessions (from Event 1001 records): ...4d439015, ...87c48db7, fffff803'a21f4cbb (session 5, hypervisor verified off).

Appendix B. Commands used

Everything below was run on the machine under test during session 2. Nothing here is a recommendation; it is the record. If you copy it, understand each line first, retrieve your BitLocker recovery key beforehand, and expect Docker and WSL2 to stop working until you revert.

B.1 Hypervisor-off boot entry (first attempt, later shown not to take effect because of the Credential Guard lock)

bcdedit /copy {current} /d "Windows 11 - Gaming (Hypervisor Off)"
bcdedit /set {GUID-returned-by-copy} hypervisorlaunchtype off
bcdedit /timeout 10

B.2 Full teardown (admin Command Prompt for reg and bcdedit, admin PowerShell for the features)

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 0 /f

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -NoRestart
Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Disable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -NoRestart
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -NoRestart

bcdedit /set hypervisorlaunchtype off

Plus, outside the terminal: Windows Security, Device security, Core isolation, Local Security Authority protection: Off. BIOS: Intel Virtualization Technology: Disabled; VT-d: Disabled. Intel VMD Controller: left Enabled.

Verification after reboot: msinfo32 shows "Virtualization-based security: Not enabled"; Task Manager, Details, shows no lsaiso.exe and no "Secure System".

B.3 Revert

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -NoRestart

(Microsoft-Hyper-V-All only if it was enabled before the teardown.)

bcdedit /set {current} hypervisorlaunchtype auto
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /f
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /f
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard" /v Enabled /f
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /f
bcdedit /delete {GUID-of-the-Gaming-entry}

BIOS: Intel Virtualization Technology, VT-d, Hyper-Threading and Active Atom Cores back to Enabled. Local Security Authority protection back to On.

B.4 Diagnostics used throughout

verifier /querysettings          (confirm Driver Verifier is off)
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
msinfo32                          (Virtualization-based security line)
eventvwr.msc                      (System log: Event 1001 BugCheck, Event 41 Kernel-Power, source WHEA-Logger)

Appendix D. Evidence index (screenshots)

Ten screenshots, E-01 to E-10, referenced throughout the timeline, the vendor log and the elimination log. Personal email addresses and the Discord handles of individual support agents are masked; case and ticket numbers are left intact so the vendors can look up the history.

Appendix E. Method note: parsing kernel minidumps without a debugger

In session 1 there was no WinDbg and no symbol server, so the ten minidumps were parsed by hand in a Python sandbox. The approach, for anyone who needs to reproduce it:

1. Header. A Windows 64-bit kernel minidump starts with the signature PAGEDU64. The bug check code is a 32-bit value at offset 0x38; the four bug check parameters are 64-bit values starting at 0x40. These five values alone classify the crash.
2. Triage dump block. A second header at offset 0x2000 holds offsets into the file for the loaded-driver list (offset and count), the string pool (offset and size) and the saved call stack (offset and size). The field positions were validated empirically against the data rather than taken from documentation: driver entries were checked for plausible kernel base addresses and sizes, and string-pool entries for valid UTF-16 driver file names.
3. Module map. Each driver entry yields a base address, image size and name length. Sorted by base, they form a map. Any kernel address can be resolved to "which module, at which offset" with a binary search.
4. Resolution. For a 0xBE, parameter 1 is the write target; for a 0x50, parameter 3 is the faulting instruction; for a 0xA, parameter 4 is the faulting instruction. Resolving those against the map is what produced "inside a 7.5 MB module at +0x28a2ca, every time". The module's name length (eleven characters) identified it as BEDaisy.sys even where the string pool did not resolve cleanly.
5. Call stack. The saved stack region was scanned for 64-bit values in the kernel address range and each was resolved against the map, giving the order of modules on the stack at the crash.
6. Event logs. python-evtx iterated every record; Event 1001 (BugCheck) and Event 41 (Kernel-Power) were extracted with their SystemTime and data fields, which gave the crash timestamps and, in session 2, the WHEA-Logger count (zero) and the Hyper-V and IsolatedUserMode start events that exposed the Credential Guard lock.

WinDbg in session 2 confirmed the hand-parsed conclusions and added the faulting instruction, the exact PTE and the failure bucket.

Appendix F. Update log