This has been raised before, can be fixed by manually installing older version of uplay into the prefix and then changing the version number. https://www.reddit.com/r/linux_gaming/comments/a8f2kl/proton_3166_beta_released/ecbdi99/ Not a nice fix, but a fix at that.
I've managed to get this game running after doing the above steps, but am now encountering lack of audio and a rendering bug, I've uploaded the video of my issue here: https://jackryder.co.uk/stuff/far-cry-rendering-bug.mp4
@kisak-valve would my issue be best in a separate issue? Didn't want to create another open issue for the same game.
Hello @JackRyder, unless you find the root cause of an issue and the issue affects multiple games or the game is whitelisted, then it's best to discuss the game specific issues here.
Please copy your system information from steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report. Also, please add PROTON_LOG=1 %command% to the game's launch options, reproduce the issue, and drag and drop the generated $HOME/steam-$APPID.log into the comment box.
system info :https://gist.github.com/JackRyder/d706d3038a2b8893595214a95e930045
Since the game runs, the proton log is pretty hefty so I split it into two parts, I imagine the second part would be the best for infomation, but i'll attach both anyway.
steam-298110A.log
steam-298110B.log
Also using proton 3.16-6 Beta.
I was able to get it working with Proton 3.16-8 Beta, and I got sound working too. I achieved this by using protontricks to run winecfg and add FarCry4.exe with the compatibility mode set to Windows XP, then using protontricks to install xact. Now I have an issue where the game is freezing every few minutes. This is because I'm on Ryzen isn't it? The issue reminded me of another issue I had with other Dunia Engine games on wine-staging because I had too many CPU cores. This is definitely not the culprit (and shouldn't be since esync is enabled). The stuttering seems to be caused my me rapidly moving my mouse. Any ideas? I plugged a different mouse into my computer and the freezing went away. Thanks Corsair.
Had the same mouse problem but disabling Uplay overlay fixed it..!
With Proton 4.2-4 the game working with follow issues:
$ WINEPREFIX=~/.steam/steam/steamapps/compatdata/298110/pfx/ winecfg
$ WINEPREFIX=~/.steam/steam/steamapps/compatdata/298110/pfx/ winetricks xactAppearing on random locations rectangular dimming in game:

How it looks in dynamic I demonstrate on Youtube video: https://youtu.be/6O_LUtFXP58
After switching to another application and returning to game by pressing "Alt -Tab" unable rotate protagonist on 360 degrees (only 180 is possible), this issue can be workarounded if in main game menu (Escape button) and select "Resume" item.
Not working gamepad in my case it Dualshok 4
$ inxi -bM
System: Host: localhost.localdomain Kernel: 5.1.0-ea5aee6d97fd+ x86_64 bits: 64 Desktop: Gnome 3.33.1
Distro: Fedora release 31 (Rawhide)
Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX X470-I GAMING v: Rev 1.xx serial: <root required>
UEFI: American Megatrends v: 2202 date: 04/11/2019
CPU: 8-Core: AMD Ryzen 7 2700X type: MT MCP speed: 3779 MHz min/max: 2200/3700 MHz
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Vega 20 [Radeon VII] driver: amdgpu v: kernel
Display: wayland server: Fedora Project X.org 1.20.4 driver: amdgpu resolution: 3840x2160~60Hz
OpenGL: renderer: AMD Radeon VII (VEGA20 DRM 3.32.0 5.1.0-ea5aee6d97fd+ LLVM 8.0.0) v: 4.5 Mesa 19.1.0-rc2
Network: Device-1: Intel I211 Gigabit Network driver: igb
Device-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter driver: N/A
Drives: Local Storage: total: 11.57 TiB used: 8.15 TiB (70.4%)
Info: Processes: 456 Uptime: 6h 58m Memory: 31.40 GiB used: 16.62 GiB (52.9%) Shell: bash inxi: 3.0.34
The game is crashes when I enable renderdoc (ENABLE_VULKAN_RENDERDOC_CAPTURE=1) for record a trace.
Gamepad controls are not recognized in the game...
Also all foliage appears flickering
To fix flickering foliage, install/compile dxvk 1.4.4 or less for now.
Related: https://github.com/doitsujin/dxvk/issues/1257
I've bisected the flickering issue, it's caused by this commit in DXVK.
As Far Cry 4 was on sale I got it. Works with an nvidia card as far as I can see. The audio issues still exist but can be worked around as previously detailed.
I would like to get the controller part to work though. Any ideas how to go about it? The initial menu react to controller input but seem to misinterpret the input. This probably leads to controllers being disabled.
Any ideas how to go about debugging this? I'm not very experienced with wine/proton debugging.
Searching for this issue I see that Far Cry Primal also has trouble with controllers, same issue maybe.
Far Cry 4 don't run. Uplay run correctly without any problem, but when I click play on Far Cry 4 it didn't run
I've bisected the flickering issue, it's caused by this commit in DXVK.
Have you reported it to DXVK?
I've bisected the flickering issue, it's caused by this commit in DXVK.
Have you reported it to DXVK?
I wrote a comment about it in the Far Cry Primal issue (https://github.com/doitsujin/dxvk/issues/1257) because that seems to have the same problem. Unfortunately they don't really know what's causing the issue, and are not really interested in fixing it(see https://github.com/doitsujin/dxvk/issues/1257#issuecomment-558790007)
Unfortunately they don't really know what's causing the issue, and are not really interested in fixing it
from the later comment it seems like it you tracked it down pretty closely. I guess the next step (unless someone spots the issue) would be to look at the disassembly (ghidra has a diffing mode) with and without the call. not in the mood to wade through x86 assembly now, though.
it seems to work fine with Proton-6.0-GE-1
Far Cry 4 launches from UPlay then immediately crashes
Issue transferred from https://github.com/ValveSoftware/Proton/issues/5149.
@ChaosBlades posted on 2021-09-10T11:09:18:
Uplay launches the game then it immediately closes.
I see in the proton logs an error for...
[0828/085556.679:ERROR:dxva_video_decode_accelerator_win.cc(1440)] DXVAVDA fatal error: could not LoadLibrary: msmpeg2vdec.dll: Module not found. (0x7E)\
... I tried to download that dll from the internet and put it in system32 but that did not seem to help
I have tried a completely stock fresh install of Pop OS.
Up to date modded xanmod kernel
Proton GE
Adding mesa and wine repo
All versions of Proton available in Steam
This is the only game I have tried that does not work. Other UPlay games work without issue
I have Far Cry 4 Gold edition with all the DLC if that matters.
It seems msmpeg2vdec.dll is part of the Windows Media Feature Pack which led me to a winetricks github issue. that can not be linked here
It seems this is a really old issue which makes me think it is not the reason Far Cry 4 is not launching for me because it clearly worked several months ago.
Hello @ChaosBlades, the link you posted is tainted by legally problematic workaround(s) and has been removed.
I did some testing on this...
Ubisoft Connect does not work on Proton 5.13-6 or older. So that leaves only Proton 6.3-7 and Experimental.
I tried fresh installs of Pop!_OS, Manjaro, and Garuda Linux. All the the same issue.
Either Far Cry 4 works on an older Proton Version but Ubisoft Connect won't work on or this is a specific issue with my hardware config... 5950x and a 6900xt
Looking at ProtonDB I can see that this was working on the latest Pop!_OS with Proton Experimental 2 months ago with a Ryzen 5 2600 and Nvidia 1650 so perhaps this is an AMD GPU issue.
It has been months now and I am still having this issue and over these last several months I look at protondb and I see random people also having the same experience as I do appear either the game runs great or it never launches. Does not seem to matter what hardware brand you have, what version of proton you are using, or what linux distro you are on. Either you are lucky and it works or you are not lucky and it doesn't launch past UPlay. I tried multiple distros both debian and arch based, tried multiple Proton versions including experimental bleeding edge, as well as tried removing all DLC and just running the base game.
It has been months now and I am still having this issue and over these last several months I look at protondb and I see random people also having the same experience as I do appear either the game runs great or it never launches. Does not seem to matter what hardware brand you have, what version of proton you are using, or what linux distro you are on. Either you are lucky and it works or you are not lucky and it doesn't launch past UPlay. I tried multiple distros both debian and arch based, tried multiple Proton versions including experimental bleeding edge, as well as tried removing all DLC and just running the base game.
Try using the GloriousEggroll proton versions, they work better with 3rd party DRM
I have been, just tested it again with the latest version. No change on the issue. Also just tested with Resizable BAR disabled. I can see plenty of people reporting they are using official versions of Proton without issue as well.
Edit: Also for clarity all my other UPlay games work fine. Several Assassin Creed games, Watch Dogs, etc. So definitely an issue specific to Far Cry 4.
I'm in the exact same boat as you @ChaosBlades I've got an Nvidia system, Farcry 5 works no problem, Farcry 4 refuses to launch.
I have finally got this game to launch on something. I am now fairly confident this is some kind of hardware specific issue. I installed ChimeraOS 33 on my living room PC and the game works without issue. I then install ChimeraOS 33 on my desktop PC that I have been having this issue on and just like with every single other distro I tried it will not launch. Here is the hardware breakdown on both systems.
Living Room PC (Works)
CPU: AMD 5800X
RAM 32GB DDR4
Mobo: ASUS TUF GAMING X570-PLUS (WI-FI)
GPU: Nvidia GTX 1660 Super
Storage: PCI 3.0 NVMe SSD
Desktop PC (Does Not Launch)
CPU: AMD 5950X
RAM: 32GB DDR4
Mobo: ASUS ROG Crosshair VIII Dark Hero (X570)
GPU: AMD 6900XT
Storage: PCI 3.0 NVMe SSD
Based on my research I can not find anyone reporting this game to work on any CPU that has more than 12 cores 24 thread. Every reference to this game not working with a CPU model listed is reporting they have a 5950X that I am able to find.
@makeclean What CPU do you have?
I went into the BIOS and limited the CPU to 1 CCD (8 core 16 thread).... Game Launches!
That is the issue, it is some kind of core count limitation.
Now that we have identified the issue can we get a developer to look into this? Let me know if you need any logs or anything from me. I did post a log back in Sept of 2021 but if that isn't enough let me know.
I'll also update my report on protondb to reflect this issue.
Does it work if you launch the game with WINED3D?
I have already made a dxvk issue since i noticed i got stuck in the pre company logos loading screen 1/2 times with dxvk, but not with WINED3D.
The game have apparently been finicky with dxvk in the past.
I added PROTON_USE_WINED3D=1 %command% to the launch options and no it does not launch. Same result as before.
Hello @ChaosBlades, it might be interesting to test how the game behaves on the AMD 5950X system with the BIOS changed back to normal and the game's launch options set to taskset -c 0-15 %command%.
That also does not work around the issue. Also tried different variations on that such as the following.
taskset -c 0,2,4,6 %command%
taskset -c 0-7 %command%
I just disabled SMT (disables Hyperthreading) in the BIOS which turns the CPU into 16 Core 16 Thread (instead of 32 Thread). This also allows the game to launch.
Edit: Limiting each of the 2 CCDs to 7 cores (14 Core 28 Thread) also allows the game to launch.
Edit2: I would just like to state that the game does work running on this same system under Windows. Seems on Linux via Proton we have a Thread limit somewhere between 29 and 32 threads and artificially limiting that via taskset does not work around the issue.
Good investigation Chaos 👀
My email reply didn't make it to you @ChaosBlades but amazing sleuthing. I have a dual socket 32 core (64 threads total) machine, which corroborates this. Amazing work.
I wonder if its worth trying numactl- https://serverfault.com/questions/625146/difference-between-taskset-and-cpuset maybe?
Assuming I did this correctly, that does not allow the game to launch.
cpuset and numactl is not installed by default on Pop OS so after installing them both it looks like cset by default already sets up a cpuset containing threads 0-31. So I should just need to add numactl --physcpubind=+0-7 %command% to launch options and that should limit the game to CPU cores 0-7, which did not allow the game to launch. UPlay does launch which makes me think it is working, but I get the same behavior as before.
Similar issue here https://www.protondb.com/app/55150 reported by synrgy87, seems to be a theme with high core count machines.
It would be nice to have a software solution to this :)
If it works on windows then i imagine a software workaround or fix should be possible.
Note even after this has been fixed the game also is a bit iffy together with dxvk and can randomly freeze at boot at least. Dunno about ingame
I own Warhammer 40,000: Space Marine - Anniversary Edition as well and tested for this issue.
On failure it will launch to full screen (black screen) unlike Far Cry 4. It will then crash to desktop with a Bug Splat error window. Where it wants you to send in a bug report.
On this game I needed to limit the CPU to 6 Cores per CCD. So 12 Core 24 Thread. The game would not work on 14 Core 28 Thread like Far Cry 4.
I'll post in the issue thread for Space Marine as well looks like they don't understand what is going on over there yet as well.
@ChaosBlades I just learned of WINE_CPU_TOPOLOGY which is built in to protons version of wine. Dunno if that could make a difference or if it's basically the same as the other methods. I'm gathering you could run it like WINE_CPU_TOPOLOGY=4:0,1,2,3 %command% to only tell about 4 cores.
But i don't really understand really anything about it 😁
@Blisto91 THAT WORKS! Nice find!
So I can run
WINE_CPU_TOPOLOGY=31:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30 %command%
and it will launch but if I do 32 then it will act as it would without the command.
Space Marine will run with
WINE_CPU_TOPOLOGY=26:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25 %command%
but not 27. I'll post that over on that issue thread as well.
with no launch options, Ubisoft Connect starts, but the game does not launch
vk_radv %command%: Same as with no launch options - Ubisoft Connect starts, but the game does not launch
vk_amdvlk %command%: Launches but freezes immediately at the very first loading screen; it does not even reach the main menu:

PROTON_USE_WINED3D=1 %command%: Game runs, but with massive graphic glitches, see video:
Changing between different ingame graphics settings does not have any effect on these glitches.
@ngreve It's likely a dxvk issue. I also reproduce a hang at the initial loading screen. Tho that is with radv.
I have made a issue about it here https://github.com/doitsujin/dxvk/issues/2669
And there is another issue from a windows user that the game crashes when they use dxvk.
Does it say anything interesting in the proton log when you try to launch with radv or amdvlk?
Edit: i am sorry i accidently pinged the wrong person first time
Running with vk_radv the last message says (steam-298110-radv.log):
5862.720:0150:0154:trace:seh:raise (22)
terminate called after throwing an instance of 'dxvk::DxvkError'
5862.720:0150:0154:fixme:msvcrt:__clean_type_info_names_internal (1000B488) stub
Running with vk_amdvlk i can't find anything interesting, but that's because I actually do not know what I am looking for (steam-298110-amdvlk.log).
This in your radv log is very odd.
info: Required Vulkan extension VK_KHR_surface not supported
That should not happen as i'm pretty sure that is a pretty old supported extension (and required for anything to work). Could you try reinstalling radv and see if anything changes?
Be sure to install both 32bit and 64 bit version.
Hello @ngreve, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.
The requested system information (also updated my OP)
I've reinstalled vulkan-radeon and installed - the missing - 32bit version of it.
Now running with Proton-7.0-3 and vk_radv, the game freezes in the beginning just like with vk_amdvlk, but the message Required Vulkan extension VK_KHR_surface not supported disappeared, I guess that's progress (?).
But I also revisited ProtonDB and saw that people got the game running with Proton 6.3 in the past.
So, I've tested it with Proton 6.3-8 and I've got it running with with vk_radv and vk_amdvlk.
But I encountered another bug. At some point, if you switch between different Proton versions, an error message appeared that said something like "No Ubisoft Connect installed. Install it so run the game... (blabla)". This error occurred every time when I've switched from Proton 7.0 down to 6.3. Switching back to 7.0 did not fixed the error, I needed to reinstall the whole game.
So, to get it running with Proton 6.3, I firstly needed to uninstall the game.
With the game uninstalled, go into Properties -> Compatibility -> Select Proton 6.3-8, then install the game.
Now Steam/Proton finds Ubisoft Connect and starts the game.
Again, the game now runs with Proton 6.3-8 and both vk_radv and vk_amdvlk.
Thanks, https://gist.github.com/ngreve/1cce2333b360acc6229ea68457ecc4d0#file-gistfile1-txt-L278-L291 and https://gist.github.com/ngreve/1cce2333b360acc6229ea68457ecc4d0#file-gistfile1-txt-L439-L452 looks like https://github.com/GPUOpen-Drivers/AMDVLK/issues/278 could be interfering with your testing.
If they are using https://aur.archlinux.org/packages/amd-vulkan-prefixes i think as long as they launch with vk_radv %command% it should be fine. In the game at least. But yes the lines look odd in the system report.
@ngreve Good to hear with some progress. Could i get you to try and start the game 3-4 times into the main menu with 6.3-8 and see if it succeeds each time? at least my own issue was that it only happened some times. If it doesn't freeze with 6.3-8 at all thats a good data point to try and find a regression for when i test it again later.
I've entered the main menu multiple times now and played for ~5min and it seems to run fine with two little caveats:
Before you enter the main menu, there is this splash screen with the FarCry 4 Logo and the message "Press any key". When I now press a key, the game focus gets lost and I have to alt+tab into the game again. But then I am in fact in the main menu and can play the game.
The game freezes, as soon as I try to enter the steam community overlay with shift+tab steam-298110-steam-overlay-crash.log.
EDIT: Btw, thanks for the exchange of ideas and getting it running in the end.
Okay thanks for testing.
On the second point i think i remember seeing that too when i was testing Far Cry 2. When i brought up the steam overlay it froze. Forgot to make a comment about it.
But I encountered another bug. At some point, if you switch between different Proton versions, an error message appeared that said something like "No Ubisoft Connect installed. Install it so run the game... (blabla)". This error occurred every time when I've switched from Proton 7.0 down to 6.3. Switching back to 7.0 did not fixed the error, I needed to reinstall the whole game.
You just need to delete the compatdata folder for the game. You don't need to reinstall the entire game.
Replying to https://github.com/ValveSoftware/Proton/issues/2143#issuecomment-1148536945
Genius! Yes, I have 64 cores that will be it! Man that's quite the find.
Far Cry 4: It's impossible to play under any version of Proton
Issue transferred from https://github.com/ValveSoftware/Proton/issues/6942.
@Plarpoon posted on 2023-07-21T00:58:38:
Note:
This log is with Proton 8.0-2, it fails immediately after having done the initialization of Ubisoft Connect, it can't even create the window of the game. You have to stop the process manually from within the Steam app by pressing "STOP" as after failure it will remain open in the background forever.
steam-298110 8.0-2.log
This log is done with GE-Proton8-6, I am aware this is not the place to report Proton GE issues but I am using it only to report what happens once you pass the Ubisoft connect phase and actually manage to create a window. In this case as said the window gets fully created but it crashes a few seconds in during the very first loading screen, not even allowing me to enter into the main menu.
In this case as-well the process will hang forever and the only way to make it stop is by stopping it from withing the Steam app.
steam-298110 GE-Proton8-6.log
Many reports on the game's ProtonDB page suggest switching to a Proton version equal or inferior to 6.3 as that's the patch that broke the game into the current situation it's in. Unfortunately the behavior is virtually identical to the one of 8.0-2 as it can't pass from the Ubisoft connect launcher properly and it crashes before creating the game window.
steam-298110 6.3-8.log
I have also added a log with proton experimental (timestamped) but it behaves exactly like Proton 8.0-2.
steam-298110 Proton Experimental 21 Jul 2023.log
Currently for me it's impossible to play this game in any way shape or form, if I can be useful for any ulterior testing let me know and I will provide all the help I can!
Thank you in advance! :)
@kisak-valve did you managed to get it working by any chance? Just got it on a sale and it's dead stuck for me and I'm also using RX 7900 XTX.
For the sake of the argument, I also did not give up on this, my hardware is still the same and I tried a couple of months ago again. It still won't boot.
For the sake of the argument, I also did not give up on this, my hardware is still the same and I tried a couple of months ago again. It still won't boot.
It weird though, there are quite a few fairly recent report on ProtonDB that it works, both nVidia and AMD users, but well, tough luck then I guess
I mean.. yeah.. but if possible I would definitely like to play that one, it's the one that is missing out from my collection of Far Crys
I'll be honest the following did it for me
WINE_CPU_TOPOLOGY=31:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30 %command%
I'll be honest the following did it for me
WINE_CPU_TOPOLOGY=31:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30 %command%
I've been trying all of those yesterday with no luck. I'm using 5900X, so it's 12C/24T, I've also tried
WINE_CPU_TOPOLOGY=4:0,2,12,14 %command%
Still hangs at the loading screen:
@agurenko Assuming you're using proton stable, could you try using Proton 9 (currently in beta) and see if you still have the issue? You might need to delete the game's prefix.
@agurenko Assuming you're using proton stable, could you try using Proton 9 (currently in beta) and see if you still have the issue? You might need to delete the game's prefix.
I've tried all versions from 6 to 9, Experimental and GE both 8 and 9, so no dice
I can confirm that the game no-longer works using Steam Proton Experimental or 9.0.1.
Ubuntu 24.04 - Nvidia RTX 3080 - 535.171.04
Clicking the Play button should initially start the installation process for Ubisoft Connect, but this never happens, I see the processing Vulkan shaders and then it returns to the Play button again.
Native Steam package with the game installed on an Ext4 formatted partition.
OK, so I managed to get it working.
Install UbisoftConnectInstaller.exe as a non-steam game using Proton Experimental.
Then launch the game again, and it correctly will launch Ubisoft Connect and load the game.
You still need to disable the Steam Overlay however.
Thank you a lot @intelligentgaming, not only your solution fixed Far Cry 4 for me but also allowed me to solve another issue I had on Mass Effect LE! 🎉
I remember a week ago I used to play "Outpost Master" non stop because I could quickly reload the stage and assess my approaches, it was fun.
But then, I progressed further in the game. After making the Arena available and conquering the first fortress in the game, every-single-outpost now takes forever and then some to load. Quick reloads are gone, they take additional time, ruining the fun. I've tried Glorious Eggroll, Proton, Linux runtime, you name it but apparently this is something I can't workarond.
I guess you can't have too much fun with an Ubisoft game.
steam-220240.log
steam-233270.log
The games don't start nor does the ubisoft launcher.
Install Far Cry 3, 3:Blood Dragon, 4.
Disable/Enable FSYNC/ESYNC, DXVK_ASYNC.
Doesn't start with nor without options.
OK, so I managed to get it working.
Install UbisoftConnectInstaller.exe as a non-steam game using Proton Experimental.
Then launch the game again, and it correctly will launch Ubisoft Connect and load the game.
You still need to disable the Steam Overlay however.
This doesn't work for me, using the flatpak version of steam.
Edit: I actually use the rpmFusion fedora 41 package of Steam.
Far Cry 4, GE-Proton9-27:
steam-298110.log
Far Cry 4 (298110) - Not Launching
Issue transferred from https://github.com/ValveSoftware/Proton/issues/9579.
@xairaven posted on 2026-03-16T18:32:14:
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:
Any assistance or an engine-level patch / Proton workaround would be highly appreciated.
I had the same issue about the process just hanging at start (not even drawing a window).
I fixed it with sudo sysctl kernel.split_lock_mitigate=0. As soon as I ran that, the game just came to life.
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.
TL;DR — FC4 stops after its second Wine stage loads uxtheme.dll, with one thread and no observed game device/window.
The launcher injection handshake is the narrowest remaining lead: its target matches that stage in 4 FC4 runs, absent from 1 working Primal run.
Old prefix residues/overrides alone do not explain the result; xalia presence and shared launch flags do not distinguish failure from success.
This does not establish the only possible hypothesis or clear d3dcompiler, DXVK, Vulkan or xe.
I am asking for help interpreting the injector's behavior under Wine. This is a correlation, not a demonstrated root cause.
Ubisoft Connect starts, logs in and hands off the launch, but no window attributable to FarCry4.exe is observed. The second game process remains alive during the captured interval.
The original 2018 report describes Uplay stuck on “Looking for updates” plus an error dialog; that is a different symptom. This update belongs here as the FC4 tracking issue.
Local runtime evidence comes from five hash-sealed runs: four FC4 runs and one Primal positive control. Filesystem checks and third-party reports are distinguished below.
7.2.5-200.fc44.x86_64, GNOME/Wayland with XWayland, native Steam RPM.8086:7d55.xe driver; xe.force_probe=7d55 i915.force_probe=!7d55 module_blacklist=i915.1789159601 experimental-11.0-20260910b-x86_64; DXVK v3.1-12-g8759acd15dc79c8.26.2.2-6.fc44, Vulkan loader 1.4.341.0. The sealed Primal log reports Mesa 26.1.8; later FC4 logs report 26.2.2, a comparison limitation.Normal-run launch options:
PROTON_LOG=1 PROTON_LOG_DIR=$HOME/fc4diag/proton-logs gamemoderun DXVK_FRAME_RATE=0 DXVK_HUD=fps %command%
Far Cry Primal (371660), n=1, works with the same Proton build and normal launch options: info: Game: FCPrimal.exe, winevulkan.dll, device creation and a window owned by the game process. Its sampled game process reaches 75 threads and has /dev/dri FDs in 59/61 samples. This is a different title/prefix, and the Mesa difference above remains a confounder.
The four FC4 runs used the existing prefix, a recreated prefix, PROTON_USE_WINED3D=1, and PROTON_NO_NTSYNC=1, respectively. All four reached the same no-observed-game-window endpoint.
uplay_r164.dll. Each of the four logs records two c0000005 faults in NtQueryInformationProcess (six matching log lines, not six faults).uxtheme.dll. It does not load uplay_r164.dll; neither FC4 stage has an observed winevulkan.dll load./dev/dri FDs throughout. S (sleeping) predominates, but R and tracing-stop samples also occur. Independently read state fields need not agree at every instant. Non-zero TracerPid observations are not proof that launcher injection blocks progress. No CPU percentage was sealed.No info: Game: FarCry4.exe appears in the four FC4 logs. UplayWebCore.exe does create a device on the Arc GPU in the launcher path; the attached matched-run excerpt shows this. That bounds the observed game progression; it does not clear DXVK, Vulkan, presentation or xe as possible contributors.
A read-only check found no GamerProfile.xml in the current recreated FC4 prefix, while Primal's prefix contains it. This is a first-run progress marker, not a cause or proof of the precise engine initialization boundary.
The following was observed in all four instrumented FC4 runs and absent from the single Primal control run:
UbisoftGameLauncher64.exe -gamelauncher_inject_pid <N> -gamelauncher_inject_tid <M>
The decimal arguments match the hexadecimal Wine group/thread that loaded the second FarCry4.exe and stopped logging:
| Run | inject_pid | inject_tid | Wine group:thread |
|---|---|---|---|
| Existing prefix | 1224 → 0x04c8 |
1228 → 0x04cc |
04c8:04cc |
| Recreated prefix | 2444 → 0x098c |
2448 → 0x0990 |
098c:0990 |
| WineD3D | 1228 → 0x04cc |
1232 → 0x04d0 |
04cc:04d0 |
| No-ntsync | 1216 → 0x04c0 |
1220 → 0x04c4 |
04c0:04c4 |
No capture records the injection's result. I am not claiming that the Ubisoft launcher injection handshake is the root cause. It is currently the narrowest repeatable divergence I found between the four instrumented FC4 runs and the single working Primal control run.
D3DCOMPILER_43.dll still loads in that run and in the working Primal control; both logs also contain native 39 and builtin 47. Old registry overrides/residues alone do not explain the failure; d3dcompiler interactions are not eliminated generally.-uplay_steam_mode and a first/second launch pattern also occur in Primal. No TLB timeout/reset/hang was found in the five sealed kernel captures; this does not establish that xe is innocent.One instrumented run (25/25 sealed hashes) genuinely changed the DLL path: wined3d.dll plus three libvkd3d* DLLs appeared. It still reached the one-thread, no-observed-game-window endpoint.
A window titled “Far Cry 4” was owned by Steam PID 47154, not by FarCry4.exe; launcher windows likewise are not game windows. Window sampling via wmctrl/xprop cannot prove absolute absence.
An earlier uninstrumented user report said WineD3D produced a window with poor performance; this sealed run did not reproduce it. WineD3D is not demonstrated as a solution here.
One run (26/26 sealed hashes) used PROTON_NO_NTSYNC=1, recorded two t_launch and two t_gameexe events, and captured both FarCry4.exe stages and the injector. It was a real launch, not an aborted capture.
The log says fsync: up and running.: ntsync was disabled while fsync remained enabled. The same terminal state followed. Prefix drift makes this a bounded attempt, not a clean causal A/B or a demonstrated solution.
[#9579](https://github.com/ValveSoftware/Proton/issues/9579), closed as a duplicate here, reports a similar no-window/no-GamerProfile.xml endpoint on Fedora 43, NVIDIA RTX 2050/PRIME and older Proton versions. The supplied report differs from our evidence in important ways:
xalia.exe runs in all four FC4 runs and the working Primal control; no xalia injector command was observed. The observed injection arguments belong to UbisoftGameLauncher64.exe. This does not exclude title-specific interactions or demonstrate DRM/anti-debug behavior.NtGetContextThread / EXCEPTION_SINGLE_STEP counts are Primal 58,026/8, matched FC4 13,941/6, recreated 133,848/10, WineD3D 14,766/6, no-ntsync 17,532/6, with +seh tracing. The working control is not the highest-count run. The second-stage groups in the two normal FC4 runs have zero context-event lines.Rs at ~5.5% CPU; ours is predominantly S, with one thread and no sealed CPU percentage. Its PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 attempt reportedly changed R to S without fixing the problem. That differs from our ntsync-off/fsync-on attempt and is not a controlled cross-machine comparison.A supplied ProtonDB report (~July 2026) suggests Proton 9.0-4, a recreated prefix, dxgi.deferSurfaceCreation=True and a six-CPU topology. It describes loading/menu freezes with a window already present, potentially a different symptom; we did not test it.
The supplied external search found no prior Wine/Proton discussion of the injection flag; no novelty claim is intended.
NtQueryInformationProcess faults expected launcher behavior, or worth investigating?UbisoftGameLauncher64.exe -gamelauncher_inject_pid in another Ubisoft title that successfully runs under Proton? A working title using this path would show that injection alone does not explain the failure and would narrow the search substantially. This is the cheapest comparison others could contribute; our single working Primal capture contains no such command.Existing public gist: sanitized excerpts, with source runs and original line references:
fc4-second-stage-full-output.txt — 59 second-stage lines from each of the two normal FC4 runs.fc4-first-stage-c0000005.txt — first-stage fault excerpts from those two runs.fc4-uplay-injection-cmdlines.txt — all four FC4 injection command lines and decimal→hex mappings.fc4-uplaywebcore-creating-device.txt — matched-run launcher device creation.primal-control-fcprimal-creating-device.txt — working control's game/device initialization.Personal home paths are replaced by $HOME. Full multi-megabyte logs are retained locally; specific ranges can be provided if useful.
Update: root cause found. The kernel's split-lock mitigation livelocks the Ubisoft Connect injection handshake. Fix: sudo sysctl -w kernel.split_lock_mitigate=0.
Follow-up to my previous comment. The one-thread, no-window stall is not a Wine deadlock: the game thread is stuck inside the kernel's split-lock trap handler.
FarCry4.exe and runs UbisoftGameLauncher64.exe -gamelauncher_inject_pid N -gamelauncher_inject_tid M, which polls that thread's context in a loop.#AC: FarCry4.exe/34309 took a split_lock trap at address: 0x6ffff388c28e.kernel.split_lock_mitigate=1 (the default on Fedora and most desktop distros; SteamOS ships 0), split_lock_warn() sleeps 10 ms in msleep_interruptible() before letting the instruction run, and returns without executing it if that sleep is interrupted.SIGUSR1); both processes show ~2,700 context switches per second. No 10 ms sleep ever completes, the instruction traps again forever, and the injector never sees progress and never gives up.Fedora 44, kernel 7.2.5, Intel Core Ultra 5 125H. Proton Experimental 11.0-20260924 (ntsync) and Proton 9.0-4 (fsync) both reproduce.
/proc/<pid>/syscall = -1 0x10f378 0x6ffff388c28e (not in a syscall, PC = trap address), wchan = msleep_interruptible, 1 thread.#AC: FarCry4.exe/24131 took a split_lock trap at address: 0x6ffff38ac28e. I missed it then.kernel.split_lock_mitigate=0 and nothing else changed, the next launch went straight through: the game connected to Ubisoft Connect 5 s after the play session started, with no injection failure or fallback in game_starter_log.txt (one launch so far). With the default, every launch stalled: 4 runs on 2026-09-20 and 5 today.Excerpts: fc4-split-lock-evidence.txt.
With a tracer attached, wineserver can't ptrace the thread (suspend_for_ptrace(): "this may fail if the client is already being debugged", then STATUS_ACCESS_DENIED). The injector's GetThreadContext fails and Ubisoft's own fallback kicks in (game_starter_log.txt):
GetThreadContext failed. Error code 5
Failed to inject suspended process. Process terminated '1396'
Falling back to no injecion
The relaunched, non-injected game hits the same split lock, pays only the 10 ms penalty, and starts. That is why the gdb nudge in #9958 works every time; it is not timing.
sudo sysctl -w kernel.split_lock_mitigate=0. To persist: echo 'kernel.split_lock_mitigate = 0' | sudo tee /etc/sysctl.d/99-split-lock-mitigate.conf. Split locks are still detected and logged; only the 10 ms penalty goes away, which the running game otherwise also pays (dozens of its threads trap on the same instruction while playing).timeout 2 strace -p "$(pgrep -nx FarCry4.exe)" -o /dev/null.This likely applies to other Ubisoft titles launched through this injector on Intel CPUs with split-lock detection, and would explain why some systems (e.g. SteamOS) are unaffected. Proton itself can't change this sysctl.
proton experimentalx8 2026-09proton 9.0-4x2 2026-09proton 8.0x1 2026-03proton 9.0x1 2026-03ge-proton9-27x1 2025-04ge-proton8-6x1 2023-07proton 8.0-2x1 2023-07proton 7.0x2 2022-07proton 7.0-3x2 2022-07proton 6.3x1 2022-07proton 6.3-8x1 2022-07proton 5.13-6x1 2021-10proton 6.3-7x1 2021-10proton 6.0-ge-1x1 2021-01proton 4.2-4x1 2019-05PROTON_LOG=1x4 2026-09PROTON_USE_WINED3D=1x3 2026-09PROTON_NO_ESYNC=1x2 2026-09PROTON_NO_FSYNC=1x2 2026-09DXVK_FRAME_RATE=0x1 2026-09DXVK_HUD=fpsx1 2026-09PROTON_LOG_DIR=$HOME/fc4diag/proton-logsx1 2026-09PROTON_NO_NTSYNC=1x1 2026-09WINE_CPU_TOPOLOGY=4:0,1,2,3x2 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-03DXVK_ASYNCx1 2025-04WINE_CPU_TOPOLOGY=31:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30x3 2024-04PROTON_LOG=1 PROTON_LOG_DIR=$HOME/fc4diag/proton-logs gamemoderun DXVK_FRAME_RATE=0 DXVK_HUD=fps %command%x1 2026-09PROTON_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-03WINE_CPU_TOPOLOGY=31:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30 %command%x3 2024-04WINE_CPU_TOPOLOGY=4:0,2,12,14 %command%x1 2024-04PROTON_USE_WINED3D=1 %command%x2 2022-07WINE_CPU_TOPOLOGY=26:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25 %command%x1 2022-06WINE_CPU_TOPOLOGY=4:0,1,2,3 %command%x1 2022-06physcpubind=+0-7 %command%x1 2022-06d3dcompiler_43.dllx1 2026-09uplay_r164.dllx1 2026-09uxtheme.dllx1 2026-09wined3d.dllx1 2026-09winevulkan.dllx1 2026-09msmpeg2vdec.dllx2 2021-09
Compatibility Report
System Information
I confirm:
Symptoms
A Uplay window with the title "Looking for updates" appears, accompanied by an error message box that tells us that Uplay has detected an unrecoverable error and must shut down.
Log file: steam-298110.log
Uplay crash dump (GZipped):
Uplay.exe_4.8.1.3617_2018-12-26_18-53-02.dmp.gz
Reproduction
Install Far Cry 4 and click the "Play" button.