Proton version: 9.0-4, Experimental, Hotfix (reproduces on all three)
I confirm:
[x] that I haven't found an existing compatibility report for this game.
[x] that I have checked whether there are updates for my system available.
Symptoms
Hang on launch. Steam shows "Running", the window is a black screen that never
progresses, process must be killed.
Changing the Proton compatibility version typically produces one successful
launch, after which subsequent launches hang again. Across 8 logged launches, no
two successful launches ever occurred consecutively — every success was
immediately followed by a hang.
The game deadlocks while spawning the Sentry crash reporter subprocess crashpad_handler.exe. eu-stack on the hung process:
This is a putenv() call between fork() and exec() in a multithreaded
process. In dlls/ntdll/unix/process.c, spawn_process() double-forks and then
calls putenv() in the grandchild before exec_wineloader():
if (!(pid = fork())) /* child */
{
if (!(pid = fork())) /* grandchild */
{
...
if (winedebug) putenv( winedebug );
...
exec_wineloader( argv, socketfd, pe_info );
putenv() is not async-signal-safe. fork() clones only the calling thread, so
if any other thread in the game held glibc's environ lock at the moment of the
fork, the grandchild inherits it locked with no owner alive to release it. __add_to_environ then blocks on that lock forever and the grandchild never
reaches exec_wineloader().
crashpad_handler.exe therefore never starts, and Sentry's crashpad client blocks
waiting for the handler to come up — which is where the game log stops.
Whether another thread is inside getenv/setenv at the moment of the fork
depends on startup thread interleaving, so this is a race — but not a uniform one.
Startup timing appears to be state-dependent, which matches the observed pattern:
changing the compatibility version forces prefix/cache work on the next launch and
yields one success, and once that state is warm the fork lands in the bad window
consistently.
Reproduction
Launch the game. It hangs on most launches. Switching the compatibility version
generally allows one launch to succeed; the launches after that hang again.
On a hung launch, the game log stops at:
LogSentrySdk: Verbose: using minidump URL ...
A good launch continues to started crashpad client handler, then D3D12 init.
Every hang stopped at using minidump URL; every success passed started crashpad client handler.
Workaround
Renaming the crashpad binary so the subprocess is never spawned stops the hang on
all three Proton versions. No hang since applying it.
mv "steamapps/common/Dark and Darker/DungeonCrawler/Plugins/sentry-unreal/Binaries/Win64/crashpad_handler.exe"{,.disabled}
Ruled out
Proton version — reproduces on 9.0-4, Experimental, Hotfix
Compatibility Report
System Information
I confirm:
Symptoms
Hang on launch. Steam shows "Running", the window is a black screen that never
progresses, process must be killed.
Changing the Proton compatibility version typically produces one successful
launch, after which subsequent launches hang again. Across 8 logged launches, no
two successful launches ever occurred consecutively — every success was
immediately followed by a hang.
The game deadlocks while spawning the Sentry crash reporter subprocess
crashpad_handler.exe.eu-stackon the hung process:This is a
putenv()call betweenfork()andexec()in a multithreadedprocess. In
dlls/ntdll/unix/process.c,spawn_process()double-forks and thencalls
putenv()in the grandchild beforeexec_wineloader():putenv()is not async-signal-safe.fork()clones only the calling thread, soif any other thread in the game held glibc's environ lock at the moment of the
fork, the grandchild inherits it locked with no owner alive to release it.
__add_to_environthen blocks on that lock forever and the grandchild neverreaches
exec_wineloader().crashpad_handler.exetherefore never starts, and Sentry's crashpad client blockswaiting for the handler to come up — which is where the game log stops.
Whether another thread is inside
getenv/setenvat the moment of the forkdepends on startup thread interleaving, so this is a race — but not a uniform one.
Startup timing appears to be state-dependent, which matches the observed pattern:
changing the compatibility version forces prefix/cache work on the next launch and
yields one success, and once that state is warm the fork lands in the bad window
consistently.
Reproduction
Launch the game. It hangs on most launches. Switching the compatibility version
generally allows one launch to succeed; the launches after that hang again.
On a hung launch, the game log stops at:
A good launch continues to
started crashpad client handler, then D3D12 init.Every hang stopped at
using minidump URL; every success passedstarted crashpad client handler.Workaround
Renaming the crashpad binary so the subprocess is never spawned stops the hang on
all three Proton versions. No hang since applying it.
Ruled out
journalctl -ksysinfo.txt
good-launch-excerpt.log
game-log-HUNG-2026.07.11-19.40.log
Summarized by Claude.Ai