I also have similar issues with some anime game but let me check if our situation is really similar:

• Is removing dxvk-cache file before launching the game fix the problem temporarily?
• When using older dxvk version release (for example: DXVK 2.2), is it has the exact same error/problem?

Is removing dxvk-cache file before launching the game fix the problem temporarily?

YES, It did fix the problem once, I've also tried with deleting nvidia shader cache, I tried once and it worked.

When using older dxvk version release (for example: DXVK 2.2), is it has the exact same error/problem?

I don't remember if I've tried, but I will try using DXVK 2.2 and report back in less than one hour

UPDATE:
Downgrading DXVK to 2.2 fixed the issue with ReShade and the weird error on GE-WINE-8.x
The issue seems to be "we're trying to load 32-bit stuff for 64-bit stuff" or something similar

IMPORTANT UPDATE: I'm bisecting the issue, once I'm done I'll announce it

Bisecting the problem leads to this:

428ca9416d60cf7025ae97da88f44eabc2ec0aa2 is the first bad commit
commit 428ca9416d60cf7025ae97da88f44eabc2ec0aa2
Author: Joshua Ashton <[email protected]>
Date:   Wed Aug 23 14:50:42 2023 +0100

    [d3d11] Implement synchronization on keyed mutexes
    
    Co-authored-by: Paul Gofman <[email protected]>

 src/d3d11/d3d11_context_imm.h   |  1 +
 src/d3d11/d3d11_initializer.cpp | 12 ++++++++++++
 src/d3d11/d3d11_initializer.h   |  2 ++
 src/d3d11/d3d11_resource.cpp    | 36 +++++++++++++++++++++++++++++++-----
 src/d3d11/d3d11_resource.h      |  2 ++
 5 files changed, 48 insertions(+), 5 deletions(-)

On WINE-TKG-7.20 the problem doesn't occur, why? m i s t e r y

Wow good work, I never investigate this far into the issue, it seems that we have the exact same issue (although on different game).. I just switched back to DXVK 2.2, continue using ReShade with REST plugin and pretend this never happen, hehe.. Thanks for reporting this, I wish the issue will be resolved soon :pray:

Wow good work, I never investigate this far into the issue, it seems that we have the exact same issue (although on different game).. I just switched back to DXVK 2.2, continue using ReShade with REST plugin and pretend this never happen, hehe.. Thanks for reporting this, I wish the issue will be resolved soon 🙏

Latest REST versions don't work though... plus, going back to DXVK-2.2 is simply not so acceptable, the drawbacks compared to v2.3 are simply too many.

@Stereo-3D Here, use this build, it has been built before that commit, so you'll gain the latency improvements of post v2.2 and pre v2.3

Can you retest with latest master? A reshade crash regression was indeed found and fixed since 2.3.
You can download a pre compiled build here https://github.com/doitsujin/dxvk/actions/runs/6240574600

Can you retest with latest master? A reshade crash regression was indeed found and fixed since 2.3. You can download a pre compiled build here https://github.com/doitsujin/dxvk/actions/runs/6240574600

That is a nice surprise! It works... for now.
Let's see if it didn't break other stuff, testing now, will update the comment.

Also @Stereo-3D (sorry for another tag) try this!

Can you retest with latest master? A reshade crash regression was indeed found and fixed since 2.3. You can download a pre compiled build here https://github.com/doitsujin/dxvk/actions/runs/6240574600

With DXVK-2.3 I also had this weird error with Call of Duty: Black Ops 3
Assertion failed: !status && "vkDestroyBufferView", file ../dlls/winevulkan/loader_thunks.c, line 3226

something that with DXVK-2.2 wasn't happening, I'll try to bisect that too.

EDIT: sometimes it happens, sometimes not, sometimes with 2.2 sometimes with every version

Can you retest with latest master? A reshade crash regression was indeed found and fixed since 2.3. You can download a pre compiled build here https://github.com/doitsujin/dxvk/actions/runs/6240574600

Yes, I can confirm that this pre compiled build is working with ReShade 5.9.2 (+REST addon) loaded on anime game I'm playing! Thank you very much @Blisto91 and @gabriele2000 :pray:

Yes, I can confirm that this pre compiled build is working with ReShade 5.9.2 (+REST addon) loaded on anime game I'm playing! Thank you very much @Blisto91 and @gabriele2000 🙏

Hell yeah!

Good to hear.

@gabriele2000 Please open news issues for anything else you think is a dxvk bug.

Good to hear.

@gabriele2000 Please open news issues for anything else you think is a dxvk bug.

Of course, I will reference the relevant comment in a new issue once I succesfully bisect the relevant commit... plus I have to be certain that it's a DXVK bug since sometimes it's a random error.

@gabriele2000 Was all good for this particular issue?

@gabriele2000 Was all good for this particular issue?

Upon further testing I'm not seeing any problem since when I claimed that the problem was fixed.

IMPORTANT
I want to write something that will be useful to everyone.

Since Reshade 5.9 something tells me that the particular error message Assertion failed: !csw->is32, file /home/builder/build_wine/wine/dlls/dbghelp/cpu_x86_64.c, line 650 is spitted thanks to a quirk of ReShade.

I've reason to believe this, since (it happens even with the commit that fixes the issue) if a game can't load ReShade properly without using a native d3d_compiler47 dll it generates the same error.

You can observe this weird behaviour like this:

• The game will open and it will immediately close itself without any error or message
• The game will open, ReShade will load and while loading the shaders the game will close itself

As you might know, ReShade needed the native dll (in the past, before WINE-8.10 or something, now I guess it doesn't anymore but there are games that don't accept that, causing the issue.

Basically ReShade (or the hooking process for that particular game?) does something "illegal" and triggers a check in WINE, introduced years ago.
If it happens, place a native d3d_compiler47.dll next to the game's executable then:

• winecfg
• In the library tab, add a custom rule for d3d_compiler47.dll as native, builtin
• Click on "OK" or "Apply" then "OK"

@K0bin Close it as "fixed", I forgot to close the issue since it's fixed for good starting from that commit.