This matches Ubisoft's ACBFR-525 (DX12 0x887A0006 on AMD) — 57 confirmations on their bug tracker, still "Need More Information".
Does this mean the same kind of stability issue exists on Windows?
Please post a Proton log, really getting tired of having to ask for one on every single bug report because everyone replaces their brain with an OpenAI subscription nowadays. The backtrace indicates a crash in game code so it's not immediately obvious where vkd3d-proton could be involved in the actual crash.
VKD3D_CONFIG=no_async,no_upload_hvv
no_async does not exist.
One actual thing you could try is VKD3D_CONFIG=defer_resource_destruction in case there's another use-after-free bug. zerovram shouldn't really change anything either, if it does then this kinda smells like some sort of race condition / sync bug in the game.
Thanks for the response. Answering your questions:
Does this happen on Windows too?
Yes — and it's actually worse there. After writing the original report, I completely wiped my Linux install and put Windows 11 on the same machine purely to see if it would help. With the latest AMD driver (32.0.31021.5001 / Adrenalin June 28 build), the game crashes to desktop identically, same pattern — sometimes even faster than on Linux. I then rolled back to Adrenalin 26.6.1 (as suggested by multiple commenters on Ubisoft's ACBFR-525 tracker) and that made it slightly more stable, but it still crashes after a while. The Ubisoft bug tracker now has 140+ confirmations and they marked it "Done" on July 22 saying "We have made some changes" — but people are still reporting the crash daily. So yes, this is absolutely not a Linux-specific or vkd3d-proton-specific issue. The game has a stability problem on AMD RDNA3 across both operating systems.
Proton log
I had about 350K lines across multiple sessions saved on the Linux install before I wiped it for Windows, so I can't attach the full file anymore. But the crash backtraces in the report above are exact copy-pastes from those logs. If you tell me what specific sections you'd want (post-initialization? last N seconds before crash? thread dumps?), I can launch Steam on the spare Linux SSD and reproduce a fresh log with PROTON_LOG=1 under controlled conditions. Just let me know what you need.
no_async doesn't exist
Good to know — been cargo-culting that from old forum posts. Thanks for clearing it up.
defer_resource_destruction
I'll test this ASAP on the fresh Linux session. The fact that zerovram changes both the crash address and the time-to-crash does make me suspect a use-after-free that gets perturbed by memory management timing. If defer_resource_destruction helps, that would confirm it.
One more data point
The Steam Deck (RDNA2 / Van Gogh) runs this game without any crashes according to Valve's verification and multiple user reports. The crash only manifests on RDNA3 (7900 XT here, confirmed on 7800 XT, 7900 XTX, and 9070 XT by other users). That narrows it down to something specific about the RDNA3 D3D12 descriptor handling that the game's engine trips over.
All I want is an ideally full log with PROTON_LOG=1. You should be able to zip it and just attach it here.
Steam Deck working doesn't mean much on its own, different settings compared to what people use on a higher-end desktop machine and there's a lot of games that have Deck-specific workarounds.
System:
OS: Bazzite
GPU: AMD Radeon RX 9070 XT
Mesa: Mesa 26.1.6
Proton: Experimental
Launch Option: PROTON_ENABLE_WAYLAND=1 DXVK_HDR=1 PROTON_LOG=1 %command%
I just got the game and have been experiencing the same frequent crashing here steam-3751950.zip is a zip of my proton log. I did not see anything interesting in it. If you would like any other logging data I would be happy to provide.
Edit this log seems better: steam-3751950.zip
PROTON_LOG=1x2 2026-08DXVK_HDR=1x1 2026-08PROTON_ENABLE_WAYLAND=1x1 2026-08PROTON_LOG=1`.x1 2026-07VKD3D_CONFIG=no_async,no_upload_hvvx2 2026-07VKD3D_CONFIG=defer_resource_destruction`x1 2026-07PROTON_LOGx1 2026-07PROTON_NO_NTSYNC=1x1 2026-07RADV_DEBUG=nohizx1 2026-07RADV_DEBUG=zerovramx1 2026-07RADV_DEBUG=zerovram):x1 2026-07RADV_DEBUG=zerovram,x1 2026-07PROTON_ENABLE_WAYLAND=1 DXVK_HDR=1 PROTON_LOG=1 %command%x1 2026-08gamemoderun PROTON_NO_NTSYNC=1 RADV_DEBUG=zerovram %command%x1 2026-07kernel32.dllx1 2026-07ntdll.dllx1 2026-070x887a0006x2 2026-070xc0000005x1 2026-07
System
OS: CachyOS (Arch-based), kernel 7.1.5-1-cachyos
GPU: AMD Radeon RX 7900 XT (Navi 31, RDNA3)
Mesa: 26.1.5-1 (RADV)
Proton: Experimental 11.0-20260713
CPU: Ryzen 7 7700X, 30GB RAM
Filesystem: EXT4
Symptoms
Game launches and plays normally, then crashes to desktop after variable time (7–31 minutes across sessions). No GPU hang, no amdgpu errors in dmesg — pure EXCEPTION_ACCESS_VIOLATION (0xc0000005) in the game process. Steam shows exit code -1 for all child processes. Crash is deterministic and reproducible on RDNA3. Same game runs stably on Steam Deck (RDNA2).
Launch options
gamemoderun PROTON_NO_NTSYNC=1 RADV_DEBUG=zerovram %command%Copia
(PROTON_NO_NTSYNC=1 is needed to work around the separate CEF/ntsync launcher deadlock from Proton#9958. RADV_DEBUG=zerovram increases session time from ~20 min to ~31 min but doesn't eliminate the crash.)
Crash backtraces (3 distinct crash points observed)
All crashes are EXCEPTION_ACCESS_VIOLATION in ACBlackFlag.exe with the same bottom-half call chain through kernel32.dll → ntdll.dll.
Crash 1 — READ violation at ACBlackFlag.exe + 0x4E29F4F (occurs without RADV_DEBUG=zerovram):
ACBlackFlag.exe + 0x4E29F4F ← info[0]=0 (READ), info[1]=0x0DDB0004
ACBlackFlag.exe + 0x42524D3
ACBlackFlag.exe + 0x003864D
ACBlackFlag.exe + 0x015B4AE
ACBlackFlag.exe + 0x015B1A9
ACBlackFlag.exe + 0x04B9C31
ACBlackFlag.exe + 0x04B573E
ACBlackFlag.exe + 0x48EC272
ACBlackFlag.exe + 0x751918A
ACBlackFlag.exe + 0x17B787C
ACBlackFlag.exe + 0x145A522
ACBlackFlag.exe + 0x52E3A0A
kernel32.dll + 0x00011649
ntdll.dll + 0x00010E0FCopia
Crash 2 — WRITE violation at ACBlackFlag.exe + 0x4CEFC88 (with RADV_DEBUG=nohiz or GE-Proton):
ACBlackFlag.exe + 0x4CEFC88 ← info[0]=1 (WRITE), info[1]=0x00000002
ACBlackFlag.exe + 0x001D8E8
ACBlackFlag.exe + 0x096E368
ACBlackFlag.exe + 0x015B4AE
ACBlackFlag.exe + 0xD939441
ACBlackFlag.exe + 0x46BDA5E
...Copia
Crash 3 — READ violation at ACBlackFlag.exe + 0xDC3CFE5 (with RADV_DEBUG=zerovram, latest build):
ACBlackFlag.exe + 0xDC3CFE5 ← info[0]=0 (READ), info[1]=0xFFFFFFFFFFFFFFFF (sentinel)
ACBlackFlag.exe + 0x4B1C780
ACBlackFlag.exe + 0x06D8B8B
ACBlackFlag.exe + 0x06D803F
ACBlackFlag.exe + 0xE0D9C3A
ACBlackFlag.exe + 0x08ADD1F
ACBlackFlag.exe + 0x4BE4987
ACBlackFlag.exe + 0x3CFFC32
ACBlackFlag.exe + 0x4EC3418
ACBlackFlag.exe + 0x4DB1FAD
ACBlackFlag.exe + 0x17B787C
ACBlackFlag.exe + 0x145A522
ACBlackFlag.exe + 0x52E3A0ACopia
What was tested (no improvement)
VKD3D_CONFIG=no_async,no_upload_hvv
RADV_DEBUG=nohiz
Proton GE 11-1
Ray tracing on/off via ACBlackFlag.ini
Frame Generation disabled
Shader cache cleared
Gamescope session (breaks Ubisoft Connect entirely)
Power limit at 280W
Notes
This matches Ubisoft's ACBFR-525 (DX12 0x887A0006 on AMD) — 57 confirmations on their bug tracker, still "Need More Information".
On Windows with AMD Adrenalin, rolling back from 26.6.4 to 26.6.1 resolves the crash — suggesting a GPU driver timing issue.
RADV_DEBUG=zerovram changes the crash point (different function, different violation type) and extends time-to-crash, but doesn't eliminate it. This suggests a VRAM management difference between RADV and the Windows AMD driver is widening a race window in the game's D3D12 descriptor/resource lifecycle.
Full PROTON_LOG available on request (~350K lines, multiple sessions).