Darktide Crash: Sub 10 minutes

System Specs

Linux Mint 22.3 - Cinnamon
Linux kernel: 6.17.0-35-Generic
CPU: Ryzen 7 3700x
GPU: AMD 7900XT

RAM: 32GB

I got gifted a copy of Darktide with this most recent sale on steam and for the life of me I cannot get the game running stably. The game launches just fine, I can navigate menues, get through the tutorial, mess around the hub, change settings, all fine. But when I try to play a mission i get less than 5 minutes in before the game crashes my entire desktop environment and I’m forced to restart my whole system.

I’ve tried Proton Hotfix, experimental, various specific versions and GE branches, I’ve tried the various launch commands and user_settings.ini changes from protondb with minimal difference in performance. Here is most recent log’n’dump from my escapades.

console-2026-07-01-04.29.28-aa085ce3-6454-44ca-a1b7-f8f6799b55ea.log (325.6 KB)

crash_dump-2026-07-01-04.29.28-aa085ce3-6454-44ca-a1b7-f8f6799b55ea.dmp (294.9 KB)

I’m really hoping to get the game working cause I’ve played hundreds of hours of vermintide 2 without problem, and have had this experience with Darktide being my first real, “Gaming on Linux Problems:tm:” moment.

Darktide is one of those games that just has tons of issues sadly. I suspect it might be more of an AMD issue than a Linux one. Saying that i just updated my NVIDIA drivers and now the game wont speak to my GPU (:

When the game crashes/locks everything, are you able to run ctrl + alt + f2 and enter a console?

asked Claude. Here the answer:

Based on this log, this is a deadlock crash, not a GPU driver crash or memory corruption issue.
Core error:
Deadlock detected while waiting on ‘renderer’ thread. Update was not called for 16.0 seconds.
The renderer thread got stuck for ~17.9 seconds inside RI::present_frame → present_windows → present — i.e. while submitting the finished frame to the display/swapchain. This in turn blocked the main thread for ~11 seconds waiting on that fence (RI::wait_for_fence in Window::update). So the game didn’t crash from a rendering bug or GPU fault — it hung waiting for the frame presentation call to return.
Why this points away from the GPU itself:
There’s no GPU reset, no AMDGPU driver fault, no VRAM/memory corruption anywhere in the log. VRAM usage and system memory both look fine at crash time. This is a stall on present(), not a rendering failure.
Probable causes (this log is running under Wine 10.0 with the RADV Mesa Vulkan driver on an RX 7900 XT, per “Wine version 10.0” / “RADV NAVI31 (LLVM 20.1.2)”):

Most likely: a compositor/present-mode interaction issue under Wine/Proton — the Vulkan/DXGI present call getting stuck waiting on the window manager or compositor (common with fullscreen/borderless handling, VSync, focus changes, or screen sleep interrupting the swapchain).
Could also relate to a specific Mesa RADV build regression with frame pacing/present under heavy stall conditions (note the many earlier “Stall Xms” warnings on both renderer and main threads throughout the session — the system was already under intermittent frame-time pressure before the full deadlock hit).
Less likely but possible: a window manager/desktop environment hiccup (e.g., compositor restart, external monitor/display config change) that dropped the present call entirely.

The other warnings in the log (missing item_type_localization_lookup entries for GEAR_HEAD/LOWERBODY/UPPERBODY/PORTRAIT_FRAME, and “Unit has still childs attached” on despawn) are cosmetic Fatshark-side bugs unrelated to the crash — safe to ignore.
TL;DR: Not a GPU crash — it’s a renderer thread deadlock on frame presentation, most consistent with a Wine/compositor present-call stall rather than anything on the AMD driver/hardware side.

So, not GPU related…