3.x Regression: patched `Split/Second` + ReShade 6.8.0 Generic Depth crash

dxvkopen windowsprobably not our bug

doitsujin/dxvk#5889 · opened 2026-09-08 by IlexisTheMadcat · updated 2026-09-08 · 10 comments · github

IIlexisTheMadcat 2026-09-08 github

Split/Second has a consistently reproducible GPU hang when returning from a race to the main menu with DXVK 3.x and ReShade's Generic Depth add-on enabled.

Repro:

Start game ->
Skip intro movies (mash enter) ->
Main menu ->
Quick play (arrow right, enter) ->
Race (enter) ->
Downtown Central (enter) ->
Select car and start (enter) ->
Skip mode description (enter)->
Skip map name (enter) ->
Scene loads ->
Pause (enter) ->
Quit (arrow down x2) ->
loading ->
crash.

Windows recorded LiveKernelEvent 141 (VIDEO_ENGINE_TIMEOUT_DETECTED)
after the DXVK 3.x hang. WER stop code: 0x141

The crash is reproducible with DXVK 3.x and with ReShade Generic Depth enabled (required).
Disabling Generic Depth avoids the crash.

DXVK 2.7.1 does not face this issue.

Software information

Game: Split/Second (exe version 1.0.0.1, product version 1.3.8.0)
DXVK file: /x32/d3d9.dll
Mods:

Holly/Patch (dinput8.dll, zipped)
ReShade 6.8.0 with Vulkan with the Generic Depth add-on enabled.

Note: Holly/Patch is used for borderless/window and timing fixes; this race-to-menu crash is separate from its known video device Reset problem, where the game could freeze if backgrounded.

System information

GPU: Nvidia RTX 3080
Driver: 616.64
DXVK versions: 3.0, 3.0.1, 3.0.2, 3.1

Apitrace files

Not provided yet. I am not sure whether a D3D9 apitrace would preserve the ReShade Generic Depth interaction required to reproduce the hang. I can try to provide one if it would still be useful.

Log files

With DXVK_DEBUG on, using DXVK 3.0.2: SplitSecond_d3d9.log

err:   DXVK: Hang detected:
err:   Device fault 0:
err:   - Memory address: 0x200020000 - 0x20002ffff (type 6)
err:   - Instruction address: 0x20002fd30 - 0x20002fd31 (type 6)
err:   - Memory address: 0x2cf8b4000 (type 1)
err:   Failed to open SplitSecond_device_fault.bin

ReShade 6.8.0, terminates just before crash: ReShade.log

A depth-stencil resource was destroyed while still in use.

Let me know if more information is needed. I gathered the information I could for the moment. This diagnosis was guided by GPT 5.6 Sol.

Ddoitsujin maintainer 2026-09-08 github

I don't think Vulkan Reshade is expected to work? DXVK cannot know when Reshade accesses its resources, and Reshade has no way to keep them alive on its own. If we recreate a depth-stencil image for literally any reason then stuff will blow up, yes.

BBlisto91 maintainer 2026-09-08 github

Why do you think the two linked issues are related?

Also try with the d3d9 version of reshade

Edit: was typing this as doitsujin posted a comment 😛

IIlexisTheMadcat 2026-09-08 github

The related issues seemed relevant because of similar GPU hang scenarios, which was similar to my issue.

I didn't want to use d3d9 because I wanted more advanced processing, e.g. more complex color spaces for an HDR enhancement. It is a very cinematic game after all.

I could also just not use depth shaders, but that takes away quite a few interesting mods.

BBlisto91 maintainer 2026-09-08 github

I meant chain the d3d9 version of reshade with dxvk. Unless you mean those features aren't supported there.
It would be a more proper way to use reshade with dxvk and is how it would be done on Linux (no env var needed though)

IIlexisTheMadcat 2026-09-08 github

The point was to expand what reshade options I could use. Stacking dxvk on top of it would defeat the purpose, as the game already runs just fine on my machine. I just wanted to improve it.

BBlisto91 maintainer 2026-09-08 github

Right. I am not familiar enough with reshade so didn't know of the difference in options available depending on API.

IIlexisTheMadcat 2026-09-08 github

I don't think Vulkan Reshade is expected to work? DXVK cannot know when Reshade accesses its resources, and Reshade has no way to keep them alive on its own. If we recreate a depth-stencil image for literally any reason then stuff will blow up, yes.

It'd be unfortunate to know that there's no fix for DXVK's d3d9 to vulkan translator with depth stencils. Maybe it's something up with ReShade's handling of those depth stencils it was referring to?

BBlisto91 maintainer 2026-09-08 github

I gather that capturing depth is very hard to do correctly in Vulkan and so we are inclined to lean towards something in Reshade being not right.

The Vulkan version of Reshade also won't work on Linux (with dxvk games afaik?), or is at least less straight forward, so this is in practice more of a Windows specific issue.
Which would make it more annoying to debug and less prioritized.

Ddoitsujin maintainer 2026-09-08 github

What you could try is a dxvk.conf with dxvk.enableMemoryDefrag = False, but there are other scenarios where we recreate depth-stencil images internally outside of memory defragmentation.

But yeah, like Blisto said, it's basically impossible for something like Reshade to extend the lifetime of a resource. One thing they could do is copy the depth image to an internal resource that they manage themselves at the end of every command list that writes the depth image in question, but that's going to cause a performance hit.

IIlexisTheMadcat 2026-09-08 github

Unfortunately that config option didn't resolve the issue. I've referenced the issue in the ReShade support server and I was told it'd been forwarded, to whom I don't know.

However, I did just find that the Holly/Patch is likely the culprit. I'll dive deeper in the meantime.