Since update 1.4.2.0 the game crashes to desktop during map load, but only on Wake Island and Top Gun: Carrier Strike. Every other map loads and plays normally.
The crash is a deterministic null pointer dereference inside bf6.exe, not a GPU driver fault. All 10 crashes produce the exact same exception address, faulting offset and accessed address, across different sessions, different graphics settings and a clean reboot.
CRASH SIGNATURE (identical in every dump)
Exception code: 0xC0000005 ACCESS_VIOLATION
Faulting module: bf6.exe+0x5205665
Faulting address: 0x0000000145205665
Access type: READ at 0x00000000000000A7
The accessed address 0xA7 is a null base pointer plus a 167-byte member offset. The code reads a field from an object that was never initialized. The value is constant across all dumps, which rules out memory corruption, since that would produce scattered addresses.
I verified three dumps spanning 67 minutes: 22:26:24, 22:40:42 and 23:33:56 local time (UTC-3). All three are identical in exception code, faulting offset and accessed address.
REPRODUCTION STEPS
1. Launch Battlefield 6 on PC (Steam), game update 1.4.2.0.
2. Queue into Wake Island or Top Gun: Carrier Strike.
3. During the map load, audio stutters for about a second and the game closes to desktop with no error dialog.
4. Load any other map. It loads and plays without issue.
Reproduced 10 out of 10 attempts on the two affected maps. Zero crashes on unaffected maps, including one continuous session of 7 minutes 49 seconds verified by process monitoring.
SYSTEM
GPU: NVIDIA GeForce RTX 5070
GPU driver: 610.88 (WDDM 32.0.16.1088)
CPU: AMD Ryzen 7 5800X
RAM: 32 GB
OS: Windows 11 Pro 25H2, build 26200
Game build: 1.4.2.0, bf6.exe version 1.0.443.60769, Steam buildid 24745559
Platform: Steam
Displays: 3
CRASH TIMELINE, 2026-08-18 (all times UTC-3)
The update wrote bf6.exe at 20:48:54. First crash at 22:26:20. The game had been stable for months before this update, with only 4 dumps total in the preceding two weeks.
22:26:20 / 22:27:29 / 22:28:58 / 22:30:24 / 22:40:38 / 22:43:24 / 22:52:16 / 22:55:17 / 23:11:09 / 23:33:51
The game writes two dumps per crash, so these are 10 distinct crashes.
TROUBLESHOOTING ALREADY PERFORMED (none of it changed the crash)
- Steam file integrity verification: passes, no files replaced.
- Full PC restart: the crash reproduces afterwards. The 23:11 and 23:33 crashes are post-reboot.
- Game shader cache cleared (Documents\Battlefield 6) and NVIDIA DXCache cleared.
- DLSS Frame Generation disabled.
- Upscaling technique changed.
- PCIe Link State Power Management set to Off.
- EA AntiCheat service and in-game launcher checked: both already on 1.0.14940698.0, no mismatch.
After each of these, the crash reproduces with a byte-identical signature.
WHAT I RULED OUT, WITH EVIDENCE
Not a GPU driver crash or TDR. No LiveKernelEvent was logged on the crash date. The most recent ones are from August 3, August 4 and August 13, unrelated to this session. No Display event ID 4101 in the System log at any point. The exception is also the wrong class: a driver hang would surface as DXGI_ERROR_DEVICE_HUNG (0x887A0006) or DEVICE_REMOVED, not a null dereference inside the game executable.
Not EA AntiCheat. eaanticheat.gameservice.exe crashed at 22:41:04, which is 20 seconds after bf6.exe faulted at 22:40:44. It is a consequence, not the cause.
Not memory instability. The exception address, faulting offset and accessed address are identical across all 10 crashes over 67 minutes. Unstable memory produces varying signatures. For completeness: this system runs two different DDR4 kits (2x A-DATA 3200, 2x Kingston KF3600C17D4/8GX), all four running at 3200. That has been the configuration for months of stable play and does not explain a map-selective, bit-identical crash that started 98 minutes after an update.
Not an incomplete install. Steam reports StateFlags 4, 12 installed depots, no disabled DLC, BytesToDownload equal to BytesDownloaded, and buildid matching TargetBuildID.
NOTE FOR THE TEAM
The offset +0x5205665 is constant across every crash, so the fault is reachable from a single code path. Given that it only triggers on the two scenarios added in 1.4.2.0, resolving the symbol at that offset against your internal PDBs should identify the uninitialized object directly.
Minidumps are available on request: 20 of them from Documents\Battlefield 6\CrashDumps, plus the WER record AppCrash_bf6.exe_3e1a5749ba96d9d01c1fc5413bce25ed87b28b_0a056a4f.