BF6 PC Crashes: 71+ Dumps & Recurring WinDbg Hashes — Engineering Review
Hello Battlefield / EA Team,
I am requesting escalation of this issue to the Battlefield/Frostbite PC engineering team.
This is not a report of a single recent crash. I have retained Battlefield 6 crash dumps going back to October 2025, giving me almost a year of longitudinal crash data from the same PC.
I currently have at least 71 known Battlefield 6 user-mode crash dumps through September 23, 2026. I batch-analyzed the original 68 dumps using Microsoft WinDbg/CDB and subsequently analyzed additional September crashes individually.
The important finding is that these crashes are not simply 71 unrelated events. They repeatedly cluster into a relatively small number of WinDbg/WER Failure.Hash families across multiple Battlefield 6 builds and, in some cases, multiple NVIDIA driver/image versions.
I have attached:
1. BF6_CrashDumps_Oct2025-Sep2026.zip — the original Battlefield 6 .mdmp files
2. Sajid_BF6_DxDiag.txt — current system DxDiag
I am providing the raw minidumps, rather than only my interpretation of them, because Battlefield/Frostbite engineering should be able to analyze them using private symbols that are unavailable publicly.
SYSTEM CONFIGURATION
CPU: Intel Core i9-13900K
GPU: MSI GeForce RTX 4090 Gaming Trio 24 GB
Motherboard: MSI MPG Z790 Edge Wi-Fi
RAM: 48 GB DDR5
Storage: 2 × WD Black SN850X 2 TB NVMe
Display: Samsung Odyssey OLED G9 — 5120×1440 / 240 Hz
OS: Windows 11
Network: Wired Ethernet
Current BF6 configuration includes Borderless display mode, Resizable BAR Auto, a 210 FPS limit and Frame Generation enabled.
Importantly, BF6 has crashed under multiple configurations over the history represented by these dumps. I am therefore not presenting any one current graphics setting as the cause.
LONGITUDINAL ANALYSIS — ORIGINAL 68 CRASH DUMPS
The original 68-dump WinDbg analysis produced the following faulting-module distribution:
KERNELBASE: 40
bf6.exe: 17
nvwgf2umx.dll: 7
No module resolved: 3
sl_dlss_g: 1
Primary problem classes in that dataset were:
XAML/HRESULT-labeled group: 30
INVALID_POINTER_READ: 19
E_OUTOFMEMORY: 9
INVALID_POINTER_WRITE: 5
SOFTWARE_NX_FAULT: 4
E_ABORT: 1
More importantly, several individual Failure.Hash values recur repeatedly.
FAILURE FAMILY #1 — 21 OCCURRENCES
Failure.Hash:
{823c07cc-a67a-e92f-3480-f4d74ce569af}
Failure:
0x887A0006 — DXGI_ERROR_DEVICE_HUNG
This was the largest single failure family in the original 68-dump dataset.
It occurred across multiple Battlefield 6 builds from November 2025 through September 2026, rather than being isolated to one game version.
FAILURE FAMILY #2 — 13 ORIGINAL OCCURRENCES + ADDITIONAL SEPTEMBER 2026 RECURRENCES
Failure.Hash:
{c6607993-a4db-3511-7d47-8a7ce6e5a44c}
Failure:
INVALID_POINTER_READ_c0000005_bf6.exe!Unknown
This is an especially persistent BF6.exe failure family.
It appears in my collection as far back as October 2025 and has continued to recur through September 2026.
In the original dataset alone it occurred across BF6 builds including:
1.0.386.51964
1.0.388.5459
1.0.424.48767
1.0.426.51287
1.0.437.12728
1.0.439.36273
It has subsequently occurred again on BF6 build:
1.0.443.60769
FAILURE FAMILY #3 — 9 OCCURRENCES
Failure.Hash:
{c862059a-e6ba-ca64-3b64-dacc95df22ca}
Failure:
E_OUTOFMEMORY_8007000e_bf6.exe!Unknown
These occurred between approximately October 2025 and April 2026.
FAILURE FAMILY #4 — 6 ORIGINAL OCCURRENCES + ADDITIONAL SEPTEMBER 2026 RECURRENCE
Failure.Hash:
{7b367f86-064a-2e05-5dc0-760739d560ad}
Failure:
INVALID_POINTER_READ_c0000005_nvwgf2umx.dll!Unknown
This is the recurring NVIDIA user-mode failure family.
Significantly, this same Failure.Hash has appeared with multiple NVIDIA user-mode image versions, including:
32.0.15.9597
and later:
32.0.16.1692
Therefore, the recurring family has not been confined to one NVIDIA driver/image revision.
OTHER RECURRING FAMILIES
5 occurrences
{3f9a4758-4ab6-6325-c9d4-7c3bd5c23a9f}
DXGI 0x887A0001
4 occurrences
{577a89c1-cd47-d3d4-2233-26f4a7549d0f}
DXGI 0x887A0005
3 occurrences
{2e3dbfa5-45db-9d81-cb14-a0e213654b79}
INVALID_POINTER_WRITE_c0000005_bf6.exe!Unknown
The latter BF6 invalid-pointer-write family occurred in October 2025, September 1, 2026 and September 19, 2026.
Smaller families also include SOFTWARE_NX_FAULT occurrences and an isolated sl_dlss_g invalid-pointer-write crash.
I do not consider the single sl_dlss_g occurrence sufficient evidence by itself to identify DLSS as the root cause.
THE CRASHES SPAN MANY BF6 BUILDS
The historical dump collection includes crashes from numerous Battlefield 6 executable versions, including:
1.0.386.51964
1.0.388.5459
1.0.394.13260
1.0.397.20249
1.0.400.9365
1.0.409.59773
1.0.420.18877
1.0.424.48767
1.0.426.51287
1.0.437.12728
1.0.439.36273
1.0.443.60769
This is one of the reasons I believe the dataset may be useful to engineering: several recognizable failure families appear to have persisted across Battlefield updates rather than being limited to a single BF6 executable.
RECENT SEPTEMBER 2026 EXAMPLES
September 16, 2026 — BF6 1.0.443.60769
Process runtime: approximately 46 minutes
Failure:
INVALID_POINTER_READ_c0000005_nvwgf2umx.dll!Unknown
Failure.Hash:
{7b367f86-064a-2e05-5dc0-760739d560ad}
NVIDIA image:
32.0.16.1692
The stack passed through nvwgf2umx, D3D12Core and Frostbite rendering components.
This was not a new hash; it was another occurrence of the established NVIDIA user-mode family already present in the historical collection.
September 19, 2026 — BF6 1.0.443.60769
Process runtime: approximately 20 minutes
Failure:
iNVALID_POINTER_WRITE_c0000005_bf6.exe!Unknown
Failure.Hash:
{2e3dbfa5-45db-9d81-cb14-a0e213654b79}
WinDbg showed BF6 attempting a write through a null base at approximately +0x18.
Again, this was an established failure family rather than a completely new crash signature.
Subsequent September 2026 crash — BF6 1.0.443.60769
Process runtime: approximately 59 minutes
Failure:
INVALID_POINTER_READ_c0000005_bf6.exe!Unknown
Failure.Hash:
{c6607993-a4db-3511-7d47-8a7ce6e5a44c}
This returned to the same long-running BF6 invalid-pointer family present in dumps dating back to 2025.
September 23, 2026 — approximately 13:50
BF6 build:
1.0.443.60769
Process runtime: approximately 46 minutes
Failure:
INVALID_POINTER_READ_c0000005_nvwgf2umx.dll!Unknown
Failure.Hash:
{7b367f86-064a-2e05-5dc0-760739d560ad}
WinDbg context showed:
RAX=0
followed by an access through approximately:
[RAX+180h]
resulting in an attempted read around address 0x180.
The stack again passed through NVIDIA user-mode, D3D12Core and Frostbite rendering components.
September 23, 2026 — approximately 14:01
Process runtime: approximately 5 minutes 40 seconds
Failure:
INVALID_POINTER_READ_c0000005_bf6.exe!Unknown
Failure.Hash:
{c6607993-a4db-3511-7d47-8a7ce6e5a44c}
This was another occurrence of the established BF6 invalid-pointer-read family.
September 23, 2026 — approximately 14:10
Process runtime: approximately 4 minutes 30 seconds
Failure:
INVALID_POINTER_READ_c0000005_bf6.exe!Unknown
Failure.Hash:
{c6607993-a4db-3511-7d47-8a7ce6e5a44c}
This occurrence contained a particularly clear null-object access.
WinDbg showed:
RAX=0
followed by:
call qword ptr [rax+10h]
with an attempted read at address:
0x10
This occurred only minutes after the previous crash and again returned to the same historical Failure.Hash.
IMPORTANT INTERPRETATION / LIMITATIONS
I am not claiming that matching Failure.Hash values prove that every crash has an identical root cause or source instruction
I understand that WinDbg/WER bucketing cn group crashes into a common failure family even when individual fault addresses differ.
Some BF6 stacks also resolve publicly to nearby symbols such as:
ffxFsr2ResourceIsNull
and:
isGlimpseEnabled
I am not claiming those public symbol names prove that FSR2 or those specific functions are responsible. Theyare simply the nearest public symbols available during analysis.
This limitation is one of the main reasons I am supplying the raw minidumps and requesting analysis against Battlefield/Frostbite private symbols.
There was also one separate Windows kernel BSOD in August 2026 involving:
0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL
and:
nvlddmkm.sys
I am treating that BSOD separately from the recurring Battlefield user-mode CTDs described above rather than assuming they share the same cause.
TROUBLESHOOTING ALREADY PERFORMED
Over the life of this problem I have performed extensive troubleshooting, including:
• Battlefield game repair/integrity checks
• EA App repair/reinstallation-related troubleshootin
• EA Javelin/AntiCheat repair/update
• Multiple NVIDIA driver revision
• Removal of NVIDIA Profile Inspector customizations
• Return to normal NVIDIA App/control setting
• Borderless display mode
• Resizable BAR configuration testin
• Frame-rate limit testing
• Frame Generation testng
• Network/NAT/UPnP investigation
• Wired Etherne
• Background-process/game-optimization investigation
• Removal of anolder custom game-mode utility that modified Windows services/settings
The current utlity used on the PC does not stop Windows services, modify DNS/network configuration, manipulate Game DVR registry settings, change game priority/power plans, or alter NVIDIA/EA/Javelin services
Network investigation also did not show NAT-session exhaustion or broadband receive errors/drops during testing.
Other demanding games, including Call of Duty/Warzone, have completed extended sessions on the same machin without reproducing these particular Battlefield failure families.
Battlefield 6 itself is intermittent. The same configuration can sometimes run successfully for hours and subsequently experience one of the established crash families.
For example, on September 23 there initially appeared to be a possible correlation with cross-platform party/communications activity. However, I subsequently restord Frame Generation, left the rest of the configuration unchanged, played again with the same friend, and did not crash.
I therefore do not consider either Frame Generation or cross-platform party/chat to be a demonstrated root cause based solely on timing.
WHAT I AM REQUESTING FROM BATTLEFIELD/FROSTBITE ENGINEERING
Please analyze the attached original .mdmp files using Battlefield/Frostbite's private symbols and internal information.
In particular, I would appreciate correlation of these recurring Failure.Hash families:
{823c07cc-a67a-e92f-3480-f4d74ce569af}
{c6607993-a4db-3511-7d47-8a7ce6e5a44c}
{7b367f86-064a-2e05-5dc0-760739d560ad}
{2e3dbfa5-45db-9d81-cb14-a0e213654b79}
I would specifically like to know whether internal analysis maps these families to known:
• Frostbite/DX12 resource-lifetime problems
• rendering/device-hung conditions• memory/resource-management problems
• NVIDIA user-mode/D3D12 interaction
• or another internal Battlefield coponent entirely
I am not asking EA Support to infr the cause from the public WinDbg symbols above. I am asking for the raw dumps to be passed to the engineering team that has access to the information necessary to resolve those addresses propery.
If engineering needs a particular diagnostic capture, telemetry collection, logging configuration, reproduction procedure or additional minidump, I am willing to collect it.
Given the duration of the dataset and the recurrence of the same failure families across numerous BF6 builds and driver revisions, I respectfully request engineering escalation rather than restarting generic PC troubleshooting from the beginning.
The complete raw crash-dump archive and current DxDiag are attached.
Thank you for taking the time to review this.
EA_Shepard EA_LunardustCat EA_Aljo
