Forum Discussion
Tell me more about how this is a OS/Driver/Hardware issue issue...fresh crash from this morning. The only good news is I wont have to worry much about this error much as it seems the game is dying already since most games start with bots now...
Alright, this is a good dump — it tells a pretty clear story. Let’s break it down cleanly and then I’ll tell you what actually caused the crash and what to do about it.
What actually crashed
Exception
Type: 0xC0000005 – Access Violation
Operation: Invalid pointer read
Address read: FFFFFFFFFFFFFFFF
Faulting instruction:
mov rax, qword ptr [rcx+20h]
Meaning:
The game tried to read a pointer that was already invalid / destroyed / never initialized.
This is a classic null-or-garbage pointer dereference, not a driver crash and not a hardware fault.
The smoking gun (this matters)
Look at the register state:
rcx = 0800000000000000
Then:
[rcx + 0x20] → FFFFFFFFFFFFFFFF
That’s not random memory — that’s a sentinel / poison value, meaning:
Object lifetime was violated
Resource was freed or never created
Game logic assumed it existed anyway
Where it happened (very important)
Even though symbols are stripped, the stack tells us exactly which system blew up:
FSR2 is directly involved
bf6!ffxFsr2ResourceIsNull
bf6!ffxFsr2ResourceIsNull
bf6!ffxFsr2ResourceIsNull
And this eventually flows into:
bf6!isGlimpseEnabled
Translation into English:
The FidelityFX Super Resolution 2 (FSR2) pipeline passed a null or invalid render resource into Frostbite’s rendering path, and Frostbite didn’t defensively check it before use.
That’s why the failure bucket is:
INVALID_POINTER_READ_bf6.exe
What this is NOT
Let’s clear this up explicitly:
Not a GPU driver crash
Not unstable RAM
Not CPU instability
Not overheating
Not Windows
If it were any of those, you’d see:
nvlddmkm.sys
dxgi.dll
d3d12.dll
TDR
Or kernel involvement
You have none of that.
Root Cause (confidence: high)
A BF6 Frostbite rendering bug involving FSR2 resource lifetime management, triggered during a render pass where a resource was missing, freed too early, or never initialized.
This matches exactly what you mentioned in earlier crashes:
Happens in DX11 and DX12
Happens more with FSR enabled
NVIDIA GPU (FSR is vendor-agnostic but less tested on NV)
Clean access violation in game code
Why it crashes sometimes
FSR2 is:
Async
Frame-history dependent
Extremely sensitive to resolution changes, alt-tab, menus, overlays, and dynamic scaling
All it takes is one frame where:
A history buffer is null
A resize happens mid-frame
A swapchain recreation races the FSR pass
→ boom, invalid pointer read.
Final summary (plain English)
BF6 crashed because its FSR2 upscaling system handed Frostbite a render resource that didn’t exist anymore. The engine trusted it, tried to read it, and instantly crashed. This is a game bug, not your system.
Jabroni31169 Linus Torvalds, creator of the Linux kernel, requires error-correcting code (ECC) memory in his PC.
He said not having ECC memory has caused him to chase his tail around in circles thinking he had code errors, but really it was a memory error.
That's the problem with memory errors. It's impossible to tell if you're experiencing a code error or a memory error.
- Jabroni311692 months agoNew Adventurer
Yea, I'm well aware of how ECC works but this isn't that for my case. Every other non-frostbite game works without issue along with every single other operation on this computer, even those that are memory intensive. Per the crash dump, frostbite is calling for something that doesn't exist, which causes the engine to crash.
The smoking gun (this matters)
Look at the register state:
rcx = 0800000000000000
Then:
[rcx + 0x20] → FFFFFFFFFFFFFFFF
That’s not random memory — that’s a sentinel / poison value, meaning:
Object lifetime was violated
Resource was freed or never created
Game logic assumed it existed anyway
- SIDEWINDR6662 months agoRising Adventurer
There may well be an issue with the Frostbite engine and GPU pipeline scheduling if you have it set to software scheduling. I get the DXGI errors as soon as I switch off hardware GPU scheduling, when I switch it back on there is no issue. Why would you want to switch off hardware GPU scheduling in the first place?
I however my system does not use FSR but DLSS instead so your crash dump is probably something different.