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

10
votes

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.

enter image description here

enter image description here

[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

2
c++visual-studiowindows-7visual-studio-2017windows-xp
best is to create a extra project configuration for XP, install an older VS version in a VM and compile the xp project file via the older VS version. – magicandre1981
I have already chosen the v141_xp toolset in my project configuration - which exists specifically to target Windows XP. In VS2015, using the v140_xp toolset works great to create binaries for Windows XP - as long as I redistribute vcruntime140.dll and msvcp140.dll as well as the api-ms-win-* UCRT DLL's from the Windows 10 SDK. But it appears that VS2017 now is linking against a newer UCRT version, for which the required redistributables are not (yet) available - neither in the Windows 10 SDK nor via the VS2017 redistributable installer - which seems like a bug to me... – MuldeR
I understand your issue. that's why use an older VS version to compile the XP exe – magicandre1981
That I can use on older VS version (e.g. VS2015) to produce a binary that will work on Windows 7 or Windows XP is not the point here. The point is that - to the best of my knowledge - VS2017 is supposed to produce binaries that work on Windows 7 (and also on Windows XP when v141'_xp toolset is selected), but apparently fails to do so! Or, more specifically, it appears that M$ missed to provide the right redistributable DLL's for those platforms in its current Windows SDK. – MuldeR

2 Answers

7
votes

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):

enter image description here

 
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!

0
votes

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).