Reproducible BF6 map-loading crash – Carrier Strike / Tsuru Reef / Hagental Base
TLDR: My game cannot launch Tsuru Reef, Carrier Strike or Hagental base since the TopGun Update. Straight crash when trying to load to the lobby with no messages.
Problem is isolated to these two maps only.
Reproducible BF6 map-loading crash – Carrier Strike / Tsuru Reef / Hagental Base
I have been investigating a highly reproducible BF6 crash affecting specific maps/modes since the August 2026 update, particularly Carrier Strike, Tsuru Reef and Hagental Base.
The crash initially appeared immediately after the update that introduced/changed Carrier Strike and Tsuru Reef content.
System
Primary affected PC:
- Ryzen 7 9800X3D
- RTX 5090 32 GB
- 96 GB RAM
- Windows 11 Pro for Workstations
- Windows build 26200
- DirectX 12 / WDDM 3.2
- HAGS enabled
- 4K 144 Hz display
- BF6 via Steam
A second completely different machine with an RTX 4070 Ti SUPER loads the same affected content normally.
Reproduction
The failure is highly deterministic.
Typical sequence:
- Matchmaking succeeds.
- BF6 begins loading Carrier Strike / Tsuru Reef or Hagental Base.
- Game crashes to desktop during loading.
- Other BF6 maps/modes continue to work normally.
Carrier Strike was how I first discovered the problem.
The same BF6 installation was copied to the RTX 4070 Ti SUPER machine and worked there, demonstrating that the original game data itself was usable.
I later performed a completely fresh, independently downloaded installation on the affected RTX 5090 machine. The same crash still occurred.
Troubleshooting already performed
The following have made no difference:
- Multiple complete BF6 downloads/reinstalls
- Steam file verification
- Manually deleting affected map files and allowing Steam to redownload them
- Completely fresh non-transferred installation
- Clearing BF6 local cache
- Clearing NVIDIA shader cache
- Clearing Windows DirectX shader cache
- Resetting BF6 settings/profile
- NVIDIA driver rollback from 610.xx to 591.86
- Later NVIDIA 616-series driver
- Low graphics preset
- DLSS disabled
- Frame Generation disabled
- Multi Frame Generation disabled
- Different frame-pacing settings
- FPS limiting
- HDR disabled
- Logitech G Hub completely uninstalled
- BF6 tested without the previous G Hub LED SDK loaded
- Async-compute-disable experiment
- Reboots between tests
None of these altered the dominant crash signature.
Crash dump findings
I have accumulated multiple BF6 minidumps across different BF6 builds and NVIDIA driver versions.
The important finding is that the crash is extremely deterministic.
August BF6 build
The repeated crash was:
Exception: 0xC0000005 ACCESS_VIOLATION Faulting module: bf6.exe Fault offset: bf6.exe + 0x5205665 Operation: READ Invalid address: 0x00000000000000A7 R8 = FFFFFFFFFFFFFFFF RDI = 0000000000000007
The relevant instruction sequence is effectively:
lea 0x8(%r8),%rdi ... mov 0xa0(%rdi),%r8d
At the time of the crash:
R8 = FFFFFFFFFFFFFFFF (-1) RDI = R8 + 8 = 7 BF6 then reads: [RDI + 0xA0] = [0xA7]
This produces the 0xC0000005 access violation.
The important point is that this exact state repeated across many independent crashes.
Driver rollback did not alter the failure
The same access violation occurred with substantially different NVIDIA drivers.
For example:
610.88 → bf6.exe + 0x5205665 → READ 0xA7
and:
591.86 → bf6.exe + 0x5205665 → READ 0xA7
The faulting instruction, register state and invalid address remained the same.
This makes a simple NVIDIA driver regression unlikely to be the primary cause of this crash.
Crash survived a later BF6 executable rebuild
After BF6 updated again, the executable changed.
The newer September dumps showed:
Exception: 0xC0000005 Faulting module: bf6.exe Fault offset: bf6.exe + 0x52064B5 Operation: READ Invalid address: 0xA7 R8 = FFFFFFFFFFFFFFFF RDI = 0000000000000007
The code moved from approximately:
+0x5205665
to:
+0x52064B5
but the surrounding machine instructions and actual failure mechanism remained effectively identical.
The new executable still receives the same -1 value, derives pointer 0x7, and attempts to read 0xA7.
This occurred even on a completely fresh BF6 installation.
Separate DXGI DEVICE_HUNG failure observed
One test produced a different BF6 crash:
DXGI_ERROR_DEVICE_HUNG 0x887A0006
BF6 reported:
Hang Detected in waitForFrameFences Timed out after 8000 ms Graphics stopped at: 142716 Compute stopped at: 142716
This came from Frostbite's DX12 SubmissionManagerDx12.cpp.
Most crashes, however, return to the deterministic 0xC0000005 / READ 0xA7 signature.
Comparison with second machine
The strongest practical comparison is:
RTX 5090 machine
- Carrier Strike / Tsuru Reef / Hagental Base crash reproducibly
- Multiple BF6 reinstalls
- Multiple NVIDIA driver versions
- same invalid-pointer crash
RTX 4070 Ti SUPER machine
- same transferred BF6 files
- affected maps load normally
This does not necessarily implicate RTX 50 hardware.
Similar BF6 ffxFsr2ResourceIsNull / invalid-resource crashes have previously been reported on RTX 20-, 30- and 40-series GPUs and AMD Radeon hardware.
It appears more likely that different GPU/platform configurations determine whether the faulty BF6 code path is reached.
Possible Frostbite / FSR2 resource-management relationship
Older BF6 crash reports have shown a very similar failure inside:
bf6!ffxFsr2ResourceIsNull
including cases where an invalid -1 resource state ultimately resulted in a read near address 0xA7.
Those reports have occurred even when FSR itself was disabled.
Without DICE's current symbols it is not possible to prove that the present bf6.exe + 0x52064B5 function is exactly the same named function.
However, the repeated pattern is highly suggestive of an invalid renderer/resource handle that BF6 fails to validate before dereferencing.
A simplified interpretation of the dump is:
map/scenario initialization ↓ resource lookup/registration fails ↓ invalid value / sentinel = -1 ↓ BF6 fails to validate it ↓ invalid derived pointer ↓ READ 0xA7 ↓ 0xC0000005
Why this appears to be a software defect
The following are difficult to reconcile with random hardware instability:
- identical faulting instruction across many crashes
- identical invalid address (0xA7)
- identical relevant register state
- same crash across several NVIDIA driver versions
- same crash after cache resets
- same crash on Low graphics
- same crash with HDR disabled
- same crash with G Hub removed
- same crash after map re-download
- same crash after complete fresh BF6 installation
- crash began after BF6 content/update changes
- later BF6 rebuild moved the code location but preserved the same failure mechanism
- similar BF6 resource-null crash families have been reported on multiple GPU vendors and generations
The affected RTX 5090 machine is otherwise stable in other workloads and BF6 maps.
Current conclusion
The evidence strongly suggests a BF6/Frostbite resource-management or scenario-initialization bug affecting specific map/mode combinations.
The GPU/platform appears to influence whether the bug is triggered, but there is currently little evidence that the RTX 5090 itself is defective.
The most useful information for DICE/EA would probably be internal symbols for the code around:
Current BF6 build: bf6.exe + 0x52064B5 Previous build: bf6.exe + 0x5205665
and specifically why the relevant lookup/resource value becomes:
FFFFFFFFFFFFFFFF
before BF6 dereferences the resulting near-null pointer.
I can provide the full .mdmp crash files if required.
