DXGIGetDebugInterface can't be located

[99z]

Environment

• Windows 11 IoT Enterprise LTSC
• Practice tool v1.7.1
• ER 1.12.3

Unfortunately, following the steps in CONTRIBUTING.md, I'm unable to get a log file to be generated. The following is the output from the console on launch:

←[2m2024-07-19T01:52:00.237004Z←[0m ←[34mDEBUG←[0m main ThreadId(01) ←[2mjdsd_er_practice_tool←[0m←[2m:←[0m ←[2mpractice-tool/src/bin/jdsd_er_practice_tool.rs←[0m←[2m:←[0m←[2m25:←[0m Looking for ELDEN RING process...
←[2m2024-07-19T01:52:00.240203Z←[0m ←[34mDEBUG←[0m main ThreadId(01) ←[2mjdsd_er_practice_tool←[0m←[2m:←[0m ←[2mpractice-tool/src/bin/jdsd_er_practice_tool.rs←[0m←[2m:←[0m←[2m44:←[0m Searching for tool DLL...
←[2m2024-07-19T01:52:00.240357Z←[0m ←[34mDEBUG←[0m main ThreadId(01) ←[2mjdsd_er_practice_tool←[0m←[2m:←[0m ←[2mpractice-tool/src/bin/jdsd_er_practice_tool.rs←[0m←[2m:←[0m←[2m47:←[0m Checking EAC...
←[2m2024-07-19T01:52:00.240458Z←[0m ←[34mDEBUG←[0m main ThreadId(01) ←[2mlibjdsd_er_practice_tool::util←[0m←[2m:←[0m ←[2mpractice-tool/src/util.rs←[0m←[2m:←[0m←[2m102:←[0m Steam AppID path: "C:\\Program Files (x86)\\Steam\\steamapps\\common\\ELDEN RING\\Game\\steam_appid.txt" exists? true
←[2m2024-07-19T01:52:00.240525Z←[0m ←[34mDEBUG←[0m main ThreadId(01) ←[2mjdsd_er_practice_tool←[0m←[2m:←[0m ←[2mpractice-tool/src/bin/jdsd_er_practice_tool.rs←[0m←[2m:←[0m←[2m52:←[0m Injecting "\\\\?\\C:\\Users\\nsm\\Downloads\\jdsd_er_practice_tool\\jdsd_er_practice_tool.dll"...
←[2m2024-07-19T01:52:00.240648Z←[0m ←[34mDEBUG←[0m main ThreadId(01) ←[2mhudhook::inject←[0m←[2m:←[0m ←[2m/home/andrea/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hudhook-0.7.0/src/inject.rs←[0m←[2m:←[0m←[2m68:←[0m WriteProcessMemory: written 520 bytes, returned Ok(())

I imagine this is related to #21 . I wouldn't be surprised if it has something to do with Windows IoT LTSC missing some features.

I'm happy to help debug further however I can 👍

[veeenu]

It looks like you are missing the DXGI debug layer which you need to enable in order to get logs (see TROUBLESHOOTING.md). Not sure if Win 11 IoT has that though, in that case you can just disable dxgi_debug in the config. It will make things a bit harder to debug but in my experience DirectX Is almost never the cause of issues with the tool, so that should be fine.

[99z]

Windows 11 IoT does not include graphics diagnostics tools. Following the steps in TROUBLESHOOTING.md to install and enable them results in the same error and no log file.

Interestingly, the DXGI error occurs when the DXGI debug layer is disabled using dxcpl and with dxgi_debug set to false in the config 🤔

[veeenu]

Mmm, this might run deeper (veeenu/hudhook). Chances are some changes in windows-rs now lead to unconditionally trying to load that function instead of only on demand.

I won't be able to address this for a few days unfortunately, but this is relatively high priority.

[veeenu]

I have looked into this. That function gets linked into the DLL so the error most likely shows up regardless of whether it is used or not.

Unfortunately we need to link it for diagnostic purposes, so it's unlikely we can find a workaround for this on the side of code. I assume Windows 11 IoT does not support dxgi1_3, at least not by its default install, but I can't exclude it could be installed in some way (though I won't be able to help with that unfortunately) and at that point the error might go away.

I am not familiar with Windows 11 IoT Enterprise. What drove the choice for you to use it compared to other Windows editions?

[99z]

This page has a table summarizing the differences: https://massgrave.dev/windows_ltsc_links

IoT is stripped down in a number of ways so it's certainly plausible it lacks the required headers.

[veeenu]

Unfortunately I couldn't find anything definitive related to DXGI. I think it's more of it having an older version (missing dxgi1_3 features) rather than not having DXGI altogether -- otherwise Elden Ring wouldn't work at all. And it's not so much about headers as the code comes already compiled, but just the version of dxgi.dll that gets shipped. I find this very likely due to the version being LTSC and so favoring older, more stable things over "newer" things that may be untested.

Sadly I don't have a good model of how to deal with this that doesn't entail massive fragile checks and/or releases with separate features (e.g. the dxgi debug disabled) that would also affect hudhook in a negative way in terms of maintainability and scope creep.

Let's keep this issue open a while, see if we can find a good solution; but atm I don't think there is anything actionable that offers a compromise compatible with the tool's core objectives.