One caveat worth noting is that the official Win32 documentation states to never call LoadLibrary from within DllMain due to some potential scenarios in which the loaded library performs thread management such that a deadlock occurs due to DllMain already holding a lock on the OS's module loader.

I'm no DirectX expert, but from what I tell dinput8.dll in particular does not seem to be one of such modules as this seems to be pretty common practice when writing a wrapper for it. SpecialK does this, and even portions of the Win32 implementation violate Microsoft's own guidance; however, ultimately it's unclear how to judge exactly when it's safe to do this or not given that the docs simply say "never".

If you want to play it extra safe, we can switch to a RAII approach and only load the real DLL once any of the 6 passthrough functions are called for the first time, avoiding the use of LoadLibrary in DllMain entirely. I'm happy to make that change.

I've called LoadLibrary from DllMain in the past, and usually it causes no issues. However I did have a very obscure bug that I found was caused by calling LoadLibrary in this way (at this point I don't remember what the problem was). Afterwards I've never put LoadLibrary inside DllMain. To be fair, this may or may not be an issue for dinput8 specifically, but I reasoned that simply hardcoding the exports to the original DLL on the C drive was better than having this potential issue, given that 99.99% of people will have C as their system drive.

Of course there's also the approach of calling LoadLibrary on the new thread and dynamically loading from the system drive (which is my usual go-to), but this can theoretically lead to a race condition - unless you add some kind of synchronization between the DLL calls and the loading of the original DLL (more on that later).

I've also already attempted the RAII approach that you mention - calling LoadLibrary and/or GetProcAddress only when one of the functions are called - but this approach caused problems specifically with Elden Ring as for some reason the Epic Online Services DLL makes GetProcAddress point to the wrong function (only after about 5-10 seconds after the game was booted). I did not look too deep into this issue to see if it could be worked around and I dropped the approach.

Currently I am working on a DLL proxying solution that I can use for all of my projects that will provide a simple approach (atleast from the usage side) to DLL proxying no matter which DLL you are proxying. It will dynamically load the original DLL from the system drive without any race conditions or any LoadLibrary calls in DllMain. The proxying will consist of a single call in DllMain and require as little setup as possible to be used in new projects.

Thank you for your interest and time, however I will let the proxying stay the way it is for now until I am able to implement my new solution. Feel free to come with more ideas or comments if you have any.

I've also already attempted the RAII approach that you mention - calling LoadLibrary and/or GetProcAddress only when one of the functions are called - but this approach caused problems specifically with Elden Ring as for some reason the Epic Online Services DLL makes GetProcAddress point to the wrong function (only after about 5-10 seconds after the game was booted). I did not look too deep into this issue to see if it could be worked around and I dropped the approach.

Wow, that's quite strange!

Although in the long run using your general purpose solution is obviously best, I'm fine moving the loading of dinput8 to LoaderThread and handling synchronizing in the interim. Just let me know if I should bother.