protonscr

Far Cry 4 - Not Launching

protonclosed appid 298110
ValveSoftware/Proton#9579 · opened 2026-03-16 by xairaven · updated 2026-09-26 · 4 comments · github · game page · search this game
Xxairaven 2026-03-16 github

Bug Report: Far Cry 4 (Steam) fails to launch via Proton on Linux - Silent hang / Deadlock during initialization

  1. 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)

  2. 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.

  3. Logs and Diagnostic Findings
    Generating a log via PROTON_LOG=1 reveals the following behavior:

  • Continuous, infinite spam of NtGetContextThread and EXCEPTION_SINGLE_STEP.
  • The engine appears to suffer a threading deadlock (likely Job Manager struggling with the Intel Alder Lake Hybrid P/E core architecture, or VMProtect anti-tamper failing to parse the Proton environment/CPU topology).
  • Proton's accessibility tool (xalia.exe) was observed attempting to hook into the game process, which might be triggering the game's anti-cheat/DRM protections, causing it to intentionally trap the main thread in an infinite loop.
  1. Extensive Troubleshooting Steps Already Taken (None succeeded)
  • Clean Installation: Completely deleted the prefix folder (compatdata/298110) and cleanly reinstalled the game.
  • Steam Input & Overlays: Disabled Steam Input entirely. Disabled both Steam Overlay and Ubisoft Connect in-game overlays.
  • USB Polling Fix: Applied WINEDLLOVERRIDES="wineusb.sys,winebus.sys=d" to prevent known winedevice.exe segmentation faults. (Improved background stability, but game still hangs).
  • CPU Topology Masking (Addressing Intel Hybrid Core issues): * Applied WINE_CPU_TOPOLOGY=4:0,1,2,3 to force a symmetric quad-core environment. Used Linux scheduler taskset -c 0-3 to physically restrict the process.
  • Synchronization Toggles: * Used PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 to prevent deadlock states. (This merely changed the process state from Running R to Sleeping S, but still no graphical output).
  • Xalia Isolation: Blocked Proton's accessibility hook via PROTON_XALIA=0, WINEDLLOVERRIDES="xalia.exe=d", and physically renaming the binary in the Proton files.
  • Graphics & Windowing: * Forced NVIDIA GPU via __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia.
  • Manually created the directory structure and injected a GamerProfile.xml forcing WindowMode="2" (Borderless) to bypass potential Wayland fullscreen capture bugs.
  1. Tested Launch Parameter Combinations
    Below are some of the exact launch arguments tested via Steam, all resulting in the exact same silent deadlock:
  • Vanilla test (after clean install): PROTON_LOG=1 %command% -skipintro
  • Core isolation & Overlay block: WINEDLLOVERRIDES="wineusb.sys,winebus.sys,gameoverlayrenderer,gameoverlayrenderer64=d" WINE_CPU_TOPOLOGY=4:0,1,2,3 %command%
  • Maximum isolation: PROTON_XALIA=0 PROTON_NO_FSYNC=1 WINE_CPU_TOPOLOGY=4:0,1,2,3 WINEDLLOVERRIDES="wineusb.sys,winebus.sys,gameoverlayrenderer,gameoverlayrenderer64=d" %command%

Any assistance or an engine-level patch / Proton workaround would be highly appreciated.

FC4Logs.zip

Kkisak-valve maintainer 2026-03-16 github

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.

Xxairaven 2026-03-16 github

Thank You very much!

LLucasCerattoRS 2026-09-20 github

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

LLucasCerattoRS 2026-09-26 github

@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.