[Global Injector] Crashes on install/update | Bootstrapping D3D9, DXGI, OpenGL simultaneously?

[Aemony]

OS: Windows 7
Redirected documents folder? No.
SKIM64 tested? Both 0.5.10 and 0.5.13
Special K version: both from base SKIM64 -> 0.7.46 and from 0.7.46 -> 0.7.59
Logs and stuff: https://drive.google.com/open?id=0B5BL9xsRx0j7cS01MEpKYzJodDg

I'm experiencing a bunch of various issues when trying to install the global injector, both from 0.5.10 and 0.5.13. What usually happens is that when I first run a Steam game to finalize the global injector installation the update dialog to Special K (0.7.46) also shows up. Regardless of what I do here, usually the game crashes within 2-4 seconds and canceling the auto-update.

The global injector installation is then left in a semi-broken state, forcing me to manually remove the My Mods folder and rerun the installation from SKIM64.exe.

Is the auto update dialog supposed to pause the rendering of the game? Because that doesn't seem to happen as the game continues loading in the background.

I was lucky twice (out of 10 attempts or so) and managed to update the global injector installation to 0.7.46, but a similar issue occurs whenever I launch games and it prompts for an update to 0.7.59 (since I migrated to the Testing branch).

When I did a cursory glance through the various SpecialK.log files I noticed that all of them seemingly tries to install hooks into DirectX 9, 11 and OpenGL. One of the times it worked SpecialK only hooked OpenGL and DirectX 11.

I noticed that DisplayFusion did install a hook on occasion, but I've sinced closed that application and the issue still persists.

[Kaldaien]

There is API auto-detection in the global injector. This feature doesn't work correctly when you have third-party software such as GeForce Experience loading every graphics DLL on your system.

I have work-arounds for GeForce Experience, but any other software that tries the same thing is going to confuse my auto-detect. Likewise, I can confuse their auto-detect and it's a really nasty feedback loop. If you know the graphics API, you can go into Documents\My Mods\SpecialK\Profiles\<game.exe>\SpecialK.ini and turn off hooks for all the other graphics APIs.

It would be helpful if I knew what was triggering the false detections on your system though; probably video capture.

[Aemony]

I'll take a thorough look through the system when I get home. I'll keep you posted.

[Kaldaien]

I released 0.7.62 with Render API selection on the compatibility menu.

Press and Hold Ctrl + Shift when you start a game, you can force Special K to use a particular render API if you know what the game uses.

[Aemony]

I'm going to perform a complete reinstallation of Steam to be on the safe side. I noticed that I'm getting different results whether I launch the game through Steam or the game executable directly.

Or, well, the results are only identical between launches with the game HunieCam Studio. I thought Legend of Korra was identical as well, but further testing proved me wrong.

HC Studio through Steam: https://i.imgur.com/3SHP7Sm.png
HC Studio through executable: https://i.imgur.com/inPkHWD.png

The game doesn't work either way, but through Steam Special K and the game crashes completely, while through the executable Special K's update promp fully seems to work and is stable, but the game has frozen in the background and must be killed through Task Manager.

I still can't find any other stuff injecting into the games, but I'm going to uninstall a bunch of shit and see if something changes.

Edit: Steam reinstalled completely and a ton of applications uninstalled. I've at most around 40 processes running on this machine now when Steam runs.

[Aemony]

I managed to update to v0.7.62, but now I get an error message when I launch various things (vc_redist.x64.exe, Steam, games through their executables).

The program can't start because D3DCOMPILER_47.dll is missing from your computer. Try reinstalling the program to fix this problem.

The game doesn't come up when I launch games through the Steam client, but then Special K doesn't seem to be loaded at all and the logs don't get updated.

I've tried installing the Windows 7 Platform Update ("not applicable to your system") and the KB2533623 ("already installed") but seems that both were already installed.

Got any ideas?

[Aemony]

I had to remove the global injector again because the D3DCOMPILER_47.dll warning came up constantly during every application launch.

How do I confirm that the global injector have been fully uninstalled? SKIM64 reported that it was installed but the DLL files remained, and the prompt regarding the DLL file came up when I launched another application so my guess is that there's broken remains of Special K wherever you add them.

That might also explain the other issue? If Windows tried injecting Special K twice or something like that into every application due to remains from previous failed installations, maybe?

[Kaldaien]

Should only be the 32-bit version that does that. Somehow the dependency was set wrong. I'll re-link SpecialK32.dll in a few minutes and re-upload 0.7.63

----

Should be fixed now.


As for uninstalling, it's not possible to remove those DLLs usually because they will be in-use by other programs. SKIM64 removes the Windows registry keys that causes them to be loaded, so that's just as good.

Programs that are currently using them will continue to do so without having the DLL pulled out from underneath them, but no new programs you launch will use them.

[Aemony]

0.7.63 solved the warning that came up with previous versions.

That said, I believe some of the steps I've taken to try and fix the original issue have caused some other issues as well, mostly related to the D3DCOMPILER_47.dll file. Remember that this is one a Windows 7 x64 machine, and between each version tested I completely removed the content of Documents\My Mods\SpecialK and extracted the new files to that same folder. I'm having trouble finding a good 64 bit game to try out with, so I'm primarily testing using 32 bit games.

---

0.7.25 - (or whatever version SKIM 0.5.13 installs) - Works without any issues (Special K OSD shows up in games and/or prompts me to update). This behaviour seems the same up to and including 0.7.31.

0.7.34 - Special K doesn't show up in-game any longer, and the D3DCOMPILER_47.dll warning comes up when launching 32 bit applications. No future version of Special K works, but 0.7.63 solves the warning at least.

