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

0.14.0-beta.1 — the crash log now names the thrower, and it names driver 616.64

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.

This build is about one report and one answer: "the new NVIDIA driver broke the 32-bit path" (#54). It is reproduced, measured and named here — and it is not a fault in this project. But until now nothing in the logs could have told you that, so most of this release is the diagnostics that now can.

32-bit games: take BOTH dlss5-feed.addon32 and host64\dlss5-feed-host64.exe from this zip. The helper protocol is unchanged (still v7), but the helper is where almost all of this release's work is — an old one tells you nothing new.

Driver 616.64: what is actually wrong

With renodx-dlss5.addon64 v4.6 or v4.7 as the neural consumer, every DLSS evaluate faults inside NVIDIA's own NGX runtime on driver 616.64. The helper survives it — it has always caught that fault — so the game keeps rendering normally and simply never receives a neural frame. That is why it reads as "the host starts but the add-on says it's not working".

Measured with host64\dlss5-feed-host64.exe --test on an RTX 5090, the same files throughout. Driver 616.56 passes every row:

The fault, now printed in host64\dlss5-feed-host.log:

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

Our call goes into the consumer's NGX detour, on into the driver's _nvngx.dll and nvngx_dlssnr.dll, and then dereferences an uninitialised pointer inside D3D12Core.dll — the address differs from run to run (-1 above, 0xC on the next). Nothing on this side is in that chain past the call itself, and the same call on the same files succeeds three other ways.

616.64 also changed what NGX says about the feature that path creates: the requirements query for feature 18 answered NotImplemented (0xBAD00012) on 616.56 and answers supported on 616.64. So the driver moved, and the v4.6+ engine is what does not survive the move.

Three fixes, any one of them:

• use Deep Fried Chicken as the neural consumer, or
• use a classic-engine renodx-dlss5 build (v4.55 and "latest" both pass), or
• roll the driver back to 616.56.

This build says all of that in the helper's log, up front, the moment it sees the combination — rather than leaving you with a helper that runs, logs nothing alarming and delivers nothing.

Run host64\dlss5-feed-host64.exe --test to check your own combination. It takes about fifteen seconds and needs no game.

Crash logs now name the culprit

A C++ exception (0xE06D7363) is raised from inside KERNELBASE, so every one of them used to log identically:

### CRASH RECORDED ###  exception 0xE06D7363 at 00007FFB... in KERNELBASE.dll;
this add-on was last doing: starting up

That names the messenger and never the thrower — and it is exactly the line the original report arrived with. It could not distinguish ReShade from the neural consumer from the NVIDIA driver, and the breadcrumb only ever moves inside the feed path, so "starting up" meant nothing either.

Both add-ons and the helper now read the MSVC throw record, which carries the thrown object and the type it can be caught as:

### CRASH RECORDED ###  exception 0xE06D7363
(C++ exception: std::runtime_error -- "the message it was thrown with") at ...

and on the 64-bit side unwind the stack and name the modules it came through:

crash stack, by module (innermost first):
KERNELBASE.dll <- VCRUNTIME140.dll <- renodx-dlss5.addon64 <- dxgi.dll

Verified against real throws in both architectures — std::runtime_error, std::bad_alloc, a bespoke std::exception subclass, a plain struct, an int, a string literal, throw new, and a rethrow. Access violations gained the same treatment inside the helper, which is how the driver fault above was pinned in the first place.

If you have an open crash report against this project, re-running it on this build is worth more than anything else you can send.

dlss5-feed.addon64 in host64\ is now refused

host64\ is a 64-bit ReShade install, so a copy of the 64-bit game add-on dropped in there does load — into the helper that is already serving your 32-bit game. It then opens a second NGX session on a second private device and detours nvngx over the neural consumer's own hooks, in the one process where none of that has ever been tested. The give-away in the log was the add-on complaining that DLSS5_Feed.fx was missing from a folder never meant to have it — which is what the original report was showing, underneath the crash.

It now recognises the helper and stays inert, saying why. The 32-bit add-on reports the stray file in the game's own log too, Install-DLSS5Feeder.ps1 offers to disable it, and Verify-DLSS5Feeder.ps1 fails on it.

host64\ takes dlss5-feed-host64.exe, a 64-bit ReShade dxgi.dll, the neural consumer and the nvngx_* runtimes. Nothing else. The game's own folder keeps dlss5-feed.addon32.

Also in this build

• The helper records only the first crash, like both add-ons already did. A GPU fault takes out every thread inside the driver at once, and they used to race for the same dump file — which is how the one crash worth a dump ended up with none.
• A repeating NGX fault is logged twice in full and then summarised, instead of writing the same two lines sixty times a second over the part of the log that explains what happened.
• Carried over from the 0.14.0 branch: the helper window is tall and narrow by default and resizable from the cast panel (width/height sliders, a real swapchain resize), so it sits as a slim column beside the game rather than a wide overlay.

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