Since you decided to visit this page, chances are you’re either looking for api-ms-win-core-rtlsupport-l1-1-0.dll file, or a way to fix the “api-ms-win-core-rtlsupport-l1-1-0.dll is missing” error. Look through the information below, which explains how to resolve your issue. On this page, you can download the api-ms-win-core-rtlsupport-l1-1-0.dll file as well.
После переноса некоторых из моих программ из VS2015 на VS2017 в заметил, что двоичные файлы больше не работают в Windows 7 или Windows XP, даже если они были скомпилированы с помощью набора инструментов v141_xp . Программа не запускается с отсутствующей DLL api-ms-win-core-rtlsupport-l1-2-0.dll (обратите внимание на 2).
Мне хорошо известно, что эти api-ms-win-* DLL принадлежат UCRT и что, начиная с VS2015, мне приходится перераспределять DLL UCRT из SDK Windows 10 (можно найти в RedistucrtDLLs в Windows 10 SDK каталог) вместе с моим приложением — достаточно просто перераспределить vcruntime140.dll и msvcp140.dll не. Но в моем каталоге Windows SDK есть только api-ms-win-core-rtlsupport-l1-1-0.dll , но не api-ms-win-core-rtlsupport-l1-2-0.dll . Я просто загрузил и переустановил последнюю версию Windows SDK (10.0.15063), чтобы быть уверенным. Тем не менее DLL, о которой идет речь, отсутствует!
Я также попытался установить пакет распространяемого VS2017 на компьютере под управлением Windows 7 (или XP) через VC_redist.x86.exe — последнюю версию, загруженную с веб-сайта Visual Studio (14.11.25325). Очевидно, что копирует DLL api-ms-win-* в каталог "System32". Но опять же, только api-ms-win-core-rtlsupport-l1-1-0.dll , но не api-ms-win-core-rtlsupport-l1-2-0.dll . Приложение все еще не запускается: -/
Спасибо и с наилучшими пожеланиями,
MuldeR
[EDIT]
Это, конечно, применимо только в том случае, если я ссылаюсь на время выполнения DLL ( /MD ). Если я ссылаюсь на "статическую" среду выполнения ( /MT ), я получаю двоичный файл, который имеет не DLL-зависимости на UCRT и отлично работает в Windows 7 и XP.
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 RedistucrtDLLs 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 :-/
Thanks and best regards,
MuldeR
[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 Answers 2
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, VCRedistMSVC14.11.25325 and VCRedistMSVC14.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 VCRedistMSVC14.11.25325 and VCRedistMSVC14.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 :-/