If I add the d3dcompiler_47.dll and d3dcsx_47.dll files under System32 and SysWOW64 per your instructions on the Release page on GitHub then Special K starts working again, albeit only for a couple of versions, up to and incuding 0.7.45.

0.7.46 - Special K stops working again, regardless of the D3D files. I can confirm that Special K is at least being loaded since I get the D3D warning prompt if I don't have those files in the sytem folders, but Special K doesn't prompt me to update nor does its OSD show up in-game. This behaviour seems the same up to and including 0.7.63.

0.7.46[github.com] only seems to have changed how you're storing the mod configs? And some minor debug things as well I guess. Anyway, both %UserProfile%\Documents and FOLDERID_Documents points to the same location according to Powershell.

PS C:\Users\Kenny> echo $env:UserProfile\Documents
C:\Users\Kenny\Documents
PS C:\Users\Kenny> [Environment]::GetFolderPath("MyDocuments")
C:\Users\Kenny\Documents

[Kaldaien]

Well, you're on Windows 7. The software cannot in a million years load CEGUI without first installing KB2533623

      // This is only guaranteed to be supported on Windows 8, but Win7 and Vista
      //   do support it if a certain Windows Update (KB2533623) is installed.
      typedef DLL_DIRECTORY_COOKIE (WINAPI *AddDllDirectory_pfn)          (_In_ PCWSTR               NewDirectory);
      typedef BOOL                 (WINAPI *RemoveDllDirectory_pfn)       (_In_ DLL_DIRECTORY_COOKIE Cookie);
      typedef BOOL                 (WINAPI *SetDefaultDllDirectories_pfn) (_In_ DWORD                DirectoryFlags);

[Aemony]

It doesn't seem to be installed (not listed under Installed Updates) but neither the x86 nor the x64 package of the update wants to be installed...

---------------------------
Windows Update Standalone Installer
---------------------------
The update is not applicable to your computer.

It's possible that Microsoft have bundled it into the monthly rollup they're nowadays releasing, but I'll take a futher look into it in 9 hours or so after work.

[Aemony]

I don't think I'm lacking actually lacking KB2533623, as the reason it doesn't show up or want to be installed is probably because it was slipstreamed into the installation source I used when installing this Windows 7.

I assume as such since you added the dependency on KB2533623 all the way back in january[github.com] with v0.7.27, if I understand the Release page correctly. As I mentioned v0.7.45 works just fine[i.imgur.com] if I add the two D3D files to System32 and SysWOW64, but v0.7.46 does not. The only difference between these versions are how you query for the Documents folder[i.imgur.com] and some additional debug stuff.

I'll probably throw up an additional Windows 7 in a virtual machine just to do some further testing on a completely blank slate to ensure that nothing post-install or third-party stuff conflicts for some reason.

[Aemony]

Yup, Windows 7 support for the global injector seems broken post v0.7.46, and I've confirmed it occurs on all version up to and including 0.7.64. I have so far only confirmed it on Dx9 and OpenGL (I think) but it's possible all APIs are affected. To note is that manually installing the injector in each game folder still works, it's just the global injector that doesn't seem to work.

v0.7.45[i.imgur.com] (global injector)
v0.7.46[i.imgur.com] (global injector)
v0.7.46[i.imgur.com] (game-specific injector)

This is on a completely fresh Windows 7 x64 SP1 install which have only gotten the following changes:

* KB2533623 installed
* KB2670838 installed (aka Platform Update)
* Visual C++ 2015 Redistributable Update 3 (both x64 and x86)
* DirectX End-User Runtime Web Installer
* manually installed the d3dcompiler_47.dll and d3dcsx_47.dll files in the system folders (fixes the global injector for v0.7.34 and future versions)

To summarize, the global injector have the following bugs in Windows 7 x64:

* d3dcompiler_47.dll and d3dcsx_47.dll doesn't get automatically downloaded or whatever you do with them. So if these don't already exist in the system files (manually installed) the GUI won't show up at all. Issue seems to have begun in v0.7.34.

* GUI won't show up at all in v0.7.46 or after.

These issues only affects the global injector and not game-specific injections! Game-specific injectors work just fine without these bugs up to and including v0.7.64

I am actually questioning whether or not it's even worth it to bother with Windows 7 for the global injector at this point. The lack of an automated install of d3dcompiler_47.dll and d3dcsx_47.dll ensures that even using the automated installer will result in a non-working Special K install if the user updates post v0.7.34, and the user folder bug that was introduced in v0.7.46 breaks it even more. However everything works just fine when using manual game-specific injections... :|

[Kaldaien]

I see, I'll look through the Win32 API stuff I use for anything that's incompatible with Windows 7.

Microsoft doesn't make this easy on developers, they have a tool that's supposed to validate your software against a bunch of rules for different Windows versions -- it never works :)

FRAPS and Windows 7 are my two biggest enemies while developing this stuff. Both are obsolete in my book, but I'll try to maintain Windows 7 support for at least a little while longer.

[Aemony]

I had completely forgotten about this thread... Anyway, an update for lurkers if anyone stumbles over this thread now or in the future:

This issue have been resolved.

Special K v0.8.1 (and later) comes with a new injection method that solves the incompatiblility issue with Windows 7 as well as Windows 10 Creators Update.

If you recently have had the old incompatible version installed I highly recommend you manually confirm that it is completely uninstalled before installing the latest version.

Do this by running regedit and check the AppInit_DLLs registry entries. Both entries should be empty (or at least not include the SpecialK DLL files) for the old version of the global injector to be fully uninstalled.
* HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
* HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows