jlrouzies-fr/DLSS5-Feeder v0.14.0-beta.2

0.14.0-beta.2 — catching the driver fault is what killed the game

on GitHub

You probably do not need to install this by hand

Install-DLSS5Feeder.ps1 does the whole install from one command — ReShade, this feeder, LumeniteFX, your chosen neural consumer, both NVIDIA runtimes, dgVoodoo2 for Direct3D 8/9, and the .ini files with the techniques already enabled in the right order. Drop it next to the game's .exe, right-click ▸ Open in Terminal, and run:

powershell.exe -ExecutionPolicy Bypass -File .\Install-DLSS5Feeder.ps1

Existing files are merged and backed up, never replaced, and it finishes with a verification pass. See AUTOMATIC_INSTALLATION_AVAILABLE.txt in the assets below for the full details and the unattended-run switches.

0.14.0-beta.1 added the diagnostics that name a C++ crash. Within hours a reporter's log came back with the answer they were built to find — and the second half of it is our bug, not the driver's.

32-bit games: take BOTH dlss5-feed.addon32 and host64\dlss5-feed-host64.exe. The protocol is unchanged (still v7), but both halves changed this release.

The crash, and why catching the fault caused it

Two lines from a real driver-616.86 run, five milliseconds apart:

[host] evaluate raised 0xC0000005 (reading address FFFFFFFFFFFFFFFF) in D3D12Core.dll
[host] evaluate fault stack, by module (innermost first):
       D3D12Core.dll <- nvngx_dlssnr.dll <- _nvngx.dll <- renodx-dlss5.addon64 <- dlss5-feed-host64.exe

### CRASH RECORDED ###  exception 0xE06D7363
    (C++ exception: std::system_error -- "resource deadlock would occur")
    KERNELBASE.dll <- renodx-dlss5.addon64 <- dxgi.dll <- dlss5-feed-host64.exe

The first is the driver fault diagnosed yesterday. The second is ours.

Everything here is built /EHsc, and so is the neural consumer. Under /EHsc, an SEH __except unwinds the frames between the fault and the handler without running C++ destructors in them — that is exactly what separates /EHsc from /EHa. So every std::lock_guard the consumer took on the way in is stepped over. Its mutexes are never released, and it is left locked by a thread that has already walked away. The next call into it — milliseconds later, from ReShade's own present — hits std::mutex::lock() on a mutex the thread already owns. That throws resource deadlock would occur, nobody catches it, and the process dies.

The fault was survivable. The recovery was not. Catching the driver's access violation and carrying on is what turned "no neural pass this frame" into a crash to desktop.

beta.2 stops calling into the consumer once a fault has come back up through its own code, and says so once:

[host] not calling evaluate again: the neural consumer's own code was on the faulting
stack, so its internal locks were skipped by the unwind and are still held. Calling back
in throws "resource deadlock would occur" and takes the process with it.

The game keeps rendering normally. You get no neural pass and a log that explains itself, instead of a crash. Both the 64-bit add-on and the helper do this.

The check is deliberately narrow — only when the consumer's own module is on the faulting stack. A fault inside NGX with nothing of the consumer's between it and us leaves none of its locks held, so the existing retry-and-reinitialise path, which has recovered real cases, is untouched.

Driver 616.86 behaves exactly like 616.64, so the warning beta.1 added already covers it.

Device-removal crashes now have breadcrumbs — #57

DRED (D3D12's Device Removed Extended Data) has to be switched on before the device is created. It was, on the Vulkan and OpenGL paths. It was never switched on for the Direct3D 11 path — the one most games take.

That was not academic. #57 is a device removed with DXGI_ERROR_DEVICE_HUNG after 9800 frames of Batman: Arkham Knight on exactly that path, and the only thing its log could say about it was:

[feed] DRED: GetAutoBreadcrumbsOutput1 failed 0x887A0004

Breadcrumbs were never armed, so the one report that needed the trail is the one report that has none. Fixed.

This arms breadcrumbs for our device; a hang caused by the game's own device or by the consumer will still show nothing from us. But "our command list was, or was not, the last thing running" is exactly the bit that was missing.

A ReShade without add-on support is no longer accepted — #53

ReShade ships two builds. They carry the same version number and the same product name, and only one can load add-ons. Nothing in the installer or the verifier could tell them apart — both only ever asked "is it new enough?" — so an existing plain install was kept and reported as fine while dlss5-feed was never loaded at all. No error, no log line, nothing.

This bites hardest on Vulkan, where the layer is machine-wide (C:\ProgramData\ReShade\ReShade64.dll) and therefore shared by every Vulkan game on the PC: one plain install done for some other game years ago is silently reused for this one. That is what #53 was reporting, and the reporter only found it by reinstalling ReShade by hand.

Both scripts now read the DLL's export table. ReShade's own add-on API locates ReShade in a process by looking for the exports ReShadeRegisterAddon and ReShadeUnregisterAddon (reshade.hpp), so a build without them cannot load an add-on — by construction, not by inference.

• Install-DLSS5Feeder.ps1 replaces a plain build automatically, local or machine-wide.
• Verify-DLSS5Feeder.ps1 fails on it and says which build you have.
• The README's Vulkan steps now say to tick "Enable loading of add-ons".

Telling NVIDIA's NGX runtime from a repack — #47, #50

NVIDIA's own nvngx_dlssnr.dll and ShortFuse's .SF repack both report file version 310.8.0.0 and both stamp the same changelist into OriginalFilename (CL 38718415), so neither field separates them. #50's reporter pointed out that what does differ is the stated FileVersion string — 310,8,0,0 from NVIDIA, 310.8.SF.0 from the repack — and that is a different field from the version quad, which was the only one ever read.

Now both are read, and the stated string is printed whenever it disagrees with the quad:

[host] NGX runtime nvngx_dlssnr.dll: 310.8.0.0 (stated FileVersion "310.8.SF.0"),
       NVIDIA DLSSNR | ..., build CL 38718415

Nothing is asserted about which build is better. #47 turns on comparing machines, and a log carrying all three fields settles it without anyone guessing.

Also

• dgVoodoo2 on a Direct3D 8 game was never detected as already installed, because the check looked only for D3D9.dll while a D3D8 game gets D3D8.dll. Every run re-downloaded the zip and re-extracted dgVoodoo.conf over your edited one (backed up first, but nobody expects to need the backup). Found while checking #56 — which turned out not to be a bug: dgVoodoo2 is D3D9.dll, and dgVoodooCpl.exe sitting beside it is proof the wrapper landed, not evidence it did not.
• The README no longer claims 32-bit Vulkan (DXVK) has no confirmed game; it has had one since #15.

Check dlss5-feed.log line 1 to confirm which build you are running — it will say dlss5-feed 0.14.0-beta.2, or dlss5-feed32 0.14.0-beta.2 on 32-bit.