STEEL GULLET Demo (5164020)

[Lyko5]

Compatibility Report

Regression: works correctly on Proton 11.0 (proton-11.0-2c-x86_64), hangs on Proton
Experimental (experimental-11.0-20260917b-x86_64). Same machine, same game, same prefix,
same settings — only the compatibility tool changed.

• Name of the game with compatibility issues: STEEL GULLET Demo
• Steam AppID of the game: 5164020

System Information

• GPU: NVIDIA GeForce RTX 4070
• Video driver version: nvidia 615.71.09 (open kernel module)
• Kernel version: 7.2.7-200.fc44.x86_64 (Fedora 44, X11 / KDE Plasma)
• Link to full system information report as Gist: https://gist.github.com/Lyko5/e3e7de5c97abc974cb8ea9930131af34

• Proton version: Proton Experimental experimental-11.0-20260917b-x86_64 (wine-11.0) — BROKEN
  • Also tested: Proton 11.0 proton-11.0-2c-x86_64 — WORKS, no hang

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

Symptoms

Right-click-drag to pan the camera hard-locks the game, 100% of the time, within a minute of
starting the tutorial. The process stays alive — audio keeps playing — but the window renders
nothing and accepts no input. The desktop stays fully responsive; only the game is wedged.

wineserver enters an infinite loop in get_hardware_message and never returns, so the game's
main thread blocks forever in NtUserGetMessage waiting for a reply that never comes.

Mouse-wheel zoom works fine. Only the action that captures/clips the cursor triggers it.

Reproduces identically on kernel 7.2.6 and 7.2.7 (rebooted between, same result), so it is not
specific to a kernel or ntsync version.

Switching the compatibility tool to Proton 11.0 (proton-11.0-2c-x86_64) resolves it. The same
right-click-pan that hangs Experimental within ~60s plays normally. Soaked for 6.5 minutes of
continuous play including repeated camera panning with no hang, against a ~60-70s time-to-hang on
Experimental. Throughout, wineserver stayed idle in epoll_pwait2 at ~4% CPU (17s of CPU time
total) rather than spinning at 53-87% and climbing. Nothing else changed: same prefix, machine,
monitors, kernel and window mode.

Game main thread — blocked waiting on wineserver

#3 readv
#4 read
#5 read_reply_data
#6 server_call_unlocked
#7 wine_server_call
#8 peek_message
#9 NtUserGetMessage
#10 __wine_syscall_dispatcher

All 46 other threads in the process are parked in futex_do_wait / ntsync_schedule. Nothing is
deadlocked inside the game itself.

wineserver — spinning, single-threaded, burning a core

State: R (running) %CPU: 53% -> 87%, climbing steadily across samples

#0 get_hardware_message <-- never returns
#1 req_get_message
#2 call_req_handler
#3 thread_poll_event
#4 main_loop_epoll
#5 main_loop

wineserver is not blocked — it is looping, and never sends the reply.

Monitor layout ruled out

Originally suspected a multi-monitor cause (three displays, two rotated portrait, primary inset
240px, leaving uncovered regions in the virtual screen). Tested and disproved. With the two
side monitors disabled and a single 2560x1440+0+0 display active — no rotation, no offset, no
uncovered regions — the hang still reproduced every time.

This reproduces on a completely ordinary single-monitor setup.

Possibly related prior art in the same area of the server, offered only as context: wine-devel
patch "server: Improve handling of cursor position clipping for empty rectangle", and
ValveSoftware/wine#24 (fullscreen clips the mouse to the wrong monitor).

A second hang mode, possibly the same bug

Roughly one launch in four hangs during startup instead, before the main menu renders (the
game's own log stops right after Vulkan init at 836 bytes, versus 5,984 for a healthy run). In that
case the main thread is stuck slightly deeper in the same path:

NtUserPeekMessage -> peek_message -> window_from_point -> send_message
-> send_message_timeout -> process_message -> call_window_proc
-> NtUserGetProp -> wine_server_call -> read_reply_data [BLOCKED]

Same subsystem (mouse hit-test inside the message pump), same wineserver round-trip that never
returns. Not proven to be the same root cause, but noted in case it helps.

Ruled out

• Not a GPU or driver fault. No Xid, no GPU reset, no coredump. Kernel journal is completely
  empty across every freeze window and the Xorg log is untouched. GPU sits at 53C / 27% while frozen.
• Not a crash. Process alive and healthy; only the render/input path stalls.
• Not shader compilation stutter. These are permanent hangs, not hitches.
• Not the Steam overlay. Disabling the in-game overlay for this title does not help.
• Not the D3D translation layers. The game renders in native Vulkan 1.4.351 (Godot 4
  Forward+) — DXVK and vkd3d are never loaded.

Reproduction

1. Launch STEEL GULLET Demo (AppID 5164020) under Proton Experimental, windowed.
   Single 2560x1440 display is sufficient — no multi-monitor setup required.
2. Enter the tutorial.
3. Hold right mouse button and drag to pan the camera.
4. Permanent freeze. Audio continues, desktop stays responsive, only the game is wedged.

Mouse-wheel zoom beforehand does not trigger it. Reproducible on demand in under a minute.

The game is a free demo, so this can be reproduced at no cost by anyone with a Steam account.

Engine: Godot 4.8.dev6.mono, Vulkan 1.4.351 Forward+. ntsync is in use (/dev/ntsync present).

Scope of testing: hang reproduced many times on experimental-11.0-20260917b (both freeze
modes). Not reproducible on proton-11.0-2c. Proton Hotfix (hotfix-20260828-ptr) is installed
but untested — happy to test it, or any intermediate Experimental build, to narrow the regression
window.

Stacks captured live with eu-stack against the frozen process while still wedged
(ptrace_scope=0). Happy to provide full thread dumps, repeated wineserver samples, or test patches.

[Blisto91]

@Lyko5 Hi there. Please attach a Proton log.
Running with PROTON_LOG=1 %command% added to the game's launch options should make a file called steam-5164020.log appear in your users home folder. The log compresses well if needed.

[Lyko5]

Sorry @Blisto91 , I tried to upload the un zipped on and it probably failed. Here ya go:

steam-5164020.log.gz

[simifor]

I don't know why ai seems to have the proclivity to not upload full logs, even when the report template specifically calls for them.
That aside, right click should be working again on proton bleeding edge https://github.com/ValveSoftware/Proton/wiki/Proton-Versions#proton-bleeding-edge thanks to Gofman, and should be working on base experimental when it next updates

[Lyko5]

Don't worry @simifor it was a human mistake. I tried to upload the uncompressed and didn't realize it failed. (It was late and I was tired, looking back it was a 200mb file) anyway, Claude Code helped me summarize and diagnose the issue otherwise I was just going to uninstall the game.

I appreciate y'all working on the fix.

[simifor]

@Lyko5 just for the record and for when you encounter another issue you want to report. Users aren't expected to diagnose issues, just report the issue they are seeing and in what condition it happens (like in this case how it happened only in newer versions). IT helped here that it was easy to repro.