none
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer

    Question

  • We are in the process of transferring our solution to Visual Studio 2015 and are experiencing some problems with our C++ assemblies.

    In the projects we have changed the PlatformTarget from v120_xp to v140_xp and replaced the Merge Modules included in our MSI:
        MM_Microsoft_VC120_MFC_x86.msm
        MM_Microsoft_VC120_CRT_x86.msm
    with
        MM_Microsoft_VC140_MFC_x86.msm
        MM_Microsoft_VC140_CRT_x86.msm

    After installation on Windows 7 which runs smooth, we get an error dialog when launching our application (the exe is one of the C++ Projects). Title is "StandAloneShell.exe - System Error" and the message is "The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem."

    I can see that others have fixed this issue by applying all updates from Microsoft Update and then installing the Visual C++ Redistributable for Visual Studio 2015 (https://www.smartftp.com/support/kb/the-program-cant-start-because-api-ms-win-crt-runtime-l1-1-0dll-is-missing-f2702.html), but this is not really an option for me to do on our customer computers around the world.

    Similar problem: https://social.msdn.microsoft.com/Forums/en-US/90a4f857-6008-44c9-bbb2-8c968569b8b2/program-cant-start-because-apimswincrtruntimel110dll-is-missing-from-computer?forum=vssetup

    By looking inside the Merge Module using Orca we can see that the file in question has a condition so that it is only installed on Window XP (501) and Windows Server 2003 (502) but it seems to also be required on other versions of Windows.

    Have anyone found a real solution for this problem?


    Tore Østergaard
    Oticon A/S, Denmark

    Wednesday, September 2, 2015 8:26 AM

Answers

  • Did you notice the section of the blog post that said:

    There will not be a merge module for the Universal CRT. If you currently use the CRT merge modules and still want to deploy the Visual C++ libraries centrally, we recommend that you move to the above mentioned Windows Update package or to the VCRedist. Alternatively, you may choose to link statically to the Universal CRT and the Visual C++ libraries.

    Thursday, September 10, 2015 3:56 PM

All replies

  • Perhaps you could use a setup bootstrapper to check for and install the prerequisite VC redistributable
    Wednesday, September 2, 2015 10:05 AM
  • Hi RLWA32

    That might ultimately be the solution but the Merge Modules is the better solution because we in some cases need to release our product as a single MSI.


    Tore Østergaard
    Oticon A/S, Denmark

    Wednesday, September 2, 2015 12:56 PM
  • Hi,

    When Redistributing Visual C++ Files, if a Visual C++ library DLL is not reachable and Windows cannot load it for your application, this message may be displayed: This application has failed to start because MSVCR<version number>.dll was not found. Re-installing the application may fix this problem.

    To resolve this kind of error, make sure that your application builds correctly and that Visual C++ libraries are correctly deployed on the target system. For more information, see Understanding the Dependencies of a Visual C++ Application.

    We recommend that you not use merge modules except when you don't have to service your application and you don't have dependencies on more than one version of the DLLs. Merge modules for different versions of the same DLL cannot be included in one installer, and merge modules make it difficult to service DLLs independently of your application. Instead, we recommend that you install a Visual C++ Redistributable Package.

    May


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Thursday, September 3, 2015 7:01 AM
  • Hi May

    Thank you for your answer. As I write myself, I know that the recommended solution is to use the redistributable. But what I don't understand is that the merge modules worked for v120 but don't with v140. The merge modules is a desired solution for us, because we can then contain the entire installation in one MSI.

    Did you remove something from the v140 merge modules to force people over to the recommended way of doing things?


    Tore Østergaard
    Oticon A/S, Denmark

    Wednesday, September 9, 2015 9:14 AM
  • Hi,

    >Did you remove something from the v140 merge modules to force people over to the recommended way of doing things?

    As far as I know, it is not.

    May


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, September 10, 2015 3:04 AM
  • Hello,

    It is a common problem with the VS2015 redistributable.

    The problem is in vcredist_x86.exe, not elsewhere.

    Nick


    • Edited by Expedition2 Thursday, September 10, 2015 4:29 AM
    Thursday, September 10, 2015 4:29 AM
  • Hi Nick

    The vcredist_x86.exe is an alternative to using the merge modules, and in my case, I am trying to avoid using it. Although vcredist_x86.exe is the recommended way, the merge modules should still do the trick. But upgrading from v120 (Visual Studio 2013) to v140 (Visual Studio) breaks that.

    It might be related to this post from earlier in the year:
    http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx, which again states that merge modules are not recommended, but should work.


    Tore Østergaard
    Oticon A/S, Denmark

    Thursday, September 10, 2015 3:18 PM
  • Did you notice the section of the blog post that said:

    There will not be a merge module for the Universal CRT. If you currently use the CRT merge modules and still want to deploy the Visual C++ libraries centrally, we recommend that you move to the above mentioned Windows Update package or to the VCRedist. Alternatively, you may choose to link statically to the Universal CRT and the Visual C++ libraries.

    Thursday, September 10, 2015 3:56 PM
  • HI RLWA32

    Thank you for you attempts at explaning this to me and sorry that I am a bit slow in understanding it.

    You are touching upon one of my problems - I don't know exactly what my projects are using, nor do I know what is part of the Universal CRT. What I know is that my application worked built in VS 2013 and installed with the v120 CRT+MFC merge modules, whereas built in VS 2015 and installed with the v140 CRT+MFC merge modules it doesn't.

    Should I understand it so that something has been taken out of the CRT merge module and placed in a windows update package so that the CRT merge module is now dependent on this package or the vc_redist? I do not control what updates my customers install and the vc_redist is a fairly large and more complicated installation than the simple merge modules.


    Tore Østergaard
    Oticon A/S, Denmark

    Friday, September 11, 2015 12:26 PM

  • Should I understand it so that something has been taken out of the CRT merge module and placed in a windows update package so that the CRT merge module is now dependent on this package or the vc_redist? I do not control what updates my customers install and the vc_redist is a fairly large and more complicated installation than the simple merge modules.


    Tore Østergaard
    Oticon A/S, Denmark

    That is the understanding that i also have from reading the blog posting. It seems the only way you can be sure that your client systems have the necessary redistributable modules is if you install them yourself with vc-redist.
    Friday, September 11, 2015 12:31 PM
  • You could edit the VC140 CRT merge module using Orca and remove the condition that limits installation of the api-ms-win-crt-runtime-I1-1-0.dll component to Windows XP alone.

    I'm sure there will be unforeseen consequences, but it's worth trying. 




    Thursday, November 12, 2015 9:14 PM
  • So what does this mean for people who have subscribed for Office 365 and having this problem??  How can I fix it.  I am currently running Windows 7 Home edition.  Need to sort urgently.  Thanks in advance
    Monday, August 29, 2016 2:14 AM
  • May, That was a very lame way to avoid answering the question! 

    Wednesday, January 11, 2017 10:33 PM
  • What the He## is Orca?
    Wednesday, January 11, 2017 10:35 PM
  • I'm sorry Krista but it looks like May, "Dropped The Ball"!

    If you're not from the U.S.A., that means she gave up because of her lack of knowledge!

    I'm sorry for you because I am having the same problem with Vista.

    Will someone PLEASE answer the question on how to fix "api-ms-win-crt-runtime-l1-1-0.dll"!     

    Wednesday, January 11, 2017 10:42 PM
    • Proposed as answer by adj99 Friday, February 3, 2017 11:14 AM
    Wednesday, January 11, 2017 10:51 PM
  • Finally an easy to read answer for people who are not as savvy as Bill Gates!

    Thank you RLWA32!!

    I'll give it a try! 

    Friday, January 13, 2017 8:45 AM
  • Tore,

    It seems as if you have more knowledge than anyone else. I salute you!

    One question though; how did you train that chipmunk to stay on top of your head?    


    Friday, January 13, 2017 8:59 AM
  • Thanks again, RLWA32!

    I have tried to use the link that you supplied but my Vista programmed computer

    stopped downloading ANY Microsoft updates about three years ago.

    I am stuck in the Microsoft "Twilight Zone". 

    Friday, January 13, 2017 9:58 AM
  • This works, it is simple, and congratulations to RLWA32

    LiVe1AdJ1

    Friday, February 3, 2017 11:13 AM
  • Hi Tore (and anyone else interested)!

    I'm trying to re-activate this discussion because I'm having the exact same problem but with VS 2017. Has anybody found a decent way to fix this issue?

    By 'decent' I mean a way in which one can still build an MFC application package in VS2017, create an MSI installer file, and make this work as a single installation package.

    Like others, I am tied to using the MSI files as we have published links to these for folks to click and install the "standalone" software packages. However, even when I use the "v141_xp" platform toolset, it seems that the installer sets up VC runtime and/or MFC DLLs that require use of the "Universal Windows" platform (and thus the api-ms-win-crt ... DLL file).

    For now, I'm having to rely on Visual Studio 2010 to build fully usable software packages!

    Cheers, Adrian

    Monday, August 6, 2018 11:00 AM
  • The "decent" way of doing this is by also including the UCRT packages in the installer too.

    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Monday, August 6, 2018 12:16 PM