I went through and tested each of the development release build artifacts, and this is the first build artifact release that has the crashing behavior, as far as I can tell.
I haven't seen any issues so far, the attached trace crashes on replay even with older DXVK builds so that's probably unrelated too. The (working) Gw2 trace that I have also works fine and I've tested a bunch of games with the render pass work.
Would probably save everyone some time to do a proper bisect rather than guessing.
@doitsujin I don't know if you saw my changes to the original post, but I've pretty much confirmed it's not the unsynchronized render passes. The last working build dev build is from January 23rd, and the first broken build is this one from January 26th.
So, unless I'm mistaken, fe277ae0f9ce39d1b143ed34e5d2ea7bc614d306 is the guilty commit.
I just really don't see why that commit would break anything, unless either our CI builds are just broken or something is going on with that wine build
Do you have the FPS limiter enabled or something? If not then we're not even calling any of those functions.
Do you have the FPS limiter enabled or something? If not then we're not even calling any of those functions.
Actually yes, I do. I have dxgi.maxFrameRate = 163 enabled in my dxvk.conf. I'll test without that and see if that gets rid of the crashing.
Update: Nope, even with the frame limiting disabled I still got the crash. In fact, removing my dxvk.conf entirely still has the crash.
Please test https://github.com/doitsujin/dxvk/actions/runs/21409869182 this build to actually confirm whether or not it is that particular commit.
FWIW I've found a 100% consistent way to trigger the bug. In GW2 you open the game map and then scroll back or forwards on the scroll wheel to zoom in and out. Upon doing so will instantly trigger the crash.
Well all I can say is that doing that works fine on my end, at least using current dxvk master on Proton Experimental.
Not reproducing so far either with Nvidia dGPU + Proton or Nvidia and amd iGPU in upstream Wine 11.1
Did the build with the revert actually end up working?
@doitsujin, sorry for the delay. I tested with that reverted build you shared and have the same issue.
Likewise, on a whim I decided to try with my previous Wine 11.0 (Kronek) runner instead of 11.1 (Kronek) and with the reverted build I do not have the crash, and it also doesn't trigger the crash with the known broken version.
So, it seems that specifically with the upgrade from Wine 11.0 -> 11.1, something breaks specifically with this build, but not prior builds.
Looking at the changelog for Wine 11.1, I see this line:
[#58143](https://bugs.winehq.org/show_bug.cgi?id=58143) Variable refresh rate does not work properly with winewayland.
I am using both Wine-Wayland as well as variable refresh rate, so perhaps my issue is related to either of these technologies. To test this, I returned to Wine 11.1 + the known broken build, but this time disabling Wine-Wayland, and now I don't have the crash.
So based on what I'm seeing this is the pattern:
Was there anything done to DXVK after January 23rd that would interact with Wayland?
We haven't really touched anything related to WSI in months, no.
I can give winewayland a try, we basically never test against it since it's not really enabled anywhere by default and frankly just not on our radar.
That's fair, and I wouldn't expect you to cover every possible scenario. I didn't know WineWayland was even enabled tbh, but it looks like a recent update to Bottles toggled it on by default. So, at the very least, Bottles is enabling it by default.
It's easy enough for me to just disable WineWayland, so no worries there. It's just super interesting to me that the breakage only happens on newer commits.
Likewise, this might be the first of many bug reports with regard to WineWayland and Wine >=11.1, so hopefully this at least just gets it on your radar that this might be an issue to look into.
I reported this to upstream Wine here, as this seems like something that might need to be fixed on their end.
Does this also happen with upstream Wine for you? That seems fine here.
I am reproducing a wine-wayland crash everytime i use the scroll wheel with Kronek 11.1 (not 11.0). But that is unrelated to dxvk as it also happens without.
Edit: Note that i don't have VRR
FWIW I also haven't run into any issues with wine 11.1 running winewayland.
The problem has been fixed in Wine 11.2. I fixed the problem on my side by updating Wayland libraries in the build environment that i use to compile my Wine builds. And given that using the mouse wheel scroll was causing crashes with listener function for opcode 9 of wl_pointer is NULL errors, i think it's been fixed in upstream too (https://github.com/wine-mirror/wine/commit/6ea70e7d7c5710df325cd66abb30efb15c7be87b).
Thanks for the update.
@Kron4ek @doitsujin Just tested with 11.2 and I can confirm that the issue is fixed. Thanks for looking into this!
proton experimentalx1 2026-01
Description
I just wanted to put this issue on your radar. I have been testing the development releases of DXVK, and development releases newer than the January 23rd dev release cause the game that I am testing with, Guild Wars 2 to hard crash a few seconds/minutes after starting the game. Granted, I have not done a complete git bisect to locate the exact commit, but I can consistently replicate the bug with the latest development release newer than Janurary 23rd, with early releases being fine.
The best way that I have found to trigger the bug so are is to open the player's map. Usually in the first 2-3 map openings the game will insta-crash.
The crash is not a "hang", rather the game instantly just dies and closes fully with no attempt at recovery. It is much more akin to an alt+F4 than crashes I've seen in the past where the screen goes white/blank and hangs.
Software information
Guild Wars 2
Arch Linux (updated to Jan 27, 2026)
System information
Apitrace file(s)
Log files
Gw2-64_dxgi.log
Gw2-64_d3d11.log