none
which msvcr90.dll?

    Question

  • I have a DLL and a testing application for it.  When I run the app to test it, I get:

    "The application has failed to start because MSVCR90.DLL was not found.  Re-installing the application may fix this problem."

    Ok, so all I did was copy over the .lib to build the app, then the .dll file was copied over into the runtime directory.  I searched C: for files named msvcr90.dll and there were multiple listings.  Which one do I pick?  I chose

    C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\msvcr90.dll

    but now when I run the app from the command line I get this

    "Runtime Error!  R6034.  An application has made an attempt to load the C runtime library incorrectly.  Please  contact the application's support team for more information."

    Did I not chose the right one?  Also, googling tells me that it's something about a manifest needed along with my DLL?  If that's it, how do I build one?

    Wednesday, February 22, 2012 5:44 PM

Answers

  • When you copied the file from the redist directory (C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\ see the redist in the name?) did you copy over just msvcr90.dll? If you did then that is the problem. There is a file named Microsoft.VC90.CRT.manifest in the directory too, you must also copy that over.

    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.


    • Edited by Crescens2k Thursday, February 23, 2012 12:44 AM
    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:13 PM
    Thursday, February 23, 2012 12:44 AM
  • If you are building the DLL with a relatively modern version of VC then no, it should generate everything necessary for the DLL. This error is occuring because msvcr90.dll is marked as a dependent assembly for the .dll file but it is not in the manifest.

    OK, I'm assuming that the DLL was built using the Visual Studio IDE here, if it wasn't then you really should have mentioned that before.

    Anyway, for the DLL, go to the project directory and find the directory where all of the .obj files are. In there look for the file named <dllname>.embed.manifest. This is a text file that contains XML, could you post the contents of that here.

    Of course, if you didn't build that DLL using the Visual Studio IDE then forget that. There are more important things to discuss, like how you are building the DLL, what tools you are using, what command line options are you giving the compiler and linker and so on.


    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.

    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:14 PM
    Thursday, February 23, 2012 5:32 PM
  • The only thought that I have left is that maybe you copied over the release version of the DLL by accident?

    From what was said earlier there was no embed version of the DLL manifest, and that only happens with release builds.

    If this is the result of a build with the solution configuration set to debug, make sure that configuration manager says that it is building the debug configuration of the project. If that still creates a release version of the DLL, try recreating the entire DLL project. There is something wrong here.


    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.

    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:13 PM
    Friday, February 24, 2012 5:02 PM
  • I just rebuilt everything and I can say for sure, especially based on size, that I am using the debug version of the dll.  When I build, I do get this one warning though.  Maybe this can shed some light?  "LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library"  It sounds related, and it doesn't happen when I make the Release build.  Googling sounds like it's the problem.  How in the heck did something like this get set?

    Nevermind, I had totally forgotten that this DLL is built against a lib that is exclusively built as Release.  That's where the confusion is coming from.  I wasn't using the lib stuff recently so I forgot about it being in there.  But I appreciate your help, even if you're pulling your hair out now at my huge mistake eating up your time.  It was good learning you provided.  Thanks.

    On another note, why is this just a WARNING?  I mean, if the result is going to be a DLL that isn't usuable, this should be an error, no?

    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:15 PM
    Friday, February 24, 2012 6:05 PM

