protonscr

Assasin's Creed Black Flag Resynced

protonopen appid 3751950Game compatibility - Unofficial
ValveSoftware/Proton#9958 · opened 2026-07-09 by igormcsouza · updated 2026-07-26 · 9 comments · github · game page · search this game
3 matching comments, n / p to jump
Iigormcsouza 2026-07-09 github

Compatibility Report

  • Name of the game with compatibility issues: Assasin's Creed Black Flag Resynced
  • Steam AppID of the game: 3751950

System Information

  • GPU: GeForce RTX 5050
  • Video driver version: nvidia 580.159.03
  • Kernel version: 6.17.0-1025-oem (Ubuntu 24.04)
  • Link to full system information report as Gist:
  • Proton version: 11

I confirm:

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

Symptoms

Game does not start past the Ubisoft Connect Banner ... I tried to watch the logs and it seems stuck in a loop, steam and ubisoft connect thinks the game is running.. but nothing happens!

Reproduction

Install thru steam and start the game using proton experimental

While I was debugging I attached gdb to see the issue and then the game started! I think this might be a time race conditional error.. for now, the game only starts for me if I do this!

assassins-creed-black-flag-resynced-debug-notes.md

I asked the AI to document the process for me so that anyone else can try also!

I also created a script that can help maybe... to start the game with the workaround!

acbf_resync_nudge.sh

Bbertonha 2026-07-10 github

Root cause found (at least on my system): kernel ntsync. Workaround: PROTON_NO_NTSYNC=1

Same symptom as @igormcsouza with AC Black Flag Resynced (appid 3751950) and also AC Shadows: pressing Play sometimes does nothing, launcher_log.txt stops at Using CEF with native rendering and never reaches Login Type: ticket, platform: Steam. The failure is random per launch — parsing my launcher_log.txt history gave 7 successes out of 36 launches (~19%) since install.

System: CachyOS, kernel 7.1.3-2-cachyos (has /dev/ntsync), Proton Experimental buildid 24009459, Mesa/RADV, Wayland session.

