I tested it on plain WINE and it also crashes there. However, it's not clear to me if the issue is simply with DXVK due to the err:sync:RtlpWaitForCriticalSection errors.

Distribution: Arch Linux
GPU: RADV RENOIR
Driver: radv 23.2.1
Wine version: 9.0rc1-1
DXVK version: 2.3
Gamescope: 3.13.17-1

d3d9 log: https://gist.github.com/R1kaB3rN/04d32de41e3d0efbb3c96692e48ddbaf
wine log: https://gist.github.com/R1kaB3rN/6489e391b86812f8411e7f7bfe441359

API trace (WineD3D): https://drive.proton.me/urls/W9BR0T4YT4#8icfHo4jdprN

I had a look at the trace Blisto shared. The game seems to be doing incredibly dubious things.

It creates a texture, uses it for a bit (meaning it has a non-zero refcount), calls IDirect3DTexture9::Release() at some point and gets a 0 refcount, meaning dxvk legitimately destroys the object... but then the game calls IDirect3DTexture9::Release() again and somehow expects that to work... but of course dereferencing a dangling pointer will make it crash *surprised pikachu face*.

No idea how this would work on native or WineD3D. Also no idea on how to fix this sort of thing.

P.S.: Not releasing the texture in question when a 0 refcount is hit gets me to the menu, but is obviously not a resonable solution.

@Blisto91 by chance, have you also confirmed this on Proton 7.0-6? I'll try to list an API trace and some logs later, but using that on the Steam Deck I wasn't experiencing crashes anymore when opening the backlog or progressing through the script

It does not seem to crash with Proton 7.0-6 no. :eyes:
Will check on Windows with dxvk here later thanks.

Thanks. Yeah, Proton 7.0-6 uses the legacy DXVK (1.10.3) and even using that with plain WINE there will still be crashes, so I don't think this bug is necessarily caused by DXVK. Below I listed the API traces of the crash after opening the backlog on 1.10.3 and WineD3D

Distribution: Arch Linux
GPU: RADV RENOIR
Driver: radv 23.2.1
Wine version: 9.0rc2
DXVK version: 1.10.3
Gamescope: 3.13.17-1
API traces: https://drive.proton.me/urls/2QSJQJ5YXW#8tp1S6vIKy8v

To note, there appears to be a discrepancy between the graphics requirements and the Vulkan translation. It advertises DirectX11 as the minimum and recommended system setting, but when using DXVK, the D3D9 to Vulkan translation occurs instead of D3D11. I don't know if D3D11 is used on Windows for this game, but if it is then this could possibly be a DXVK bug? Though this is probably just a mistake from the publisher/devs

[...] so I don't think this bug is necessarily caused by DXVK.

@R1kaB3rN The issue is the game relies on "use after free" to work properly. Apparently this somehow works on native (meaning Windows)...

As I mentioned before, a clean fix will be rather hard to implement. If you want I can share a build that works, but what it basically does is to never release textures, which is like allowing a racoon to rummage through your trash for any of the older stuff you've thrown out by never emptying your bin - meaning not exactly a good idea. I expect the game will eventually run out of address space in this scenario, but it does indeed get it working.

It advertises DirectX11 as the minimum and recommended system setting, but when using DXVK, the D3D9 to Vulkan translation occurs instead of D3D11. I don't know if D3D11 is used on Windows for this game, but if it is then this could possibly be a DXVK bug? Though this is probably just a mistake from the publisher/devs

Game requirements (expressed in terms of DirectX version) and the graphics API (Direct3D version) that they use are very commonly different. There's no direct correlation between the two. If dxvk reports D3D9, that is because the game code is creating a D3D9 device. The behavior will be the same regardless of OS, because again, it's game code that we're talking about here.

Yes, it relies on properly supporting use after free, not just with extra d3d resource release (which crashes first usually) but with some other game memory objects game allocates and frees directly too. The issue with texture extra release can be confirmed on Windows by enabling heap debug flag FLG_HEAP_ENABLE_FREE_CHECK in NtGlobalFlag for game exe (e. g., using gflags.exe program from Windows SDK), with that enabled it crashes in the same place on Windows.

This should hopefully work better in Proton Experimental [bleeding-edge] which got a bit of use after free support improvements.

Not a dxvk issue afterall. Thanks gofman!