none
This application has failed to start because MSVCR80.dll was not found!

    General discussion

  • Hello folks!

     

    I spent 2 days knocking my heads on a damned bug! Now I’ve found the solution, so I’d like to share it with you.

     

    I wrote a C++ managed library for use with C# projects in the company. I had to write this in C++ to be able to use stlport and openssl libraries, both written in C.

     

    My managed C++ library, copycontrol.dll, always worked fine at Visual Studio 2003 age. The problem comes out with Visual Studio 2005 and Windows XP. The C++ applications that used copycontrol.dll started to fire a “This application has failed to start because MSVCR80.dll was not found”, during debug process. The release version was OK. So I heard that Visual Studio 2005 had a new dll loading schema (side by side), and that just copying MSVCR80.dll to my application folder would not resolve the problem.

     

    With the new schema, every C++ assembly must point the runtime library that will be used, in a manifest file. So, if copycontrol.dll uses any resource of MSVCR80.dll, I need to write the following manifest file (release version):

     

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>

    <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

      </dependency>

    </assembly>

     

    And the following for debug version:

     

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>

    <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

      </dependency>

    </assembly>

     

    Well done. But why only debug version fires the unhappy error message above? And why does it complains about MSVCR80.dll, and not MSVCR80D.dll, as expected?

     

    After hours and hours searching the internet and MSDN articles, I gave up and decided to look into stlport and openssl.

     

    Stlport has two libraries, stlportd.5.0.dll (for debug) and stlport.5.0.dll (for release), each one with a manifest file referencing the bad guy MSVCR80.dll in a correct manner.

     

    I use openssl as a static library (.lib), so obviously it doesn’t require a manifest file. But, I was using only the release version of the library, libeay32.lib. And that was the problem! libeay32.lib uses the release version of MSVCR80.dll. So, despite the fact of my copycontrol library is being built as debug, libeay32.lib forces the use of release version of MSVCR80.dll.

     

    End of story. I have 2 workarounds for the problem.

     

    -         add the line “type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'” as additional manifest for debug version of copycontrol library, getting the following L:

     

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>

    <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

      </dependency>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

      </dependency>

    </assembly>

     

    -         build a debug version of openssl and use it with debug version of copycontrol library J

     

    This is not a common issue, but I thought that could be useful for some unlucky programmer dealing with C++ and .NET.

     

    Regards!

     

    Bruno.

    Monday, March 12, 2007 10:21 PM

All replies

  • I think this is my exact problem I am having with an OpenGL, GLUT, GLUI project I am working on. I editing the manifest but Visual Studio keeps rewriting it. Which should I change, the embed or the intermediate? By the way why are there two and how are they different?

    http://www.css.taylor.edu/~btoll/resources/graphics/opengl/xp/visualc.html

    That is the exact project code I'm trying to run and the site that tells you how you're supposed to be able to run it (for VS2003 anyway).

    If you could pop that in and see if you get the same error I would be much obliged. I'm not sure which library is the culprit either. I guess the glui32.lib is static like t he one you mentioned and I see it gets it's own manifest but maybe the opengl32.lib, glu32.lib, or glut32.lib are referencing MSVCR80.DLL (am I right in saying that?).

    Thanks so much for getting me a little closer to the solution.
    Tuesday, March 20, 2007 10:15 PM
  • I hope you can help me because I am not too computor literate. I tryed to re-install a game I play alot but was having problems with. When I re-install it it says I dont have the MSVCR80dll installed. How do I install it or restore it? Where do I type the script you describe in your post? Can I down load these devices from microsoft? Any help would be great. Thank you
    Saturday, March 24, 2007 2:59 AM
  • Bruno,

    Thank you so much for posting this clear example of how to fix the manifest problem.  In my case the problem stemmed from linking in a library [ libfftwf_sse_x64.lib ] which had not been compiled for debug.  Even when I compiled it with debug flags, the missing msvcr80.dll was still searched for in the manifests of the exe that linked to the dll which linked the release library (for some reason) .

    Situation looked something like this:

     MyDll.dll -- compiled for debug configuration, statically liked with some 3rd party libraries compiled for release
     MyProg.exe -- compiled for debug configuration, dynamically linked with MyDll.dll

    It appears that unless all of my the libraries linked in are compiled for the same debug configuration, I get the MSVCR80.dll was not found error.

    The specific way I solved this problem in my solution file was to add the following test to the Configuration Properties->Linker->Manifest File->'Additional Manifest Dependencies' field of MyProg.exe :
      type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b'

    Since I also have 'Generate Manifest' set to 'Yes', this will generate the manifest correctly to handle the 3rd party compiled libraries that look for MSVCR80.dll .

    Thanks again,

      -- Richard

    Friday, August 03, 2007 1:27 AM
  • I found this thread at approximately the same time as a collegue (suffering the same problem) found an alternative solution so I thought I'd post the alternative too:

    We found that setting properties for linker | input | ignore specific library | msvcrt.lib
    also works.


    cheers!

    Pete


    Wednesday, January 16, 2008 4:21 AM
  • I set project properties->linker->Input->Delay Loaded Dlls msvcr80d.dll. It works!
    Tuesday, June 22, 2010 6:32 PM