What I found while the launcher was stalled:

  • The full upc.exe process tree is alive (~50 threads incl. CrBrowserMain, plus UplayWebCore.exe CEF helpers). No crash, no error — and no network connections ever opened, so it hangs before even requesting the Steam auth ticket.
  • The CEF helper processes (UplayWebCore.exe) spawn and exit within ~1 second, repeatedly, until CEF gives up; meanwhile the Ubisoft startup threads freeze at the exact moment of CEF init. The CEF browser thread keeps pumping (Chromium's HangWatcher is visibly sampling thread contexts in the Proton log), so it's an in-process deadlock/lost-handshake, not a kernel-level hang.
  • All stuck threads wait in wchan ntsync_char_ioctl — Proton Experimental silently prefers the kernel ntsync device over fsync when /dev/ntsync exists (WINEFSYNC=1 in the env is ignored in that case; wineserver prints ntsync: up and running.).
  • Note for anyone trying to debug this: upc.exe self-terminates the moment winedbg attaches (anti-debug), so no backtraces that way. SIGSTOP/SIGCONT on the stalled process does not un-stick it.

Workaround that fixed it: launch options

PROTON_NO_NTSYNC=1 %command%

Result: 10/10 successful launches (vs the 19% baseline; ~1e-5 probability of that being luck). Same fix works for AC Shadows.

Things I ruled out with A/B launches, in case they're suggested here: deleting the launcher's cache/http2 (still stalls after full wipe — the random success rate just makes it look like a fix), PROTON_ENABLE_WAYLAND/HDR launch options (stalls with and without), Proton/Steam/kernel updates (none in the failure window).

@igormcsouza — your gdb-attach "nudge" workaround fits this picture: attaching perturbs the ntsync wait timing rather than fixing anything. If your kernel has /dev/ntsync, could you check whether PROTON_NO_NTSYNC=1 also fixes it for you? That would confirm this is an ntsync race in CEF's subprocess handshake rather than something game-specific.

Iigormcsouza 2026-07-10 github

I tested PROTON_NO_NTSYNC=1 idea from @bertonha but unfortunately it cannot apply to my system (my kernel doesn't supports it), I hit the same symptom on fsync and esync, so the race is probably not ntsync-specific tho.

My setup with kernel 6.17.0-oem (no /dev/ntsync.. the flag is a no-op here, Proton logs fsync: up and running) and Proton Experimental

But thanks to this great debugging effort from @bertonha I was able to narrow down even more the issues for me and here is what I found while debugging my stalls:

  1. Same intermittent symptom, different sync backend. When stalled, my threads were parked in futex_wait_multiple (the fsync wait path). I then retried with PROTON_NO_FSYNC=1 (esync fallback) and still got a stall, so on my machine the race survives across sync backends, suggesting the lost-wakeup happens at a higher level (the launcher/game handshake), with ntsync perhaps just widening the race window on your kernel.
  2. A second stall point exists, past the one you described. Yours dies at CEF init before login. I also caught a case where login fully succeeds (launcher_log.txt reaches Login Type: ticket and Play session successfully started) but ACBlackFlag.exe parks at 1 thread forever during the UbisoftGameLauncher64.exe inject handshake. A healthy game process ramps to ~50 threads within seconds, so thread count is a reliable freeze detector.
  3. The gdb nudge fits your theory. Attaching gdb stops and resumes all threads, forcing blocked waits to re-check their condition... it un-sticks both stall points every time (the parked 1-thread stub exits normally and the launcher respawns the game, which then boots fine). It's timing perturbation, not a fix, consistent with a lost-wakeup race.
  4. Practical workaround for anyone without ntsync: No flag needed..but I still rely on my watchdog script that polls for the two freeze signatures (steam.exe shim with no UbisoftGameLauncher.exe child; game process stuck at 1 thread) and nudges via gdb -batch -p <pid> -ex 'handle SIGUSR1 nostop noprint pass' -ex 'handle SIGQUIT nostop noprint pass' -ex 'handle SIGSYS nostop noprint pass' -ex continue. 100% launch success since. Happy to share the updated and more precise version.

acbf_resync_nudge.sh

TL;DR: PROTON_NO_NTSYNC=1 untestable here (no ntsync), but the same race reproduces on fsync and esync.. so the root cause is likely in the CEF/launcher subprocess handshake itself, with the sync backend only affecting how often the window is hit.

SSchidstorm 2026-07-10 github

I can confirm the same issue on my system.

System:

  • Kubuntu 24.04 LTS
  • NVIDIA GeForce RTX 4090
  • NVIDIA Driver 595.71.5
  • Proton Experimental

Without the GDB workaround, Ubisoft Connect launches, but the game never reaches a playable state.

The helper script was able to start the game process, but on my system that alone was not sufficient. ACBlackFlag.exe remained running in the background (sleeping) without creating a game window.

What consistently works for me is attaching GDB directly to the running ACBlackFlag.exe process after it has started:

gdb -q -batch -p <PID_OF_ACBlackFlag.exe> \
  -ex 'set pagination off' \
  -ex 'detach' \
  -ex 'quit'

As soon as I detach from the actual game process, the game immediately continues and the window appears.

So in my case, the GDB nudge is required not only for the Proton/Ubisoft launcher process but also for the actual ACBlackFlag.exe process.

Nngrampsas 2026-07-11 github

I can confirm the same issue on my system.

System:

  • Ubuntu 26.04 LTS
  • NVIDIA GeForce RTX 4090
  • NVIDIA Driver 610.43.02
  • Intel Core i9-13900KF
  • Proton-CachyOS Latest

Three issues in acbf_resync_nudge.sh prevented it from working on my system:

1. GAME_PATTERN never matched the real game process

The original pattern '^S:.*ACBlackFlag\.exe' was written for ps output (where S: is the process state), but find_pid uses pgrep -af which outputs PID COMMAND. The ^ anchored to the PID number, so nothing ever matched. Additionally, bare ACBlackFlag.exe matched the outer shell wrapper (/bin/sh -c ... steam-launch-wrapper ... ACBlackFlag.exe) and the Wine steam.exe shim, both of which have lower PIDs than the real game process.

Fix: Changed to 'Z:.*ACBlackFlag\.exe' to match the actual Wine process path (e.g. Z:\...\ACBlackFlag.exe), and added an exclude parameter to find_pid to filter out the shim.

2. nudge() used -ex continue instead of -ex detach

The nohup gdb ... -ex continue & approach keeps GDB attached and tracing, which doesn't produce the stop/resume cycle needed to unblock the futex deadlock. What actually works is attach-then-detach: GDB attach stops all threads, then detach resumes them, forcing every thread to re-check its wait condition.

Fix: Changed to gdb -batch -p "$pid" -ex 'detach' -ex 'quit' (synchronous, no backgrounding needed).

3. LAUNCHER_PATTERN missed UbisoftConnect.exe

On my system the launcher binary is UbisoftConnect.exe, not UbisoftGameLauncher.exe.

Fix: Added alternation to cover both names.

I add the updated script in case it helps you. The game launches normally with the script now

acbf_resync_nudge_v2.sh

Iigormcsouza 2026-07-11 github

Good news! Thanks to the comment from Hodor at ProtonDB I got a much better workaround which is to set sudo sysctl kernel.split_lock_mitigate=0 before starting the game!

I see some distributions already comes with this enabled and that explains why people are getting the game running out of the box.. and why for others only disabling ntsync would suffice..

I hope this can help people that are striving to run the game using the nudge ... And it actually narrows down even more the issue!

I'm used to set this guy to 0 when running NFS Heat.. but would love to have a proper fix for Assassin's Creed Black Flag Resynced.. :D So you can finally just play and go!

Kkisak-valve maintainer 2026-07-13 github

AC: Black Flag Resynced - In-game HDR setting automatically reverts to OFF on SteamOS / Proton (Steam Machine 512GB)

Issue transferred from https://github.com/ValveSoftware/Proton/issues/9970.
@geeksonhugs posted on 2026-07-13T20:05:42:

Compatibility Report

Assassin's Creed: Black Flag Resynced (AppId: 3751950)⁠

System Information

Steam Machine 512GB (2026)

AMD GPU

Custom Steam Machine console configuration (Connected to a 4K Living Room TV).

Proton Version

Default selected stable Proton build, also tested on Proton Experimental & Proton Hotfix.

Game name

Assassin's Creed: Black Flag Resynced

Behavior

The native in-game HDR toggle refuses to stick. When toggling HDR to "On" in the video settings and hitting apply, the screen blanks out momentarily for a display handshake, but immediately returns with the setting reverted to "Off."

Note: The SteamOS Quick Access Menu (QAM) "Enable HDR" toggle works perfectly, triggering the expected system-level tonemapping pop, but the game engine itself fails to recognize native HDR availability.

Steps reproduced / Troubleshooting attempted:

  1. Verified SteamOS QAM has HDR enabled.
  2. Swapped between the game's available windowing modes (Borderless and Windowed).
  3. Dropped the Steam client's "Maximum Game Resolution" properties from Global 4K down to 1920x1080 to prevent resolution-mismatched handshake drops.
  4. Tested the environment variable flag in Launch Options: PROTON_ENABLE_HDMI_HDR=1 %command%
  5. Appended the '-fullscreen' argument to the launch options to bypass borderless engine loops.
  6. Forced the game to run via Proton Experimental.

In all scenarios, the behavior remains identical: the display blanks out and immediately reverts the native HDR toggle back to off.

I confirm:

  • [X] that I haven't found an existing compatibility report for this game.
  • [X] that I have checked whether there are updates for my system available.
Jjohnfercher 2026-07-16 github

IDK if this is the most appropriate place to talk about this. The HDR is working, but in a strange way.

Before I add this configs PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 %command% when I enabled the HDR the colors were completed washed (as I already experience in other games with HDR problems). After adding, it worked but, the color still a little bit washed out (less but still visible). I'm using last Bazzite version, RTX 4090 and I9 CPU.

More info:
I tried many proton versions, inclusing GE protons.

RRicaz 2026-07-16 github

Game has been running great with 100+ FPS on my 5800X and 9070XT.
I have run into some crashes though. The amdgpu driver crashes and resets the GPU:

Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:5 pasid:391)
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:  Process ACBlackFlag.exe pid 123758 thread vkd3d_queue pid 124326
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:   in page starting at address 0x0000000000000000 from client 10
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00501031
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:          Faulty UTCL2 client ID: TCP (0x8)
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:          MORE_FAULTS: 0x1
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:          WALKER_ERROR: 0x0
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:          PERMISSION_FAULTS: 0x3
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:          MAPPING_ERROR: 0x0
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:          RW: 0x0
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:5 pasid:391)
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:  Process ACBlackFlag.exe pid 123758 thread vkd3d_queue pid 123886
Jul 17 00:24:45 n0va kernel: amdgpu 0000:09:00.0:   in page starting at address 0x000000000100d000 from client 10
Jul 17 00:24:47 n0va kernel: amdgpu 0000:09:00.0: Dumping IP State
Jul 17 00:24:47 n0va kernel: amdgpu 0000:09:00.0: Dumping IP State Completed
Jul 17 00:24:47 n0va kernel: amdgpu 0000:09:00.0: [drm] AMDGPU device coredump file has been created
Jul 17 00:24:47 n0va kernel: amdgpu 0000:09:00.0: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
Jul 17 00:24:47 n0va kernel: amdgpu 0000:09:00.0: ring gfx_0.0.0 timeout, signaled seq=23536171, emitted seq=23536173
Jul 17 00:24:47 n0va kernel: amdgpu 0000:09:00.0:  Process ACBlackFlag.exe pid 123758 thread vkd3d_queue pid 124326
Jul 17 00:24:47 n0va kernel: amdgpu 0000:09:00.0: Starting gfx_0.0.0 ring reset
Jul 17 00:24:49 n0va kernel: amdgpu 0000:09:00.0: Ring gfx_0.0.0 reset failed
Jul 17 00:24:49 n0va kernel: amdgpu 0000:09:00.0: GPU reset begin!. Source:  1
Jul 17 00:24:49 n0va kernel: amdgpu 0000:09:00.0: [drm] *ERROR* Failed to initialize parser -125!
Jul 17 00:24:51 n0va kernel: amdgpu 0000:09:00.0: MES(1) failed to respond to msg=REMOVE_QUEUE
Jul 17 00:24:51 n0va kernel: amdgpu 0000:09:00.0: failed to unmap legacy queue
Jul 17 00:24:52 n0va kernel: [drm:gfx_v12_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
Jul 17 00:24:52 n0va kernel: amdgpu 0000:09:00.0: MODE1 reset
Jul 17 00:24:52 n0va kernel: amdgpu 0000:09:00.0: GPU mode1 reset
Jul 17 00:24:52 n0va kernel: amdgpu 0000:09:00.0: GPU smu mode1 reset
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: GPU reset succeeded, trying to resume
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: [drm] PCIE GART of 512M enabled (table at 0x0000008000000000).
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: VRAM is lost due to GPU reset!
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: PSP is resuming...
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: RAP: optional rap ta ucode is not available
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: SECUREDISPLAY: optional securedisplay ta ucode is not available
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: SMU is resuming...
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: SMU is resumed successfully!
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: program CP_MES_CNTL : 0x4000000
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: program CP_MES_CNTL : 0xc000000
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: [drm] DMUB hardware initialized: version=0x0A000C00
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring sdma0 uses VM inv eng 9 on hub 0
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring sdma1 uses VM inv eng 10 on hub 0
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring vcn_unified_0 uses VM inv eng 0 on hub 8
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: ring jpeg_dec uses VM inv eng 1 on hub 8
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: GPU reset(1) succeeded!
Jul 17 00:24:53 n0va kernel: amdgpu 0000:09:00.0: [drm] device wedged, but no recovery needed
Jul 17 00:24:54 n0va systemd-coredump[163269]: Process 8210 (Xorg) of user 1000 terminated abnormally with signal 6/ABRT, processing...
Jul 17 00:24:54 n0va systemd[1]: Created slice Slice /system/systemd-coredump.
Jul 17 00:24:54 n0va systemd[1]: Started Process Core Dump (PID 163269/UID 0).
Jul 17 00:24:54 n0va systemd-coredump[163270]: [🡕] Process 8210 (Xorg) of user 1000 dumped core.
KKishi85 2026-07-25 github

Replying to https://github.com/ValveSoftware/Proton/issues/9958#issuecomment-4936716638

Can confirm PROTON_NO_NTSYNC=1 fixes issues with Ubisoft Connect Launcher on Proton 11 (also fixes other Ubisoft games like AC Odyssey, Immortals: Fenix Rising).

Update: When using a Proton 10 version that supports NTsync via PROTON_USE_NTSYNC=1 the Ubisoft Connect Launcher is also working as expected 100% of the time with NTsync enabled hinting to this being a regression issue in Proton 11

Proton versions

Launch options

Launch lines

Upstream links