VS2017 and missing “api-ms-win-core-rtlsupport-l1-2-0.dll” on Win7/XP

Question

After porting some of my programs from VS2015 to VS2017 in noticed that the binaries no longer run on Windows 7 or Windows XP - even though they have been compiled with v141_xp toolset. The program fails to start with missing DLL api-ms-win-core-rtlsupport-l1-2-0.dll (note the 2 ).

I'm well aware that those api-ms-win-* DLL's belong to the UCRT and that, starting with VS2015, I have to redistribute the UCRT DLL's from the Windows 10 SDK (to be found at Redist\\ucrt\\DLLs in the Windows 10 SDK directory), along with my application - just redistributing the vcruntime140.dll and msvcp140.dll is not sufficient. But there is only api-ms-win-core-rtlsupport-l1-1-0.dll in my Windows SDK directory, but not api-ms-win-core-rtlsupport-l1-2-0.dll . I just downloaded and re-installed the latest Windows SDK (10.0.15063), just to be sure. Still the DLL in question is absent!

I also tried installing the VS2017 Redistributable package on the Windows 7 (or XP) machine via VC_redist.x86.exe - latest version downloaded from Visual Studio web-site (14.11.25325). Obviously that copies the api-ms-win-* DLL's into the "System32" directory. But, again, only api-ms-win-core-rtlsupport-l1-1-0.dll , but not api-ms-win-core-rtlsupport-l1-2-0.dll . App still won't start.

---

[EDIT]

This of course only applies if I link against the DLL runtime ( /MD ). If I link against the "static" runtime ( /MT ) I get a binary that has no DLL dependencies on UCRT and runs fine on Windows 7 and XP.

---

[EDIT #2]

Please refer to my other post (including EDIT) for the resolution of the mess:
https://stackoverflow.com/a/45773325/1766377

Answer 1

Okay, this is quite interesting: Just now my VS2017 found a new update. Apparently that updated my VS2017 from v15.2 to v15.3.1 . The runtime libraries were updated as well, it seems!

There are now two directories, VC\\Redist\\MSVC\\14.11.25325 and VC\\Redist\\MSVC\\14.11.25415 , inside my VS2017 install directory. The vcruntime140.dll exists in both directories. But the newer version (25415, right) has quite different dependencies, compared to the older one (25325, left):

Only the "new" version has dependencies that are missing on Windows 7. So, I should be fine going with the "old" version. But it means I'm locked to the "old" version. Is this normal / intended ???

(BTW: Both DLL versions from VS2017 v15.3.1 are newer than the one I originally took from v15.2 )

---

[EDIT]

So, it was just brought to my attention that there is a subtle difference between the VC\\Redist\\MSVC\\14.11.25325 and VC\\Redist\\MSVC\\14.11.25415 directories: The 25415 directory has all DLL files inside another sub-folder called onecore , the other one doesn't. Apparently, this means that the "newer" DLL versions (the one with onecore sub-folder) are not supposed to be redistributed with normal Desktop applications; they are strictly for the "OneCore" Mobile/IoT platform.

Conclusion:
M$ did a great job to design the Redist directory structure as confusing as possible . Putting the version numbers of the "normal" and the "onecore" redistributables on the same level of the directory hierarchy (rather than having separate onecore and desktop directories on that level) indicates that those directories represent different versions of the same thing - which isn't the case at all :-/

Do *not* redistribute any */onecore/* DLL's with normal Desktop applications!

Answer 2

In the property pages for the project, try changing the Windows SDK version from 10.0.15063.0 to 10.0.10240.0. I think that will fix it, provided that the older SDK is installed on your build machine. Something else to try is to change the platform toolset to v140_xp. VS 2017 then builds with the VS 2015 tool chain, provided that VS 2015 is installed.

My personal preference is to avoid any 'DLL hell' by linking with the static runtime, although this won't work if an exe and a dll need to share a heap and incurs some space penalty if you are building several binaries (I just have two).