FSR2 crashing game even if still disabled in settings
Game has been crashing on me, like 2 or 3 minutes after a game started, this is my rig:
Processor 13th Gen Intel(R) Core(TM) i5-13600KF (3.50 GHz)
Installed RAM 32.0 GB (31.8 GB usable)
Graphics card NVIDIA GeForce RTX 5060 Ti (16 GB)
Storage 1.73 TB of 2.73 TB used
System type 64-bit operating system, x64-based processor
Been running crash reports and all points to a FSR2 bug. Does anyone else has the same issue?
What caused the crash?
The crash is a null pointer write (0xC0000005):
ExceptionCode: c0000005 (Access violation)
Attempt to write to address 0000000000000000
AV.Type: Write
AV.Dereference: NullPtr
The faulting instruction:
bf6!ffxFsr2ResourceIsNull+0x2ff9fd5
movntps xmmword ptr [rdx],xmm0
At the time of the crash:
rdx = 0000000000000000
The game attempted:
movntps [rdx], xmm0
which effectively became:
movntps [0x0], xmm0
and immediately crashed.
Why this is important
The symbol name visible in the dump is:
bf6!ffxFsr2ResourceIsNull
and the stack is almost entirely inside that path:
bf6!ffxFsr2ResourceIsNull
bf6!ffxFsr2ResourceIsNull
bf6!ffxFsr2ResourceIsNull
...
That is extremely significant.
FSR2 (AMD FidelityFX Super Resolution 2) resources are being referenced during the crash.
The game is attempting to write to a resource pointer that is NULL.
In plain English:
Battlefield 6 tried to use an FSR2-related resource that didn't exist or had already been released.
Another major clue
Your dump shows:
APPLICATION_VERIFIER_LOADED: 1
This means Application Verifier was still enabled when the crash occurred.
The failure bucket confirms it:
FAILURE_BUCKET_ID:
INVALID_POINTER_WRITE_AVRF_c0000005_bf6.exe
Notice:
AVRF
That's Application Verifier.
Application Verifier intentionally catches invalid memory usage that might otherwise go unnoticed.
What this means for your earlier testing
You've already told me:
- FSR2 disabled
- DLSS enabled
- RTX 5060 Ti
- Driver 621.01
- Crashes still occurring
This dump suggests one of two things:
Scenario 1 (more likely)
Battlefield 6 still loads parts of the FSR2 code path internally even when DLSS is selected.
Many Frostbite builds do this because:
- DLSS
- FSR2
- XeSS
share parts of the same temporal upscaling framework.
So "DLSS enabled" does not necessarily mean FSR2 code is never loaded.
Scenario 2
Corrupted shader cache or configuration data is causing a stale FSR2 resource reference.
Typical symptoms:
- Crash during rendering
- Null GPU resource pointer
- Reproducible after graphics setting changes
What I would do next
1. Remove Application Verifier completely
Verify:
appverif.exe
or:
gflags /p
Battlefield 6 should not appear in either.
If present:
appverif /delete /for bf6.exe
or through the Application Verifier GUI.
Reboot afterward.
2. Delete the Battlefield 6 shader cache
Delete any shader cache folders for Battlefield 6.
Also clear:
%LOCALAPPDATA%\NVIDIA\DXCache
and
%LOCALAPPDATA%\NVIDIA\GLCache
then reboot.
3. Reset the BF6 graphics configuration
Remove or rename the BF6 settings folder so the game regenerates it.
This eliminates hidden FSR2-related settings left behind from previous configuration changes.
4. Disable all frame generation/upscaling temporarily
For one test session:
DLSS = Off
FSR = Off
XeSS = Off
Frame Generation = Off
Render at native resolution.
If stability returns, you've confirmed the issue is in the upscaling pipeline.
What the dump does NOT show
I do not see evidence of:
- NVIDIA driver crash
- nvlddmkm.sys failure
- RTX 5060 Ti hardware fault
- DirectX device removed error
- Overclock instability
- RAM corruption
The crash occurs before any of those indicators appear.
My conclusion
Based on this dump alone:
Battlefield 6 crashed because an FSR2-related rendering resource pointer was NULL and the engine attempted to write through it. The instruction was:
movntps [rdx], xmm0
with:
rdx = 0
The evidence is strengthened by:
bf6!ffxFsr2ResourceIsNull
appearing as the faulting symbol and throughout the stack trace.
The other thing that jumps out is that Application Verifier was still loaded, so I would make absolutely sure it has been completely removed before collecting the next crash dump. A post-Verifier dump will tell us whether this is a real engine bug or Application Verifier exposing a memory-management issue that normally stays hidden.
