Issues with Special K and Windows 10 20H2

Hey guys, don’t know if anyone has already tested this but I updated my machine to the october update of Windows 10 (20H2) and after that Special K services aren’t running anymore and even trying to start them manually in SKIF doesn’t work, might it be related to the way the injection of DLL’s is done?

Have you tried moving specialK folder to C drive and launch as admin?

Already tried running as admin (nothing changed), my SpecialK folder is already at the C drive.

Oh boy… and so it begins…

19042 and 19041 are on the same build (.572 or .608 for the release preview update two days ago.) I’m on 20H2 myself since earlier this year all it is is a small enablement package activating the new features.

It should be compatible unless Defender / Threat Detection is blocking them (It gets updated pretty frequently.) fully uninstalling and re-installing SKIF and it’s batch files could also help in case these got unregistered somehow.

If it’s a clean install for 20H2 / 19042.508 + the newest cumulative (.572 or .608 if on the RP ring.) you’d likely also want to add the DirectX 2010 July runtime and the Visual C++ 2019 runtimes.

I use this for the VC++ stuff.

Source links for the runtimes are here also if one would rather do it through these.

https://download.visualstudio.microsoft.com/download/pr/7651ff4e-1916-49be-9e7d-e92ebc183adf/B1A32C71A6B7D5978904FB223763263EA5A7EB23B2C44A0D60E90D234AD99178/VC_redist.x64.exe
https://download.visualstudio.microsoft.com/download/pr/8ecb9800-52fd-432d-83ee-d6e037e96cc2/50A3E92ADE4C2D8F310A2812D46322459104039B9DEADBD7FDD483B5C697C0C8/VC_redist.x86.exe

The batch files SKIF uses registers and sets a few things I think the current download is the full 0.11.0.50 build maybe .51 and then Kaldaien has been posting builds here and there of 32 and 64 bit 0.11.1.0 experimental .dll files but if used to replace the current packaged full distribution of SpecialK they should still work through SKIF.

Probably just needs an injection cache address flush, that happens every time there’s an OS update.

Normally it happens automatically because a game either crashes at startup from old cached memory addresses in the config file, or the cached addresses do nothing and SK never draws a frame (it purges its cache if a game never draws a frame).

1 Like

Thought it was automatic but yeah several of the D3D .dll files got updated with the .540 updates.

c:\windows\system32\dxgi.dll=DirectX Graphics Infrastructure 10.0.19041.546
C:\Windows\SYSTEM32\d3d9.dll=Direct3D 9 Runtime 10.0.19041.546 (WinBuild.160101.0800)
c:\windows\system32\d3d11.dll=Direct3D 11 Runtime 10.0.19041.546 (WinBuild.160101.0800)

Looks something like that plus the cache for the various functions.

IDXGIFactory_CreateSwapChain=c:\windows\system32\dxgi.dll?5ef10
IDXGIFactory2_CreateSwapChainForCoreWindow=c:\windows\system32\dxgi.dll?5f620
IDXGIFactory2_CreateSwapChainForHwnd=c:\windows\system32\dxgi.dll?5f7f0

But yeah I thought that was pruned and redone when a older/invalid address or version is found.
I use a prepared config file though so it can just write in the updated info when a cumulative or a build update for Windows 10 happens.

So it’s not something I encounter often although on a miss SpecialK generally just removes the info and updates it on it’s own, good information to know though I’ve not seen it act up over it but that doesn’t mean it couldn’t happen. :slight_smile:

EDIT: Microsoft is updating the OS quite actively now too although the release preview update didn’t touch on the D3D files this time, quite a few fixes.

To say nothing of the earlier now fully released updates for 19041/19042.xxx :smiley:
(Nice to see despite how much focus is on 21H1 and the full new Windows 10 build other than this shared cumulative code and enablement pack just so there can be a 20H2 build.)

That new build is also going quite actively but it’s not really ready for normal usage just yet, few more months though and it should stabilize into bug fixing mode and readying for full launch for May I guess.

Updating the Visual C++ packages seems to have done the trick (injection started normally now), thanks for the help.