I can confirm that I am experiencing the exact same issue.
Only an issue for me after the newest DaD patch 2024/12/27 Patch:6.7#Hotfix 75. No issues before this patch on both Steam and Lutris
Launching Blacksmith launcher through Lutris (I have tried steam aswell with no difference).
I have tried disabling/enabling the following options:
Nothing seems to fix the issue. Seems to be related to fetching of teammate data (hp, buffs, class, name) as the performance comes back to normal GPU utilization when teammates leave the game, or playing solo the performance is amazing. Solo is still multiplayer which leads me to think that fetching the teammate data is the issue. It doesn't seem to be the UI elements, as hiding the UI via in-game keybinds has no effect on the performance issue.
Specs:
Custom Proton: GE-Proton9-21
Distro:Pop!_OS 22.04 LTS
Kernel:6.9.3-76060903-generic
RAM:32 GB
GPU Driver:NVIDIA 565.77
GPU:NVIDIA GeForce RTX 4070 Ti SUPER
CPU:Intel Core i5-14600KF
Newest update to Dark and Darker has made this issue even worse. Using Mangohud, I was able to see that CPU and GPU utilization fluctuates from 30% up to 60% usage, but it quickly drops back down.
Frame Latency has gotten worse when not even in an official game. Sitting in the lobby gives me from 60ms to 140+ms latency on my frames.
Starting to feel this is more of a Dev issue on the Dark and Darker side.
https://www.youtube.com/watch?v=QItek5OUewo
Here is a video showcasing the FPS loss in menu and solo play with Mangohud active.
I have the same issue on Pop!OS 22.04. I've also tried multiple proton versions and with/without MangoHud. I can also confirm that graphics settings have no effect on the issue.
Dark and Darker (2016590): launch deadlock
Issue transferred from https://github.com/ValveSoftware/Proton/issues/9967.
@dautry posted on 2026-07-12T18:55:51:
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:
__lll_lock_wait_private
__add_to_environ
putenv
NtCreateUserProcess
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.
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.
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}
journalctl -kgood-launch-excerpt.log
game-log-HUNG-2026.07.11-19.40.log
Summarized by Claude.Ai
@dautry can you try undoing your changes and checking with proton bleeding edge? https://github.com/ValveSoftware/Proton/wiki/Proton-Versions#proton-bleeding-edge it should be working more reliably without extra steps
@simifor bleeding edge worked like a charm
It would be great to know which exact version it was at that time since it’s constantly changing
experimental-bleeding-edge-11.0-396219-20260714-p51fec9-wffeb50-d5098f1-v3dfc6f
(build
timestamp 1783989866, Steam buildid 24192907)
Dark and Darker not working on newest patch
Issue transferred from https://github.com/ValveSoftware/Proton/issues/10063.
@cashiusjk posted on 2026-08-14T05:27:52:
Compatibility Report
Name of the game with compatibility issues: Dark and Darker
Steam AppID of the game: 2016590
System Information
GPU: NVIDIA GeForce RTX 3070 Ti
Video driver version: NVIDIA proprietary 595.84.0
Kernel version: 7.0.0-28-generic (Ubuntu 26)
Link to full system information report as Gist:
Proton version: GE-Proton11-5. Also reproduced on stock Proton Experimental, stock Proton 11.0-100 ("Proton Hotfix"), GE-Proton10-34, and GE-Proton11-1.
I confirm:
that I haven't found an existing compatibility report for this game.
#8208 exists for this AppID but describes a different, older failure mode ("Tavern is not working!" at character select). This report is a distinct failure in the anti-cheat service installer, occurring before the game process starts.
that I have checked whether there are updates for my system available.
Symptoms
The game's Ironshield anti-cheat bootstrapper (Tavern.exe) fails before the game process ever starts. In-game dialog:
An error has occurred. Code 9. Unable to update anti-cheat components. Please restart your PC and relaunch the game.
The Unreal Engine process (DungeonCrawler) never launches, so no game-side log is written.
The game worked under Proton for months prior to this. The failure began after Steam re-acquired the game's depot (recorded in config.vdf as "buildid":0 → "target_buildid":24707614, 2.28 GB of a 3.88 GB install), which forced the anti-cheat to update its components — and therefore to install and reconfigure its Windows service, TavernWorker. That service-configuration path is where it fails.
Root cause visible in the Proton log
The anti-cheat bootstrapper is launched as:
Command: ['.../steamapps/common/Dark and Darker/Tavern.exe',
'-server=http://live-gateway.lunatichigh.net',
'-steam=1', '-taverntype=steam', '-tavernapp=dad']
The following block repeats four times, after which the process gives up and reports code 9:
7099.456:0030:019c:fixme:service:svcctl_ChangeServiceConfigW Setting password not supported
7099.456:01a0:01a4:fixme:service:SetServiceObjectSecurity 0000000000299B80 5 000000000010BB90
7099.457:0030:019c:fixme:service:svcctl_ChangeServiceConfig2W SERVICE_CONFIG_FAILURE_ACTIONS not implemented: period 0 msg L"" cmd L""
7099.457:0030:019c:fixme:service:svcctl_ChangeServiceConfig2W SERVICE_CONFIG_SERVICE_SID_INFO not implemented: type 0
7099.457:01a0:01a4:err:ole:get_arm_offset_from_union_arm_selector no arm for 0x8 and no default case
7099.457:01a0:01a4:warn:seh:dispatch_exception backtrace: --- Exception 0x6c5.
Exception 0x6c5 is 1733 decimal — RPC_S_INVALID_TAG ("the union tag does not match the value of the discriminant"). The unwind trace following each exception is entirely inside rpcrt4.dll.
Also observed in the same window:
fixme:service:QueryServiceObjectSecurity information 5 not supported
fixme:service:QueryServiceConfig2W Level 6 not implemented
err:service:device_notify_proc failed to get event, error 1726
(1726 = RPC_S_CALL_FAILED.)
Exact root cause: SC_RPC_CONFIG_INFOW has no arm for SERVICE_CONFIG_TRIGGER_INFO
The union selector 0x8 in the error message is dwInfoLevel == 8, i.e. SERVICE_CONFIG_TRIGGER_INFO.
Wine's SC_RPC_CONFIG_INFOW union in include/wine/svcctl.idl defines arms for levels 1–7 only, and has no [default] arm:
c
typedef struct _SC_RPC_CONFIG_INFOW {
DWORD dwInfoLevel;
[switch_is(dwInfoLevel)] union {
[case(SERVICE_CONFIG_DESCRIPTION)] SERVICE_DESCRIPTIONW *descr;
[case(SERVICE_CONFIG_FAILURE_ACTIONS)] SERVICE_FAILURE_ACTIONSW *actions;
[case(SERVICE_CONFIG_DELAYED_AUTO_START_INFO)] SERVICE_DELAYED_AUTO_START_INFO *delayedstart;
[case(SERVICE_CONFIG_FAILURE_ACTIONS_FLAG)] SERVICE_FAILURE_ACTIONS_FLAG *actionsflag;
[case(SERVICE_CONFIG_SERVICE_SID_INFO)] SERVICE_SID_INFO *sid;
[case(SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO)] SERVICE_RPC_REQUIRED_PRIVILEGES_INFO *privinfo;
[case(SERVICE_CONFIG_PRESHUTDOWN_INFO)] SERVICE_PRESHUTDOWN_INFO *preshutdown;
};
} SC_RPC_CONFIG_INFOW;
SERVICE_CONFIG_TRIGGER_INFO (8), SERVICE_CONFIG_PREFERRED_NODE (9) and SERVICE_CONFIG_LAUNCH_PROTECTED (12) are all absent. Because there is no [default] arm either, the NDR marshaller raises RPC_S_INVALID_TAG as a structured exception rather than returning an error code — and the anti-cheat treats that as fatal.
Ironshield registers TavernWorker as a trigger-started service, so this call is not optional for it.
Suggested fixes, smallest first:
Add a [default] ; arm to SC_RPC_CONFIG_INFOW so unsupported levels return ERROR_INVALID_LEVEL instead of raising an exception. This alone may be enough to unblock callers that tolerate a failed trigger-config call.
Implement SERVICE_CONFIG_TRIGGER_INFO properly — add SERVICE_TRIGGER_INFO / SERVICE_TRIGGER / SERVICE_TRIGGER_SPECIFIC_DATA_ITEM to the IDL and handle level 8 in programs/services/.
Other unimplemented SCM functionality hit in the same sequence
SetServiceObjectSecurity / QueryServiceObjectSecurity with SECURITY_INFORMATION = 5 (OWNER | DACL)
ChangeServiceConfig2W / QueryServiceConfig2W level 6 — SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO
ChangeServiceConfig2W level 2 — SERVICE_CONFIG_FAILURE_ACTIONS
ChangeServiceConfig2W level 5 — SERVICE_CONFIG_SERVICE_SID_INFO
ChangeServiceConfigW with a service account password
Note that these are logged as fixme (non-fatal); only the level-8 union arm raises.
Note on kernel-mode
The game ships a kernel driver (tvk.sys, ~5 MB) alongside the Tavern components, but no attempt to load it appears anywhere in the log. The only ZwLoadDriver call is Wine's own winebth:
err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\winebth": c0000142
So this failure does not appear to require kernel-mode support — only the user-mode Service Control Manager paths listed above.
Reproduction
Install Dark and Darker (AppID 2016590) on Linux under Proton.
Put the anti-cheat in a state where it must update its components and (re)register its service — e.g. use a brand-new Proton prefix, or let Steam re-acquire the game depot.
Launch with empty launch options.
The launcher window appears briefly, then errors with "Code 9 — unable to update anti-cheat components." The game process never starts.
Reproduced on stock Proton Experimental and stock Proton 11.0-100 (Proton Hotfix), as well as GE-Proton11-5 (on a completely fresh prefix), GE-Proton10-34, and GE-Proton11-1. This is not GE-specific.
Ruled out
Filesystem / permissions — library is on ext4 (rw,nosuid,nodev,relatime); the anti-cheat successfully writes its component files (drive_c/ProgramData/Tavern/Tavern_1_1.bin, TavernCommon_1_1.bin) before failing.
Launch options — reproduced with the field completely empty; gamescope and gamemoderun wrappers removed.
protonfixes — confirmed running on GE-Proton11-5 (All checks successful); no protonfix exists for this AppID (No main stage global protonfix found for "Dark and Darker" (2016590)).
Stale prefix — reproduced on a freshly generated prefix.
Leftover anti-cheat processes — pgrep -fa -i tavern empty between attempts.
Duplicate Steam installs — no Flatpak Steam present.
Game install integrity — reproduced after Steam file verification and after a full reinstall.
ge-proton10-34x1 2026-08ge-proton11-1x1 2026-08ge-proton11-5x1 2026-08proton 11.0-100x1 2026-08proton experimentalx1 2026-08proton hotfixx1 2026-08ge-proton9-21x1 2025-01rpcrt4.dllx1 2026-08
Compatibility Report
System Information
I confirm:
steam-2016590.log.gz
Symptoms
When playing Solo, the game runs incredibly smooth. When playing in duos or trios the game is hovering around a solid 30-40 FPS. Editing in-game settings doesn't seem to affect the FPS at all. If your teammates die and leave the game, the FPS jumps back up to normal and smooth.
Reproduction
100%