Black Ops III: Game threads deadlocked in server_init_process_done on NVIDIA hybrid GPU laptop

System Information

• GPU: AMD Vega iGPU (card0, used by Hyprland compositor) + NVIDIA RTX 3050 Mobile (card1, game via prime-run)
• CPU: AMD Ryzen 7 5800H (16 threads)
• RAM: 58 GB
• Driver: NVIDIA 590.48.01, mesa/RADV 25.3.2
• Kernel: 6.18.2-zen2-1-zen
• OS: Arch Linux
• DE: Hyprland (Wayland), Xwayland 24.1.9
• Dual monitors: eDP-1 (1920x1080@120) + HDMI-A-1 (2560x1440@75)
• Proton versions tested: 9.0-4, 9.0 Beta, GE-Proton10-32, Experimental
• Steam AppID: 311210

Symptoms

After the Treyarch/Activision intro video plays successfully, the game shows a permanent black screen. DXVK HUD (DXVK_HUD=fps) confirms frames are being presented at 62fps — the rendering pipeline works, but the game renders empty/black frames. No audio output (despite audio threads running and mmdevapi render buffers being filled). No crash. Process consumes ~270% CPU indefinitely.

Root Cause Analysis

Using GDB attached to the running process, I identified that 5 game threads are permanently stuck in server_init_process_done → NtWaitForMultipleObjects → __fsync_wait_objects. These threads never execute game code — stack inspection confirms no game code return addresses (0x140xxxxxx range) on any of their stacks.

Stuck threads (all identical backtrace):

Backtrace (identical for all 5):

#0  syscall () from libc.so.6
#1  __fsync_wait_objects () from ntdll.so
#2  NtWaitForMultipleObjects () from ntdll.so
#3  __wine_syscall_dispatcher () from ntdll.so
#4  server_init_process_done () from ntdll.so
#5  wine64 entry

Working threads (not stuck):

Window, Input, dxvk-submit, dxvk-cs, dxvk-queue, Sound Decode, Sound Mix, Video Decode (×16), dxvk-shader-*, threaded-ml, Stream, StreamAsync — all function normally. The render pipeline works (swapchain created, frames presented via Vulkan), but there is no scene data to render because the gameplay threads (Database, Backend) that load assets are deadlocked.

strace profile of the game process:

81% futex (19k calls, 1.4k errors)
18% poll  (2.5k calls)
 1% write (17k calls)

Key Observations

1. Sync mechanism is irrelevant: Same deadlock with fsync, esync, and pure wineserver-side sync (PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 WINEESYNC=0 WINEFSYNC=0). The backtrace changes from __fsync_wait_objects to __esync_wait_objects to wait_select_reply respectively, but the threads remain stuck in NtWaitForMultipleObjects regardless.

2. Proton version is irrelevant: Identical behavior on Proton 9.0-4, 9.0 Beta, GE-Proton10-32, and Proton Experimental.

3. Steam overlay is irrelevant: Same deadlock with overlay fully removed (LD_PRELOAD="" WINEDLLOVERRIDES="gameoverlayrenderer64=d;gameoverlayrenderer=d"). Confirmed via /proc/pid/maps that overlay .so was not loaded.

4. Audio devices are irrelevant: Reduced from 9 ALSA devices (3 cards) to 1 card by unloading snd_aloop kernel module and unbinding HDMI audio via sysfs. No effect.

5. Display config is irrelevant: Tested Wine virtual desktop (1920x1080 via winecfg), single monitor (disabled HDMI-A-1 via hyprctl keyword monitor HDMI-A-1,disable), config.ini with FullScreenMode=2/Monitor=0. No effect on the thread deadlock.

6. Direct Wine launch behaves differently: When launching BlackOps3.exe directly through wine64 (bypassing Proton's steam.exe wrapper), the game briefly shows the Wine virtual desktop and a safe mode dialog with game console — it does NOT black screen. However it crashes shortly after because it needs the Steam runtime. This strongly suggests the steam.exe → BlackOps3.exe parent-child process launch path triggers the deadlock.

7. Proton's BO3-specific workaround: Proton has a special code path for AppID 311210 that uses wine (32-bit) + c:\Program Files (x86)\Steam\steam.exe instead of wine64 + c:\windows\system32\steam.exe. Patching this to use the normal path did not fix the issue.

8. Wineserver is healthy: strace on wineserver shows it actively processing ~12k writes/sec. It services other threads (Window, Input, Sound, DXVK) fine. It specifically never completes the init handshake for the 5 stuck threads.

9. vkcube/glxgears work fine: Both render correctly on the NVIDIA GPU via prime-run through Xwayland, confirming the GPU → compositor buffer handoff works. This is not a display/compositing issue.

What I Tried (35+ attempts)

• All common ProtonDB fixes (dsound=n,b override, audio device reduction, video folder removal/renaming, GE-Proton, config.ini creation, Media Foundation install via protontricks)
• PROTON_USE_WINED3D=0 and PROTON_USE_WINED3D=1 (WineD3D path showed GL_INVALID_OPERATION shader errors)
• VK_LOADER_DRIVERS_SELECT=nvidia_icd.json to hide AMD GPU from Vulkan
• Wine virtual desktop via winecfg GUI
• Disabling second monitor via Hyprland
• t7patch community security patch (loads successfully but no effect)
• BOIII community client (incompatible with latest game update)
• WINE_CPU_TOPOLOGY=4:0,1,2,3 to reduce thread spawn parallelism
• Patching Proton script to remove BO3-specific steam.exe workaround
• WINEDEBUG=+relay (game crashes under the logging overhead before reaching black screen)
• Targeted WINEDEBUG=+d3d,+mfplat,+mmdevapi,+module,+ntdll analysis
• dxvk.conf with dxgi.enableExclusiveFullscreen = False (read by DXVK but Exclusive FS: 1 persists)
• Repeated GDB backtrace sampling every 2-3 seconds over 60+ seconds — stack never changes
• Multiple Wine prefix deletions and fresh prefix creation

Reproduction

1. Install Call of Duty: Black Ops III on a system with AMD iGPU + NVIDIA dGPU (hybrid/Optimus laptop)
2. Hyprland (Wayland) compositing on iGPU, game offloaded to dGPU via prime-run
3. Launch with any Proton version
4. Intro video plays, then permanent black screen (DXVK HUD shows fps if enabled)
5. ps -T -p $(pgrep -f BlackOps3.exe) -o spid,%cpu,comm | sort -k2 -rn shows Database/2_Backend/BlackOps3.exe at 70-92% CPU
6. GDB: thread apply all bt 10 shows all busy threads stuck in server_init_process_done

Attached Files

• steam-311210.log — Proton log from a clean launch (Proton Experimental)
• gdb-thread-dump.txt — Full GDB backtrace of all ~80 threads
• thread-cpu.txt — Per-thread CPU usage snapshot