api-ms-win-core-rtlsupport-l1-2-0 missing on a windows 7 deployment
-
I have successfully built and deployed my Qt app on several Windows 10 systems, but not on Windows 7. On startup, it gives an error api-ms-win-core-rtlsupport-I1-2-0.dll missing. On at least one the systems I tried, I did find a file with a I1-1-0 suffix, but this doesn't seem to help. My build machine is Windows 10.
-
I have successfully built and deployed my Qt app on several Windows 10 systems, but not on Windows 7. On startup, it gives an error api-ms-win-core-rtlsupport-I1-2-0.dll missing. On at least one the systems I tried, I did find a file with a I1-1-0 suffix, but this doesn't seem to help. My build machine is Windows 10.
-
Many thanks. I have added the redistributables as suggested in two ways: I could add the 2013 and earlier in windows 7, but could not add the 2015 as it indicated it needed later Windows. In the InstallShield redistributable list, I added "Visual C++ 14.0" OpenMP, DebugCRT, and CRT, in various flavors of ARM, x86, and x64. I seem to have changed the symptom, but not much, as it now claims that api-ms-win-crt-runtime-I1-1-0.dll is missing, and I cannot find that file on my build machine either. Along the way, I have upgraded from InstallShield Limited Edition to Express, and with that there is a dependency scanner. When I use that, it does list a number of files with api-ms-win prefixes as missing, but cannot add them, because I cannot seem to find them on my build machine or find them from other sources. Perhaps they are in the redistrivutable packages, but this is not obvious, and so I am still stuck.
Any further ideas?
Andy -
Hi, the functions inside api-ms-win-core-rtlsupport-I1-2-0.dll are all structured exception functions, and some of them do not work on Windows 7 (they need Windows 8 or Windows 10).
But that dll is just a dummy dll (same for all the other api-ms-win-xxx .dlls) that Windows never loads. They are just an indirection layer, Windows knows that the functions requested actually can be found in ntdll.dll.
So maybe if you can relink/rebuild your app for Windows 7, that dependency on api-ms-win-core-rtlsupport-l1-2-0.dll can be removed.
-
Hi, the functions inside api-ms-win-core-rtlsupport-I1-2-0.dll are all structured exception functions, and some of them do not work on Windows 7 (they need Windows 8 or Windows 10).
But that dll is just a dummy dll (same for all the other api-ms-win-xxx .dlls) that Windows never loads. They are just an indirection layer, Windows knows that the functions requested actually can be found in ntdll.dll.
So maybe if you can relink/rebuild your app for Windows 7, that dependency on api-ms-win-core-rtlsupport-l1-2-0.dll can be removed.
@hskoglund Thank you!
I am sorry to ask what seems such a simple question, but how do I relink/rebuild for Windows 7? My latent assumption has been that the exe is the same for 10 as it is for 7, but this may be naive and incorrect. This assumption has driven me to find the right package contents rather than to change the exe, but your mention of relinking/reloading would of course be very important if I am assuming the right thing. A corollary to the question is, can a Windows 7 load be built using a Windows 10 build machine, that is, can I make the two target-specific exeutables both from a common build machine or would I need to come up with a configuration of visual studio on a windows 7 build machine? ...or, confirm that in fact a common exe is possible...
-
Solved:
and boy did I learn a lot on the way...
The basic issue was not win7 as such; it was a more complete understanding of the vagaries of dependencies. The solution was relatively simple, to include the right version of the msvc DLLs. But of course that makes it sound trivial, which it was not. I used dependencywalker but this is as misleading as it is helpful, because the dependencies shift considerably with changes to the top level objects and it took me quite a while to understand that. Also, the difference between 32 and 64 bit objects isn't obvious; sometimes they are in one folder, other times in another from computer to computer. Next was the need for multiple levels of msvc DLLs rather than just one, but not the same objects, some the same and some different. Last but not least was a confusion over InstallShield redistributables and merges, and even that if one isn't careful, the testing is made more opaque because of InstallShield reconfigurations when one is tryign to get the file lists right by specifically inclduign or excluding files on a given target.My advice to the forum ends up similar to what most searches on related topics say: you have to know about your actual program dependencies, don't get thrown off the track by the api-ms-win files because they don't have real content, and watch out for both direct and indirect references to 32- vs. 64-bit modules. Watch the file sizes, since the names are the same.
Many thanks to the forum.
