The diagnosis reads the log properly, the library is remembered, and a 4K display gets its whole window
Three things that stopped people outright
An install that could not finish anywhere with a comma for a decimal
point. dlss5-feed.cfg is written by the add-on as well as by this tool, and
the add-on is C++: in a process whose locale uses a comma - PCSX2 sets one
through Qt - it writes mv_scale_x=1,000. Reading that back raised out of
the middle of the install and nothing was installed at all (#69). Numbers
read from that file survive whichever locale wrote them.
Every video download failed. ffmpeg comes from BtbN's builds, and their
"latest release" is now a dated autobuild whose file names carry the build
hash, while the stable name lives on the release tagged latest. Looking in
the wrong one found nothing: "ffmpeg build not found on GitHub" (#75). It
asks for the tag, falls back to matching the name, and then to the
download URL itself.
An install cut off halfway looked like a broken game. A download that
stops - a reset connection (#74) - leaves the folder set up part of the way,
and the installer records that. The diagnosis never read it, so the parts
that never arrived were reported as missing files, as if an antivirus had
taken them. It says the install did not finish instead of reporting the parts that
never arrived as missing files.
Red Dead Redemption 2, twice
Both reports (#66, #70) were the same thing: the game was set to Vulkan and
the optiscaler route hooks a Direct3D path, so OptiScaler's overlay kept
asking to "select FSR or DLSS or XeSS as upscaler" with DLSS already on. The
diagnosis says so, and names the two ways out.
A third OptiScaler build
The optiscaler build dropdown has a third entry: wilsjo2's fork, which
runs the neural pass before super resolution rather than after it, over one
to three passes (#76). That is the ordering the neural-upstream route gets on
the ReShade side, on the OptiScaler side. It is never chosen automatically,
and the dropdown labels it "not run here": one game measured by its author,
and no test of it on this side - reports welcome.
Every fork publishes its releases the same way, so one reader handles all
of them.
Adding it turned up an older fault of its own: with two forks' archives in
the cache, what will happen? listed whichever one the file pattern found
first, and described the wrong package. It names the archive belonging to
the build that is actually selected - still without making a single request,
which is what that screen promises.
A d3d9.dll import is the weakest evidence in a file
Grand Theft Auto V was read as a DirectX 9 game and sent to a route that has
nothing for it (#77). GTA5.exe does import d3d9.dll - engines keep that
import for a launcher, a video player or an old settings dialog long after
they stopped drawing with it, and Red Dead Redemption 2 (#12) and Call of
Juarez (#31) are the same shape.
The reason it kept happening is that only half the file was being read:
executables also carry a delay-load import table, which is where an
engine records a library it loads on demand, and that table was never
parsed. It is parsed, and a d3d9 import is treated as the weakest evidence
in the file - the DLSS files in the folder, a D3D12 Agility SDK, a
delay-loaded d3d11 or d3d12, and finally the names inside the executable all
get asked first. A bare dxgi.dll delay-load does not count: a real DirectX 9
game can use DXGI on its own just to enumerate displays.
Checked against a real library before shipping: every game's renderer was
recorded, the change made, and the two compared - nothing moved that was not
meant to.
"The game has not been started" while DXVK's log sat in the folder
DXVK writes its own log next to the game the moment it loads. Call of
Juarez: Gunslinger had one, and no ReShade.log, and was told three times
that the game had never been started and might not be running on Vulkan
(#31). Both were wrong, and the folder said so. A DXVK log written since the
install is read as what it is: the game ran, DXVK loaded, and ReShade is not
in the chain - a different problem with a different fix.
A report that contradicted itself
Starfield's ReShade.log is 400 KB and a report carries the last 250 KB, so
the lines recording which add-ons loaded fell off the front while every line
those add-ons wrote was still there. The report said "ReShade loaded no
add-ons" directly above "34621 heartbeats" from the add-on that had loaded
(#51). A line an add-on wrote is proof enough that it loaded.
The report knows whose crash it is
"did it work?" was answering with whichever rule matched first, and on the
1.7.2 reports that was often the wrong component.
A crash in the game was called a feeder bug. The feeder's crash handler
catches every crash in the process - its own and the game's alike - and
prints the module chain that led to it. That chain is read. Detroit:
Become Human crashed with DetroitBecomeHuman.exe <- KERNEL32.DLL <- ntdll.dll, no add-on in it anywhere, and the report said "a feeder bug;
try another feeder build" (#63). It says the game crashed instead, and a crash
that lands inside the Direct3D 12 or NGX runtime is named as that instead
of either.
"Working." on a game that produced nothing. Far Cry 5's feed delivered
one frame and then faulted inside D3D12Core.dll on every evaluate - the
driver 616.64 fault - and because the fault was split over two log lines in
the feeder's beta.5 build, the pattern missed it and one delivered frame
was enough to print "Working." (#68, #37). The chain alone is the signature,
and where add-on 4.55 is already installed the answer is the one that
helps: roll the driver back to 616.56.
An add-on from a run three days ago, reported as loaded. ReShade never
truncates ReShade.log, so a report can carry several launches at once. Only
the last one is read. Two builds of one add-on inside a single launch
is a real fault - two files fighting over the same frame - and that is said
outright.
Something else pacing the frames. When the feed counts more presents
than frames it fed, something is presenting frames the feed never made -
NVIDIA Smooth Motion is the usual one. It is named, with where to turn it
off.
The neural-upstream route says what it did
For three releases this route answered with "This route leaves no frame log
of its own" and a hint to open the overlay (#39, #51, #64), while the add-on
was writing every step of its run into ReShade.log. That is read: whether neural rendering
is switched on, whether the game's DLSS call was ever hooked, what NGX
answered when the feature was created, whether the snippet fallback was
used, how many frames have gone through and whether they came out valid,
and whether the game hands over an exposure buffer - the answer to "the
picture only gets darker".
It also catches the failure behind S.T.A.L.K.E.R. 2 hanging on a save
(#64): the add-on's log stops at a device re-creation, which is the game
throwing its D3D12 device away and building a new one. The report names it
and says what to do instead of asking for another log.
The library is remembered between launches
Finding the library is the slowest thing this tool does, and it happened
again on every launch even when nothing had changed. It is written to
%LOCALAPPDATA%\dlss5-autopilot\library.json and read back on the next
one, so the list is there at once. Rescan still does the full walk.
A cached game is only trusted while it is unchanged: a game the store has
updated, or one with a file dropped into its folder, is inspected again on
the spot, and a cache written by a different release of this tool is not
used at all - what this tool believes about a game is exactly what changes
between releases. Thanks to josema0890 (#67), who sent a working proof of
concept with the request.
A 4K display gets the whole window
The first round of #40 scaled the fonts and the row heights. The report
that came back - "the text is readable now, but the log box is one and a
half lines" - was three more things, none of them a font:
- The window asked for more than the screen. Scaled with everything
else, it opened 2490 pixels tall on a display 2160 tall, and the minimum
size kept it there: the bottom of every page was off the screen and
dragging could not bring it back. - Row counts are not pixels. Fourteen rows of log at 300 % is three
times the pixels it was at 100 %. Text and list heights hold roughly their
size instead of their row count. - Nothing could scroll. The settings on the install page are taller
than a 300 % screen on their own, and the architecture page - the first
page anyone sees - was 448 pixels past the bottom of the window at 200 %.
Both scroll, and only when they have to: at 100 % there is no
scrollbar and the layout is unchanged. The install page divides what the
window has between the settings and the log, so neither can take it all,
and the game list's detail line no longer gets squeezed to one pixel.