Hello @xairaven, we're using one issue report per unofficially supported game title, so I've gone ahead and transferred this issue report to https://github.com/ValveSoftware/Proton/issues/2143#issuecomment-4069842243.
Thank You very much!
Update 2026-09-26: root cause found: the kernel's split-lock mitigation livelocks the Ubisoft injection handshake. Fix:
sudo sysctl -w kernel.split_lock_mitigate=0. Details: https://github.com/ValveSoftware/Proton/issues/2143#issuecomment-5850732240. The analysis below is kept for reference.
@xairaven I observed a similar no-game-window endpoint on Fedora 44 / Intel Arc (xe) / Proton Experimental 11.0-20260910b, with no GamerProfile.xml in the recreated FC4 prefix.
In four instrumented FC4 runs, UbisoftGameLauncher64.exe -gamelauncher_inject_pid / -gamelauncher_inject_tid targets the Wine group/thread that stops logging; this observation is absent from one working Primal control run.
xalia.exe also runs in that working control, and no xalia injector command was observed. This does not exclude title-specific interactions.
NtGetContextThread and single-step events also occur in the working control and do not independently identify the failure here.
This is a correlation, not a demonstrated root cause. Full evidence and limitations: https://github.com/ValveSoftware/Proton/issues/2143#issuecomment-5753029566
@xairaven Follow-up: I found the root cause. The kernel's split-lock mitigation livelocks the Ubisoft injection handshake (details: https://github.com/ValveSoftware/Proton/issues/2143#issuecomment-5850732240). On an Intel CPU with split-lock detection, journalctl -k | grep split_lock during a stall should show FarCry4.exe trapping, and sudo sysctl -w kernel.split_lock_mitigate=0 before launching fixed it here. The Rs state and ~5% CPU you saw fit a thread that keeps re-trapping.
proton experimentalx2 2026-09proton 8.0x1 2026-03proton 9.0x1 2026-03PROTON_LOG=1x1 2026-03PROTON_NO_ESYNC=1x1 2026-03PROTON_NO_FSYNC=1x1 2026-03PROTON_XALIA=0x1 2026-03WINEDLLOVERRIDES="wineusb.sys,winebus.sys,gameoverlayrenderer,gameoverlayrenderer64=d"x1 2026-03WINEDLLOVERRIDES="wineusb.sys,winebus.sys=d"x1 2026-03WINEDLLOVERRIDES="xalia.exe=d"x1 2026-03WINE_CPU_TOPOLOGY=4:0,1,2,3x1 2026-03PROTON_XALIA=0 PROTON_NO_FSYNC=1 WINE_CPU_TOPOLOGY=4:0,1,2,3 WINEDLLOVERRIDES="wineusb.sys,winebus.sys,gameoverlayrenderer,gameoverlayrenderer64=d" %command%x1 2026-03WINEDLLOVERRIDES="wineusb.sys,winebus.sys,gameoverlayrenderer,gameoverlayrenderer64=d" WINE_CPU_TOPOLOGY=4:0,1,2,3 %command%x1 2026-03
Bug Report: Far Cry 4 (Steam) fails to launch via Proton on Linux - Silent hang / Deadlock during initialization
System Environment
OS: Fedora Linux 43 (Workstation Edition)
Kernel: 6.18.16-200.fc43.x86_64
Desktop Environment / Display Server: KDE Plasma / Wayland
CPU: Intel Core i5-1235U (10 Cores, 12 Threads - Hybrid P/E Architecture)
GPU: NVIDIA GeForce RTX 2050 (Hybrid Graphics / PRIME Offload) 580.126.18
RAM: 16 GB
Proton Versions Tested: Proton Experimental (experimental-10.0-20260227), Proton 9.0, Proton 8.0
Launcher: Steam (AppID: 298110) + Ubisoft Connect (latest version auto-installed via prefix)
Issue Description
Far Cry 4 fails to launch completely on Linux via Steam/Proton. Upon clicking "Play", the Ubisoft Connect launcher initializes properly, connects to the network, and seemingly hands over the launch to the game. However, the game window never appears.
The process FarCry4.exe remains running in the background indefinitely, consuming ~5.5% of CPU usage. The game sits in an Rs (Running) state but is caught in a deadlock. It fails to even reach the stage of generating the GamerProfile.xml file in the compatdata documents folder.
Crucial Context: Far Cry 3, Watch Dogs 1 run nicely without any tweaking.
Logs and Diagnostic Findings
Generating a log via PROTON_LOG=1 reveals the following behavior:
Below are some of the exact launch arguments tested via Steam, all resulting in the exact same silent deadlock:
Any assistance or an engine-level patch / Proton workaround would be highly appreciated.
FC4Logs.zip