All replies

  • Here is list of all vc++ runtime packages:

    http://support.microsoft.com/kb/2019667

    Install the latest one for VC++2008, because what you have in your redist directory may be outdated.

    Also it is very recommended that your dll and the test app are bult with same VC++ version.

    Usually there's no need to do anything with the manifest. Just check that your project settings are correct and vc++ will do the right thing.

    Regards,

     -- pa


    • Edited by Pavel A Wednesday, February 22, 2012 6:13 PM
    Wednesday, February 22, 2012 6:11 PM
  • Here is list of all vc++ runtime packages:

    http://support.microsoft.com/kb/2019667


    So on any machine that I want to have an app use the dll on, I have to have someone execute "Visual C++ 2008 SP1 Redistributable Package (x86)"?

    Install the latest one for VC++2008, because what you have in your redist directory may be outdated.

    Also it is very recommended that your dll and the test app are bult with same VC++ version.


    What is "redist" directory? I am using VS2008 for both app and dll.

    Usually there's no need to do anything with the manifest. Just check that your project settings are correct and vc++ will do the right thing.


    What project settings should I check?

    Thanks.

    Wednesday, February 22, 2012 7:52 PM
  • When you copied the file from the redist directory (C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\ see the redist in the name?) did you copy over just msvcr90.dll? If you did then that is the problem. There is a file named Microsoft.VC90.CRT.manifest in the directory too, you must also copy that over.

    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.


    • Edited by Crescens2k Thursday, February 23, 2012 12:44 AM
    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:13 PM
    Thursday, February 23, 2012 12:44 AM
  • When you copied the file from the redist directory (C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\ see the redist in the name?) did you copy over just msvcr90.dll? If you did then that is the problem. There is a file named Microsoft.VC90.CRT.manifest in the directory too, you must also copy that over.

    I copied that over as well, and I still see the same issue.  Any settings could be off?
    Thursday, February 23, 2012 3:41 PM
  • If you are building the DLL with a relatively modern version of VC then no, it should generate everything necessary for the DLL. This error is occuring because msvcr90.dll is marked as a dependent assembly for the .dll file but it is not in the manifest.

    OK, I'm assuming that the DLL was built using the Visual Studio IDE here, if it wasn't then you really should have mentioned that before.

    Anyway, for the DLL, go to the project directory and find the directory where all of the .obj files are. In there look for the file named <dllname>.embed.manifest. This is a text file that contains XML, could you post the contents of that here.

    Of course, if you didn't build that DLL using the Visual Studio IDE then forget that. There are more important things to discuss, like how you are building the DLL, what tools you are using, what command line options are you giving the compiler and linker and so on.


    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.

    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:14 PM
    Thursday, February 23, 2012 5:32 PM
  • If you are building the DLL with a relatively modern version of VC then no, it should generate everything necessary for the DLL. This error is occuring because msvcr90.dll is marked as a dependent assembly for the .dll file but it is not in the manifest.

    Anyway, for the DLL, go to the project directory and find the directory where all of the .obj files are. In there look for the file named <dllname>.embed.manifest. This is a text file that contains XML, could you post the contents of that here.

    I use Visual Studio 2008. Here are the contents of TheDLL.dll.intermediate.manifest file (note that there isn't one with 'embed' in the name):

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
    <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level='asInvoker' uiAccess='false' />
          </requestedPrivileges>
        </security>
      </trustInfo>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
        </dependentAssembly>
      </dependency>
    </assembly>

    Now when I right-click and select the version tab for msvcr90.dll, I see File version is "9.0.21022.8". So this should match, right?
    Thursday, February 23, 2012 7:03 PM
  • It should, but as I said, you should be checking the version in MICROSOFT.VC90.CRT.manifest. The msvcr90.dll is part of that after all. So once it is working correctly it will be getting the version information out of the MICROSOFT.VC90.CRT.manifest file. Which is why it is important that it exists in the same directory as the DLL file itself. Oh, and you are right, the embed.manifest doesn't exist. I keep forgetting this for some reason. The release build doesn't generate the output manifest and then embeds it like debug does, it just takes the manifest and directly embeds it.

    So anyway, the DLL has the manifest as expected so it can't be that. So more information is needed on the executable you are using this DLL with. What version of Visual Studio was it built with. Does it have a manifest? If so, can you show the contents of that manifest?


    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.

    Thursday, February 23, 2012 7:13 PM
  • It should, but as I said, you should be checking the version in MICROSOFT.VC90.CRT.manifest. The msvcr90.dll is part of that after all. So once it is working correctly it will be getting the version information out of the MICROSOFT.VC90.CRT.manifest file. Which is why it is important that it exists in the same directory as the DLL file itself. Oh, and you are right, the embed.manifest doesn't exist. I keep forgetting this for some reason. The release build doesn't generate the output manifest and then embeds it like debug does, it just takes the manifest and directly embeds it.

    So anyway, the DLL has the manifest as expected so it can't be that. So more information is needed on the executable you are using this DLL with. What version of Visual Studio was it built with. Does it have a manifest? If so, can you show the contents of that manifest?

    I am also building the app with Visual Studio 2008.  Here is the app's manifest:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
          </requestedPrivileges>
        </security>
      </trustInfo>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>

    Note that it has the extension .exe.embed.manifest
    Thursday, February 23, 2012 7:38 PM
  • Ah, so I'm going to need the DEBUG version of msvcr90.dll, right?  And it's corresponding DEBUG manifest?
    Thursday, February 23, 2012 7:41 PM
  • This is the first time that you mention the debug CRT. If you indeed build a debug configuration (which depends on the debug CRT) the situation is completely different.

    There simply is no redistributable CRT package for the debug CRT that you can download and install on target machines.

    To get the debug CRT on the target, you indeed copy it from the VC++ installation on your development machine, along with the manifest. Please just read the VC++ documentation or google how to do this properly.

    -- pa

    Thursday, February 23, 2012 8:52 PM
  • Ok, I searched the development machine for "Microsoft.VC90.DebugCRT" and it was a folder containing Microsoft.VC90.DebugCRT.manifest and msvcr90d.dll.  So I added the files to the runtime debug directory that the application resides in.  But it doesn't want msvcr90d.dll, it wants msvcr90.dll (without the "d").  So do I mix the release version of msvcr90.dll with the debug manifest?
    Thursday, February 23, 2012 9:58 PM
  • The debug CRT doesn't magically override the release CRT. If the DLL needs one and the executable needs the other, then you will need both to be present, so both DLLs and both manifests. But be aware that the debug CRT isn't redistributable, when you started using Visual Studio you accepted the license agreement saying that you will not redistribute the debug CRT.

    Try building a release build of the executable and trying to use that to run the DLL. I think with that you should notice that it will load then. Of course it is a problem for actual debugging. I want to confirm something first though.

    ---Edit---

    I tested out a sample using an executable with the debug runtime and a DLL with the release runtime and I was able to load the DLL. I also took into consideration that it maybe the Windows version that could be causing issues and I tried it out on Windows XP too (currently running Windows 7 x64) but even this had no problems. So somehow, something on your system is causing the DLL to not try to load its manifest and that is causing the current problem.

    In the executable how are you trying to load the DLL, did you link the DLL's import library to the executable or are you trying to use LoadLibrary?


    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.

    • Edited by Crescens2k Friday, February 24, 2012 10:44 AM
    Friday, February 24, 2012 4:04 AM
  • Ok, yes, I am only doing this so I can use the debugger to step through into the DLL.  So the debug CRT will only be used on this test machine that I also build on.

    First, this is how I built.  I made a debug version of the DLL.  From that, I copied the .lib and .dll files over to my exe subfolders.  The .lib went in the same directory as where the object files and build log end up.  The .dll went into the directory where the .exe ends up.  So it's like this:

                          Debug                                                                                                MyProject                

                             |                                                                                                          |

                             |                                                                                                          |

          .dll, .exe, msvcr90d.dll, Microsoft.VC90.DebugCRT.manifest                                    Debug

                                                                                                                                         |

                                                                                                                BuildLog.htm, obj files, .lib from DLL project

    I then went to the Properties page for my .exe project and added Debug\MyDll.lib as a linker input additional dependency.  Then I built the .exe.  When I run it, it claims msvcr90.dll is not found.  So I added msvcr90.dll and Microsoft.VC90.CRT.manifest to the directory with the .exe and .dll, etc.  Now when I run from the command line I get R6034, An application has made an attempt to load the C runtime library incorrectly.

    Friday, February 24, 2012 3:51 PM
  • If this is a debug build of the DLL, why is it depending on the release version of the CRT?

    Did you perhaps change Project Properties->Configuration Properties->C/C++->Code Generation->Runtime Library from "Multi-threaded Debug DLL (/MDd)" to "Multi-threaded DLL (/MD)"?

    Since it is being dificult figuring out why it isn't reading the DLL's manifest, then at least we can try to get it to use the same version of the CRT as the executable.


    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.

    Friday, February 24, 2012 4:26 PM
  • Ok, I'm opening up the DLL project now.  MyDll Property Pages -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library says "Multi-threaded Debug DLL (/MDd)" and I never went in here, so this sounds correct.

    Any other idea on why it is asking for the release version of CRT?  I have been switching back and forth between release and debug builds, because if I build the .exe against the release .lib file, then run with the release .dll and the release CRT then the .exe executes.  But I am trying to step through and debug the dll, so that is why I am stuck here.

    Friday, February 24, 2012 4:44 PM
  • The only thought that I have left is that maybe you copied over the release version of the DLL by accident?

    From what was said earlier there was no embed version of the DLL manifest, and that only happens with release builds.

    If this is the result of a build with the solution configuration set to debug, make sure that configuration manager says that it is building the debug configuration of the project. If that still creates a release version of the DLL, try recreating the entire DLL project. There is something wrong here.


    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.

    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:13 PM
    Friday, February 24, 2012 5:02 PM
  • I just rebuilt everything and I can say for sure, especially based on size, that I am using the debug version of the dll.  When I build, I do get this one warning though.  Maybe this can shed some light?  "LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library"  It sounds related, and it doesn't happen when I make the Release build.  Googling sounds like it's the problem.  How in the heck did something like this get set?
    Friday, February 24, 2012 5:57 PM
  • I just rebuilt everything and I can say for sure, especially based on size, that I am using the debug version of the dll.  When I build, I do get this one warning though.  Maybe this can shed some light?  "LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library"  It sounds related, and it doesn't happen when I make the Release build.  Googling sounds like it's the problem.  How in the heck did something like this get set?

    Nevermind, I had totally forgotten that this DLL is built against a lib that is exclusively built as Release.  That's where the confusion is coming from.  I wasn't using the lib stuff recently so I forgot about it being in there.  But I appreciate your help, even if you're pulling your hair out now at my huge mistake eating up your time.  It was good learning you provided.  Thanks.

    On another note, why is this just a WARNING?  I mean, if the result is going to be a DLL that isn't usuable, this should be an error, no?

    • Marked as answer by msnhelpsme Friday, February 24, 2012 6:15 PM
    Friday, February 24, 2012 6:05 PM