none
msvcr80.dll not found

    Question

  • I've created a simple Win32 console application. When I try to debug it, I get the message:
     "This application has failed to start because MSVCR80D.dll was not found. Re-installing the application may fix the problem."

    The Release version runs fine.

    Any idea as to what the problem could be?

    Thanks,
    Jonny
    Thursday, June 02, 2005 8:02 AM

Answers

  • This means several things.
    a) your console application does not have manifest. Either embedded inside or external. To check this, do the following:
          `1. Check for <appname>.exe. manifest next to exe. If it is not there, it may be embedded. Go to step 2.
            2. Open appname.exe in VS. See if it has RT_MANIFEST. Save it as a file and see if it has this line in it:      
    <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50215.4652" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
                If no RT_MANIFEST resource is present in the binary, go to step 3. If it is there, then go to step 4.
             3. You are building with /manifest:no. Don't do this, it is not supported scenario. Remove this linker switch and it all should work.
             4. msvcr80d.dll is not on the system. We need to know what version of VS is installed, what OS, what parts of VC++ have you selected during installations. Go ahead and file a bug on this on lab.msdn.microsoft.com.

    Hope this helps, 
    Nikola 
    VC++ Team

          
    Saturday, June 04, 2005 2:18 AM
  • I had the same msvcr80d.dll not found problem when trying to run the debug of a simple project. (the release build worked fine).

    I have a clean XP pro installed on a FAT32 partition, and then installed Visual C++ 2005 Express followed by the platform SDK per:
    http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/

    The credit for the fix goes to Cezary Sliwa.   Go to Project->properties->Configuration Properties->Manifest Tool->Use FAT32 Work-around->YES.

    There seems to be a time stamping bug that causes the debug build to mess up the manifest. 

    I am surprised I had to spend several hours hunting for this solution - there is very little help on Microsoft's knowledge base an no help about the FAT32 workaround in the VS help files.

    I hope this saves someone else some time.
    -Eric
    Tuesday, January 31, 2006 7:29 AM
  •  Joel Archambault wrote:
     You could just copy the msvcr80.dll or msvcr80d.dll into you C:\window\system32\ folder. This may not be the prettiest way to solve it tho.

    This is wrong thing to do and it is not supported way of building VC++ applications in VS2005, http://msdn2.microsoft.com/en-us/library/ms235316(VS.80).aspx

    For any similar problems, please post manifest embedded in your applications, build log of this project and info where msvcr80.dll is installed on your computer.

    Friday, February 24, 2006 9:47 PM
  • bashkiro, repeating what Eric said above, if your drive is FAT32 instead of NTFS, try using the FAT32 work-around.

    In the manifest settings under:

    Project Properties - Configuration Properties - Manifest Tool - General

    make sure the "Use FAT32 Work-around" is set to Yes.

    and then do a rebuild all.

    Monday, May 01, 2006 11:39 PM
  • Hi Ted,

    Thanks for following up. Let me start by saying that Richard's double-linker-invocation technique (which is the same thing our IDE project system uses in some cases), is a great solution for some cases, but not always the right thing to do. I think it's worth reading the MSDN docs on this, which I think are more complete and more correct.

    Second, on your specific point about app-local DLLs, I was not able to reproduce your problem. I see things working exactly as we documented them.

    I created a standard VS2003 Win32 Console EXE project on my machine. I replaced its main code with this code:

    #include <windows.h>

    typedef void (*pfnVoid)(void);

    int _tmain(int argc, _TCHAR* argv[])
    {

    HMODULE hModule=::LoadLibrary(argv[1]);
    if(hModule==NULL)
    {
        ::MessageBox(NULL, "DLL Load failed", "Hello", MB_OK);
        return 0;
    }
    pfnVoid pfnFunc=(pfnVoid)::GetProcAddress(hModule, "Test");
    pfnFunc();
    ::FreeLibrary(hModule);

    return 0;

    }

    I then used VS2005 to create a Win32 Project that was a DLL, and added this code to it:

    extern "C"

    {

    __declspec(dllexport) void Test(void)
    {
    ::MessageBox(NULL,L
    "Hello", L"World", MB_OK);
    }

    };

    I built both projects.

    In my VS2003 IDE, I changed the command line arguments of the EXE project to be the location of my DLL project's debug built output

    F:\testdll\Debug\testdll.dll

    I ran the EXE project, and got the expected message box.

    Of course, the debugger showed me that the msvcr80.dll was coming from WinSxS as expected on my machine (which has VS installed).

    Next, to simulate a machine with no CRT install, I went into WinSxS\manifests and WinSxS\policies and renamed the manifest, catalog and policy files that refer to this assembly [Obviously, this is just a temporary hack, but it has exactly the same impact as trying this on a machine where the assemblies are not installed.

    I ran the EXE project, and got the message box indicating that the DLL could not be loading, again as expected. The Event log confirmed that the DLL was failing to load because the debug CRT assembly was no longer installed.

    Finally, I copied the Microsoft.VC80.DebugCRT folder from the ...\vc\redist\... folder into the same folder as the DLL (f:\testdll\debug in my case).

    I ran the EXE a third time, and this time it ran fine again. The debugger modules window confirmed that the CRT had been loaded from app-local, as expected.

    I believe this is exactly the scenario you described as not working, and I see it working fine here.

    Can you perhaps send me an example of a program where you see this not working, and what error you are seeing?

    Martyn Lovell
    Development Lead
    Visual C++ Libraries

    Thursday, June 15, 2006 9:57 PM
  • Hi,

    If error has disappeared after you copied dlls to system32, that means that your application is built with manifest or there is not .manifest file in applicaiton local folder. You may find more information about changes made to VC++ libraries in MSDN docs http://msdn2.microsoft.com/library/bxf4ee9f(en-us,vs.80).aspx or on my blog http://blogs.msdn.com/nikolad/archive/2005/03/18/398720.aspx . Long story short, deployment model for VC++ libraries is changed in VS2005, you application needs to have WinSxS manifest file next to it or embedded inside of it to direct OS loader to a correct version of VC++ library. We have more detailed docs in latest builds of VS2005.

    Thanks,
    Nikola
    Monday, July 11, 2005 9:49 PM

All replies

  • This means several things.
    a) your console application does not have manifest. Either embedded inside or external. To check this, do the following:
          `1. Check for <appname>.exe. manifest next to exe. If it is not there, it may be embedded. Go to step 2.
            2. Open appname.exe in VS. See if it has RT_MANIFEST. Save it as a file and see if it has this line in it:      
    <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50215.4652" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
                If no RT_MANIFEST resource is present in the binary, go to step 3. If it is there, then go to step 4.
             3. You are building with /manifest:no. Don't do this, it is not supported scenario. Remove this linker switch and it all should work.
             4. msvcr80d.dll is not on the system. We need to know what version of VS is installed, what OS, what parts of VC++ have you selected during installations. Go ahead and file a bug on this on lab.msdn.microsoft.com.

    Hope this helps, 
    Nikola 
    VC++ Team

          
    Saturday, June 04, 2005 2:18 AM
  • I also have been getting this error message and up until now seem to have had no idea why it was happening. After installing then uninstalling (including deleting of folders leftover) and installing again, the error would not occur and then for what seemed no apparent reason it would re-occur. This error seems to occur right after going to project properties and does not require any changes to be made, it also only occurs on the debug build and not the release build. By copying the msvcm80d.dll, msvcp80d.dll and msvcr80d.dll (from C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373) to C:\WINDOWS\system32 and replacing existing file (didn't know if msvcm80d.dll and msvcp80d.dll were required but copied them there also) the error no longer occurs. However the cl.exe in C:\Program Files\Microsoft Visual Studio 8\VC\bin also complains about mspdb80.dll missing after going to project properties, but compiling and building in visual c++ 2005 express edition beta 2 still work.
    Sunday, July 10, 2005 9:31 AM
  • Hi,

    If error has disappeared after you copied dlls to system32, that means that your application is built with manifest or there is not .manifest file in applicaiton local folder. You may find more information about changes made to VC++ libraries in MSDN docs http://msdn2.microsoft.com/library/bxf4ee9f(en-us,vs.80).aspx or on my blog http://blogs.msdn.com/nikolad/archive/2005/03/18/398720.aspx . Long story short, deployment model for VC++ libraries is changed in VS2005, you application needs to have WinSxS manifest file next to it or embedded inside of it to direct OS loader to a correct version of VC++ library. We have more detailed docs in latest builds of VS2005.

    Thanks,
    Nikola
    Monday, July 11, 2005 9:49 PM
  • I'm getting this error on XP64 with Express 2005 beta 2. I tried to create a Win32 test app using this set of instructions:

    http://lab.msdn.microsoft.com/express/visualc/usingpsdk/default.aspx

    When I attempt to run it I get the missing DLL. Copying the DLL into the Debug directory allows me to run it. The IDE tells me it can't open an EXE. Without the DLL, I get a DLL load exception attempting it. With the DLL copied,  I get "The file cannot be opened with the selected editor. Please choose another editor." Linker command line looks like this:

    /OUT:"\.exe" /NOLOGO /MANIFEST /MANIFESTFILE:"\.intermediate.manifest" /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib

    Curiously the manifest has this:

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

    Note the 'x86' instead of 'amd64'. Is that something new with beta2 or do I have something screwed up in my installation? The IDE installed itself to my Program Files (x86) directory.
    Tuesday, October 18, 2005 3:17 AM
  • Re: Lomak's reply.

    I'm getting sporatic occurances of this problem that pop up out of the blue (i.e. no purposeful changes to my manifest nor changes to dll locations/versions.)  Next time this happens, could you do a "super clean" of your project: quit the IDE, go to the command line and delete all intermediate files manually (delete the debug directory, release directory, your ncb file and your user-level project settings file.) If your manifest problem goes away (i.e. loader doesn't complain of a missing dll), then at least I can know I'm not the only one...

    I have 2005 Beta 2 BTW.

    This is admittably on the side of superstition, but hey, it's the month of the Jack-O-Lantern.

    Brian
    Tuesday, October 18, 2005 3:44 AM
  • I second Brian on this. Please try to repro this on "clean" project. And do not copy anything to anywhere. Just build project from IDE and if error shows up, please check manifest embedded inside the binary and msvcr80d.dll in WinSxS. If IDE does not open EXE, try running mt.exe -inputresource:myapp.exe;#1 -out:myapp.manifest on the VS command line. This should extract manifest from binary to a text file.

    Nikola
    VC++
    Thursday, October 20, 2005 6:42 PM
  • My point was that I was hit this problem (a manifest mismatch of some kind) without any special doing on my part. i.e. at some point in my VS session: code/build/run->works->code/build/run->missing dll.  It went away a clean project build, and not the "Clean Project" kind of clean.  A "go to command line and scrub down completely" kind of clean.  This happened 4 times in the last couple of months. 

    But of course my Beta2 version might be the culprit.  I posted this in the hope that someone else could duplicate this pathlogical issue. 

    Brian
    Thursday, October 20, 2005 7:01 PM
  • OK. I had the same problem with the Express Beta, now I see it was not fixed in the released version. The bug is very simple: the manifest resource file "Debug\xyz.exe.embed.manifest.res" is generated BEFORE its source file. Just check the build log. Removing the .res file and rebuilding cures the problem. PS. I wonder if building on a NTFS vs. FAT partition affects this.
    Saturday, November 19, 2005 8:30 PM
  • I had this problem with the release version.  Changing the runtime library, Properties->C++->Code Generation, helped.  I changed it from /MD to /MT
    Sunday, November 20, 2005 4:08 AM
  • I had the same problem when running a registry scan using Norton's Systemworks.  Several file associations for Net Framework could not be made when attempting to access msvcr80.dll with the error message "file could not be found..."  Norton's more or less told me that either the file was hidden in NTFS or was missing and it was suggested that I reinstall...reinstall what? It didn't specify though what I was to reinstall, net framework? my operating system? or just the dll file....Anyway, thank you for your notes here...saved me a lot of aggravation :)
    Tuesday, November 29, 2005 6:09 PM
  • It would be nice to have a verbose diagnostic tool that tells you after the fact why the loader chose to say msvcr80.dll (or any other dll) not found, in the same spirit as dcdiag.exe goes through domain controller configuration issues with a fine tooth comb.  (If I was an expert and I had the time, I'd write one.) :)


    Tuesday, November 29, 2005 6:16 PM
  • I can verify that I had the same issue. I deleted the .res file in the Debug directory, and attempted to build again, and everything was fine after that.

    A bit vexing!

    Friday, December 16, 2005 7:09 AM
  • Ok, same problem here:
    I created the exactly same visual studio project, once on an NTFS partition and once on a FAT32 partition. On FAT32 I get this strange "msvcr80.dll was not found" error, on NTFS I don't get it....
    Removing the .res file every time solves the problem, but is quite a hassle.

    However, here you go, this is the automatic solution:

    In the Visual Studio Project properties of the Manifest Tool, under General you can activate "Use FAT32 Work-around". Now everything works fine.

    I hope, I could help others desperately looking for an easy solution.

    Cheers,
    Marco
    Sunday, January 15, 2006 5:57 PM
  • feuerste that's an excellent point (I'm "bottom posting" this reply so it will appear at the bottom of this thread)  I didn't know what the "use FAT32 work-around" option was as it's not even in the online help.  And the only mention of it seems to be in a Korean blog at:

    http://blogs.msdn.com/bkchung/archive/2005/10/28/486086.aspx

    Can someone at Microsft comment about the "use FAT32 work-around" option and in what circumstances should you use it.   Is it something that affects run-time at all or is it just compile time workaround?

    Sunday, January 15, 2006 8:44 PM
  • Ok, since others may also wonder, why that happened and what the fix is for, here is a very helpful hint I got from Cezary (Thanks a lot for that!)

    The difference between FAT and NTFS is probably the resolution of the
    file time-stamps. It is 2 seconds for FAT. It is enough time to generate
    two files so that the build system does not know which one is newer.

    Microsoft developers, why is this FAT32 work-around
    1) not documented at all?
    2) not enabled by default for any visual studio project?

    Cheers,
    Marco

    Monday, January 16, 2006 9:25 AM
  • Hello everyone,

    My name's Martyn Lovell, and I'm the development lead of the team that produces msvcr80.dll [The Visual C++ Libraries team]. There are a couple of things I'd like to clarify.

    Those of you who are seeing errors at application runtime should heed the advice above about building your application with a manifest. This is corrrect advice.

    However, if the only error you're seeing is from Norton WinDoctor/SystemWorks, then read on...

    First, Norton WinDoctor is wrong. It incorrectly reports that msvcr80 is missing when in fact it is correctly installed in the WinSxS directly in the windows. folder. If you own WinDoctor, you should report this bug to Symantec so that they get it fixed.

    Do NOT copy the this file to any of the folders WinDoctor recommends.

    If you've already attempted to take corrective action for this issue (by copying msvcr80.dll or msvcr80d.dll to ...\system32 or to the .NET Framework directory), please delete them. These files do not need to be copied around, and doing so may cause problems in future.

    Please feel free to contact me directly if you have more questions.

    Martyn Lovell
    Development Lead
    Visual C++ Libraries
    martynl@microsoft.com

    Monday, January 16, 2006 11:36 PM
  • (SORRY! just noticed mention of fat32 workaround after posting, am trying that now)

     

    I have the same problem:

    • Same error message,
    • Visual Studio 2005 Standard Edition, version 8.0.50727.42
    • Apparently only in debug,
    • Typically happens after a rebuild all.
    • The required files do exist in winsxs folder

    I believe the problem is some sort of VS5 bug which corrupts the embedded manifest because it tends to not occur till the first rebuild, and the embedded manifest is shorter, ommiting reference to DebugCRT.

    ??There is a small chance it is also related to VS05 complaining once or twice that cpp files that it created lack correct CR/LF??

    (Note: in the following, Ogre is a large open src graphics engine, tinyXML is a handful of c++ files and headers)

    For example I have a running Ogre app

    • I include the tinyXML files and a function that calls them, and a line in main to call that function and press f5
    •    (the application runs)
    • I select rebuild all, then press f5
    •    (the error occurs)
    • By removing tinyXML files and rebuilding, program runs again.

    This worked 3 times in a row, but on fourth time bug did not reoccur by this method. It'll be back.


    NOTE: You can open your EXE inside Visual Studio and examine the embedded manifest as described in (A) below

    • THIS IS HOW MY MANIFEST APPEARS IN MY EXE WHEN I HAVE THE PROBLEM:
      ------------------------------------------------------------------
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?><assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"></assembly>

     

    • THIS IS HOW MY EMBEDDED MANIFEST APPEARS WHEN THINGS ARE WORKING
      ---------------------------------------------------------
      <?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"></assemblyIdentity>
          </dependentAssembly>
        </dependency>
      </assembly>  


    Some extra info::
    -----------------------------
    locations of "MSVCP80D.dll" on my computer:

    • C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c
    • C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT

    (I also had dirs for amd64 versions)

    Found this help at microsoft
     (Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies)
    (A) http://msdn2.microsoft.com/en-us/library/ms235342.aspx

    ..which refers to
     (Understanding Dependencies of a Visual C++ Application)
    (B) http://msdn2.microsoft.com/en-us/library/ms235265.aspx

    ..which told me about Depends.exe utility
    (C) C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\Depends.exe

    I ran Depends.exe and used it to open my application.exe
    Depends.exe told me essentially what I already knew, that MSVCP80D.DLL (and two others) could not be located. Not so much useful as comforting to know it shares my pain.

     

     

    Friday, January 20, 2006 1:05 AM
  • Thanks Martyn!
    Wednesday, January 25, 2006 12:08 AM
  • I got the same message about missing msvcr80 with the debug version of an open source app (enblend) but found a different solution than fooling with manifests (which did not work in my case).  All the CRT dlls were properly installed; but the program manifest does not mention msvcr80, only msvcr80d -- just as yours does.  The solution? Take the linkers's advice and put MSVCRT.lib in the list under project/properties/linker/input/ignore specific library!

    Link warns when MSVCRT.lib conflicts with other libs, but then loads from it anyway; the manifest builder is evidently unaware of this, so the new super-safe, public-keyed, foolproof MicroSlop Windows XP dll finder proceeds to barf. 

    Monday, January 30, 2006 6:44 PM
  • Tom,

    We'd need more information to fully diagnose this problem. It sounds like you are mixing _DEBUG and retail binaries in a single image (perhaps because of libraries built with debug code and without?). We don't support this, and there are lots of problems when trying to do so, as you've discovered.

    msvcrt.lib is used with msvcr80.dll. msvcrtd.lib is used with msvcr80d.dll. You need to have the right one of these, and ONLY one of these. If you are getting linker conflict warnings, this is telling you that you have a serious problem. Don't ignore them.

    Note also that installing msvcr80d.dll in WinSxS is a separate installation step, so it's possible that your initial manifest was correct but that you hadn't installed debug DLLs on your target machine.

    Martyn Lovell
    Development Lead
    Visual C++ Libraries

     

     

    Monday, January 30, 2006 6:58 PM
  • I had the same msvcr80d.dll not found problem when trying to run the debug of a simple project. (the release build worked fine).

    I have a clean XP pro installed on a FAT32 partition, and then installed Visual C++ 2005 Express followed by the platform SDK per:
    http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/

    The credit for the fix goes to Cezary Sliwa.   Go to Project->properties->Configuration Properties->Manifest Tool->Use FAT32 Work-around->YES.

    There seems to be a time stamping bug that causes the debug build to mess up the manifest. 

    I am surprised I had to spend several hours hunting for this solution - there is very little help on Microsoft's knowledge base an no help about the FAT32 workaround in the VS help files.

    I hope this saves someone else some time.
    -Eric
    Tuesday, January 31, 2006 7:29 AM
  • Great, that there are people out there who actually know what they are doing when they use their VC++ :) I had the problem discussed here but only when I deleted the manifest.res file did it work, your help is appreciated very, very much!
    Tuesday, January 31, 2006 1:06 PM
  • Would be nice Eric, but I have tried most of what is suggested in this thread and still can't find the MSVCR80.dll file running it in debug mode. I am so bored with this error. What it left to try... my school project is a catastrophe very soon.

    Sunday, February 05, 2006 9:47 PM
  • The "FAT workaround" and fooling with manifest build sequence did not work for me either.  Here is what did:

    Try putting MSVCRT.lib on the "ignore default library" list in your project's linker settings.  You don't need it if you are building for debug and are not linking to any nondebug object files or 3rd party libraries, but the linker will sometimes still load things from it if allowed to; however the manifest built by VC8 will not reflect this. Apparently, when there is a manifest, every called MS library dll has to be listed in it, and Windows won't look for them in the "standard places" (i.e. \windows\system32) even if they are there.  Such is the price of progress.

    Frankly, this seems to be a bug in VC8/.net2 and I'd complain to Microsoft if I cared more.  But I just work around it as indcated.

    Monday, February 06, 2006 1:32 AM
  • Tom, Jim,

    From reading your posts, I don't have enough information to diagnose your problem. However, I'll be glad to help you get your project working. Perhaps you can email me with

    - details of what version of the product you're using and what operating system

    - what error message you're seeing,

    - a copy of your exe

    - any messages you're seeing in the event log

    - anything else relevant.

    I'm sure we can work out what the right thing to do is.

    Thanks,

    Martyn Lovell
    Development Lead
    Visual C++ Libraries

    Monday, February 06, 2006 7:16 PM
  • I encountered the same problem, and apparently msvcr80d.dll is not installed by VC++ Express. I can see msvcr80.dll in WinSxS, but not the debug version.

    Actually, I was trying to recompile a project I'm still maintaining with VC6 under VC8 in order to drop VC6, but I don't like the dependency on new libs in this case too much. The app is pure win32, no .NET around and should run on non-.NET enabled platforms too. Can I achieve this somehow with VC8?

    Regards,
    Andreas Pflug

    Wednesday, February 15, 2006 3:58 PM
  • Hi there,

    For those of you who couldn't make it work, you could just copy the msvcr80.dll or msvcr80d.dll into you C:\window\system32\ folder. This may not be the prettiest way to solve it tho.

     

    Joel

    Thursday, February 16, 2006 1:13 PM
  •  Joel Archambault wrote:
     You could just copy the msvcr80.dll or msvcr80d.dll into you C:\window\system32\ folder. This may not be the prettiest way to solve it tho.

    This is wrong thing to do and it is not supported way of building VC++ applications in VS2005, http://msdn2.microsoft.com/en-us/library/ms235316(VS.80).aspx

    For any similar problems, please post manifest embedded in your applications, build log of this project and info where msvcr80.dll is installed on your computer.

    Friday, February 24, 2006 9:47 PM
  • Hello,

    I have changed the "Properties Pages->Conf. Properties ->Linker -> Debugging-> Generate Map File" switch to Yes. Now the error does not occour and the app runs well. I do not know why. The map file dipicts sm'thing like this

    ".....
    0002:00001ea6 __CRT_RTC_INITW 00412ea6 f MSVCRTD:MSVCR80D.dll
    0002:00001eb0 ___report_gsfailure 00412eb0 f MSVCRTD:gs_report.obj
    0002:00002000 __configthreadlocale 00413000 f MSVCRTD:MSVCR80D.dll
    ....."

    I do not knoow for what or why this happened nor the meaning of a map file nor the crptic words init, please be kind enough to explain.

    Thanks a Billion

    Ashan

     

    Wednesday, April 19, 2006 5:04 AM
  • I have the problem "msccr80d.dll not found" when I try to debug win32 console application.

    I am using the trial version (VS2005 team) on my WinXP (Dell 8250).

    Do you have any solution for the problem now?

     

     

    Monday, May 01, 2006 11:23 PM
  • bashkiro, repeating what Eric said above, if your drive is FAT32 instead of NTFS, try using the FAT32 work-around.

    In the manifest settings under:

    Project Properties - Configuration Properties - Manifest Tool - General

    make sure the "Use FAT32 Work-around" is set to Yes.

    and then do a rebuild all.

    Monday, May 01, 2006 11:39 PM
  • Thanks, seems to be it helps!
    Monday, May 01, 2006 11:55 PM
  • Eric,

    As with others, I got the "msvcr80d.dll not found" after editing the project properties.

    I applied this fix and it worked for me.

    You're right - this workaround should be in the Microsoft KB.

    Thanks,

    Henry

     

    Friday, May 05, 2006 8:59 PM
  • --- Aner wrote:
    I had this problem with the release version.  Changing the runtime library, Properties->C++->Code Generation, helped.  I changed it from /MD to /MT
    ---

    This solved my problem with Visual Studio 2005 C++ EE. My test win32 app finally worked on an older computer without any .net framework.

    Wednesday, May 17, 2006 9:35 PM
  • Convertion to /MT is almost always an inappropriate and dangerous solution.

    The problem with /MT is that we will no longer be able to service our code if there turns out to be a security problem. When you target the CRT DLL you can be sure that in an emergency, we can fix the security problem.

    My strong advice is to avoid /MT in almost all cases.

    The right solution is to simply attach a manifest to your program (done by default in the IDE), and copy the CRT DLLs and its manifest with XCOPY or you zip file or installer.

    If you have questions or concerns, feel free to email martynl@microsoft.com.

    Martyn Lovell
    Development Lead
    Visual C++ Libraries

     

    Thursday, May 18, 2006 11:42 PM
  • can someone please answer these questions ? (sorry if these are really obvious)
    1. does the .manifest file need to be in the same directory as the exe file ?
    I have a directory "something_debug" where all the obj, sbr and the manifest files are created but I have set my target file (.exe) to be created in another directory (along with all my other exes for conveneince)

    2. I upgraded my project from vc6 to vc8 and by default this was what the manifest file was called $(IntDir)\$(TargetFileName).intermediate.manifest . do I need to remove the "intermediate" from there ?

    this is my main problem: When I link another library (fortran, multi-threaded, dll) to this project(multi-threaded debug DLL, debug configuration), it builds it without any problems, but when I run the program, it gives me this error "...msvcr80.dll not found...".
    I know the external library is not debug version - I do not have my hands on its debug version right now to check if that solves the problem. do I really need to have a debug version of the library for it to work ? plus, I was expecting it to ask for msvcr80d.dll since I am in debug configuration. can someone explain what's happening ?

    thanks,
    Julian.
    Thursday, May 25, 2006 7:08 PM
  • Question 1:

    When you build an EXE or DLL with the IDE project system, we also build a manifest by default to represent the dependencies of that EXE or DLL. By default we'll embed this manifest inside your EXE or DLL as a resource (ID#1 for an EXE and ID#2 for a DLL). This is the recommended way to do things, as you don't have another file to worry about.

    For a DLL, your dependency manifest MUST be internal in this way as an ID#2. It cannot ever be external.

    For an EXE, you can use an external manifest (foo.exe.manifest) which must appear right next to the EXE in the same folder. But there's no advantage to this form.

    In the IDE, if you set the EXE to be built somewhere else, its manifest should be built there too. But since, by default, we build the manifest into your EXE, rather than as an external file, you won't see it on the disk. If you open your EXE in the resource editor you'll see its manifest.

    Remember that binaries with no depenedncies on libs DLLs (CRT/MFC/ATL) generally don't need manifests. For example, if you build /MT, you likely won't need a manifest.

    Question 2:

    The .intermediate.manifest file is an intermediate file, used in the production of the actual manifest. It is not suitable for use, and you should treat it like a .obj intermediate file - just ignore it.

    Main problem:

    I don't know anything about linking fortran to VC8, but you'd definitely need to be using a version of fortran designed to link with VC8.

    However, in your example it seems like you are linking /MD code (from fortran) to /MDd code (from your project). This is completely not supported. You need to only link compatible code. If your fortran code has to be /MD, then your project will need to be /MD too.

    However, I doubt that that is the cause of your msvcr80.dll error. I assume the DLL you are building does not have a manifest. Did you check inside the DLL that it has a manifest?

    Martyn Lovell

    Development Lead

    Visual C++ Libraries

     

    Thursday, May 25, 2006 7:36 PM
  •  Martyn Lovell wrote:


    If you open your EXE in the resource editor you'll see its manifest.

    ...

    I assume the DLL you are building does not have a manifest. Did you check inside the DLL that it has a manifest?



    based on your reply i'm beginning to think that maybe I have not understood when to use "multi-threaded" as opposed to "multi-threaded DLL"
    this is what my understanding is based on - (http://www.steptools.com/support/kb/articles/0004.htm) - is article accurate ?
    I am using the "DLL" option so that my program uses the dynamic C libraries as opposed to the static libraries. I don't know why you assumed that i am building a DLL - please let me know if i am going wrong somewhere. I am building an (/MDd) EXE and not a DLL.
    I am linking my program to a static library (/MD) (from fortran). is that something that I am not supposed to do - I mean am I not allowed to link an /MD program to a static library?

    thanks for the explanation on the manifests - is the resource editor the same as the "resource view" is VS 2005? can you tell me how to get to the "resource editor" or how to open the exe in that?
    thanks

    Thursday, May 25, 2006 8:20 PM
  • I had started another thread on a different problem and for some reason, I just got an email saying that the post has been deleted by "Ayman Shoukry - MSFT" because it is a duplicate of the post I made on this thread.
    I went through this entire thread, and none of the posts address the problem that I mentioned in my new post. How do I go about starting a new thread and not have it deleted ?
    Thursday, May 25, 2006 8:32 PM
  • I figured out how to open the exe with the resourse editor. thanks
    Thursday, May 25, 2006 8:48 PM
  • Multi-thread means that you compile /MT and use libcmt.lib, libcpmt.lib, nafxcw.lib, etc. This results in a binary that contains all the library code inside itself. A variant is multi-threaded debug (/MTd) which links with libcmtd.lib, libcpmtd.lib, nafxcwd.lib.

    Multi-threaded [debug] DLL means that you compile /MD, and use msvcrtDrinks.lib, msvcprtDrinks.lib, mfc80Drinks.lib. This results in a binary with a manifest that depends on msvcr80.dll, mfc80.dll, etc.

    The article you linked to is from 1997, and definitely does not apply to VC8, which doesn't even include LIBC.LIB. It is unlikely that code from a 1997 fortran tool would link to VC8.

    Sorry that I misunderstood that you were building a DLL. Here's what I should have said:

    >> However, I doubt that that is the cause of your msvcr80.dll error. I assume the EXE you are building does not have a manifest. Did you check inside the EXE that it has a manifest?

    You can link a program to a static library compiled the same way from a toolset that is compatible with VC8, yes.

    Martyn Lovell

    Development Lead

    Visual C++ Libraries

     

    Friday, May 26, 2006 12:00 AM
  • thanks for the explanation.
    I was finally able to get a debug version of the static library. and when I linked that with the debug version of my program, I did not get that error message ! so, i'm guessing that error message I got earlier didn't really explain the problem well since obviously I have both dlls on my computer (msvcr80d.dll and msvcr80.dll) - because both debug and realease versions of my program work fine when it is not linked to this static library. maybe it should have said something along the lines of "incompatible dlls".

    thanks
    Sunday, May 28, 2006 5:19 AM
  • Hi Eric,

     

    It worked for me(FAT32 workaround).

    Thanks

    Frustrated

    Tuesday, June 13, 2006 11:25 AM
  • Hi Martyn.  First off, I want to say thanks for being out here on the front lines with us developers.

    I have to say that I am really frustrated and disappointed at how burdensome this merge module/manifest stuff is.  I have been developing Windows apps since the 16-bit days and I've been using Visual C++ since VC++ 4.2.  I get the impression that Microsoft, after several attempts, gave up trying to solve DLL Hell in an elegant fashion and decided to just "make it the application developer's problem".

    At my company, we are transitioning from Visual Studio 6 (VC98) to Visual Studio 2005.  We produce Java server-side applications which typically run using either Sun's or IBM's Java virtual machine.  This means the app is launched from an JAVA.EXE executable produced by another company.  The java.exe and supporting IBM/Sun libraries are typically statically linked with whatever they need, so that developers like me are free to dynamically link against whatever version of the CRT they want without fear of conflicts.

    We have a few DLLs which provide access to native Windows functionality (these DLLs link to the CRT have always been built using /MDd).  We do not use the Visual Studio IDE to build anything -- everything is driven from the command line build system using CL.EXE and LINK.EXE, as we've been doing for over a decade.  The application deploy process for dev builds on dev workstations is brick simple -- files are simply copied into the deployment directory.

    The developer then runs the code using the IBM or Sun Java virtual machine.  Obviously this virtual machine is implemented as an executable file over which we have no control (typically java.exe).  So the developer ends up running something like "java.exe <some arguments>", making sure that our native DLLs are included on the PATH.  There is no installer for dev builds, so no merge module magic can happen.

    The virtual machine loads our code, which eventually causes our own DLLs to be loaded using something like LoadLibraryEx. And this is where things break down, because these DLLs link
    to the debug CRT and the error dialog says that the application is not using a manifest.

    99% of the Microsoft documentation on this subject discusses how to use the Visual Studio IDE to make sure that your application is including the right merge modules in its manifest.  This presents two problems for me -- (1) as stated above, I don't use the Visual Studio IDE, (2) the actual application is built by Sun or IBM, we just build the DLLs.

    So I've experimented with manually installing the debug CRT non_redist merge modules (using MSIEXEC /I) and then creating an external manifest (java.exe.manifest) and copying it into the Java installation directory.  This doesn't quite work right, and anyways it feels like an ugly kludge (because it is).

    Is there any documentation which explains, in straightforward terms, what a developer needs to do in order to get a debug version of his application to run on his workstation WITHOUT using Visual Studio projects?

    I'm extremely frustrated that the way I've been doing running apps on Windows for 10+ years suddenly changed.

    Best regards,
       Chad Loder
    Thursday, June 15, 2006 6:13 AM
  • Hello Chad.  Applocal will work the best for you.  This isn't documented anywhere (except in OShah's web page about the matter).  Let's say you have a DLL you built named myjavaDLL.DLL.  Just make sure the runtime DLLs AND the manifest are in the SAME folder as the DLL (not a subfolder like Microsoft recommends). 

    e.g.

    • C:\Test\myjavaDLL.DLL
    • C:\Test\MSVCR80.dll
    • C:\Test\MSVCP80.dll
    • C:\Test\MSVCM80.dll  (only needed if any reliance on managed code)
    • C:\Test\Microsoft.VC80.CRT.Manifest

    The exact same as above also applies to debug versions of the runtime DLLs (just use the debug versions of the DLLs and manifest instead of the release)

    Thursday, June 15, 2006 12:54 PM
  • Hi Chad,

    Thanks for following up. Sorry you're finding this difficult. We are working on improved docs, but I believe we already have docs that should cover your scenario: http://msdn2.microsoft.com/en-us/library/ms235542(VS.80).aspx - this includes subtopics that specifically address how to do this if you are non-VS project user.

    What this article will show you is how to put a manifest inside your DLL using tools we ship with the product, and this will allow the DLL to find its msvcr80 dependency even when it runs inside the Java VM or elsewhere. Your command line build is already generating the manifest you need, so all you need to do, most likely, is add a call to the mt.exe tool to your makefile. We have lots of itnternal users at Microsoft who use makefiles for their builds (including some of our largest projects), and we were able to add the manifest generation to the build with only small changes.

    Let me also say explicitly that creating java.exe.manifest is wrong, and you should delete this manifest. Applying a manifest to another piece of software is never correct and should be thought of as similar to making a binary patch to the program - never something to be doing.

    To address your initial point, I'd assert that we didn't give up on solving DLL Hell in an elegant fashion. Instead, the windows team looked hard for the most simple and elegant solution to the problem they could find while making minimal changes to existing applications, and this is the solution they were able to find. Windows spent many years of engineering creating the new manifest-based loading scheme in Windows XP, and VC spent a large amount of time adding it to Whidbey in a way to make it as easy as possible for existing applications developers (including adding features to the compiler, linker and IDE to make this as automatic as possible). Not every aspect of this is as easy as it could be, but when you look at the raw technology the operating system provided, we've worked hard to do almost all of the work for you.

    Let me know if you have any further problems.

    Martyn Lovell

    Development Lead

    Visual C++ Libraries

     

    Thursday, June 15, 2006 5:17 PM
  • Hi Ted,

    First, let me say that both applocal and central install should work just fine in Chad's scenario. His problem appears to be that his DLL doesn't have a manifest. And app-local deployment definitely is documented http://msdn2.microsoft.com/en-us/library/ms235291.aspx

    If you are targetting OSes w2k and earlier, then you want to do your app-local deployment in the same folder as your application. This is the only way they'll be found on down-level operating systems.

    If you are targetting only WXP and later, then subdirectory deployment is better because it ensures that the appropriate assemblies are kept separate.

    Martyn

     

    Thursday, June 15, 2006 5:26 PM
  • Chad, I missed the part of your article about how to include a manifest when using the command line (instead of IDE).  Richard Grimes wrote a pretty good article explaining it here (much of it still applies to unmanaged - the important point is invoking the linker twice):

    http://www.ddj.com/dept/cpp/184406482

    http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm

    [EDIT: everything below this is incorrect - please see subsequent replies for accurate info]

    Martyn, I meant to explain that applocal deployment is only documented for EXEs, not DLLs.  For DLLs (such as ActiveX etc), the documented approach does not work.  If you put the CRT DLLs and manifest in a subfolder, then the DLL does not find them.  If you can show a complete working example of a DLL being loaded by another external EXE (that has no manifest etc) and having the applocal DLLs in a separate subfolder e.g.

    c:\test\mytestdll.dll

    c:\test\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifest

    c:\test\Microsoft.VC80.CRT\mscvr80.dll

    etc.

    and then some other external EXE built with some old tool like VC6 or VC.NET, for example c:\mytestexe\TESTVC6.EXE, and then the TESTVC6.EXE does a LoadLibrary of c:\test\mytestdll.dll

    then I apologize that I've been giving the wrong info all along,

    Thanks

    Ted.

    Thursday, June 15, 2006 6:01 PM
  • Hi Ted,

    Thanks for following up. Let me start by saying that Richard's double-linker-invocation technique (which is the same thing our IDE project system uses in some cases), is a great solution for some cases, but not always the right thing to do. I think it's worth reading the MSDN docs on this, which I think are more complete and more correct.

    Second, on your specific point about app-local DLLs, I was not able to reproduce your problem. I see things working exactly as we documented them.

    I created a standard VS2003 Win32 Console EXE project on my machine. I replaced its main code with this code:

    #include <windows.h>

    typedef void (*pfnVoid)(void);

    int _tmain(int argc, _TCHAR* argv[])
    {

    HMODULE hModule=::LoadLibrary(argv[1]);
    if(hModule==NULL)
    {
        ::MessageBox(NULL, "DLL Load failed", "Hello", MB_OK);
        return 0;
    }
    pfnVoid pfnFunc=(pfnVoid)::GetProcAddress(hModule, "Test");
    pfnFunc();
    ::FreeLibrary(hModule);

    return 0;

    }

    I then used VS2005 to create a Win32 Project that was a DLL, and added this code to it:

    extern "C"

    {

    __declspec(dllexport) void Test(void)
    {
    ::MessageBox(NULL,L
    "Hello", L"World", MB_OK);
    }

    };

    I built both projects.

    In my VS2003 IDE, I changed the command line arguments of the EXE project to be the location of my DLL project's debug built output

    F:\testdll\Debug\testdll.dll

    I ran the EXE project, and got the expected message box.

    Of course, the debugger showed me that the msvcr80.dll was coming from WinSxS as expected on my machine (which has VS installed).

    Next, to simulate a machine with no CRT install, I went into WinSxS\manifests and WinSxS\policies and renamed the manifest, catalog and policy files that refer to this assembly [Obviously, this is just a temporary hack, but it has exactly the same impact as trying this on a machine where the assemblies are not installed.

    I ran the EXE project, and got the message box indicating that the DLL could not be loading, again as expected. The Event log confirmed that the DLL was failing to load because the debug CRT assembly was no longer installed.

    Finally, I copied the Microsoft.VC80.DebugCRT folder from the ...\vc\redist\... folder into the same folder as the DLL (f:\testdll\debug in my case).

    I ran the EXE a third time, and this time it ran fine again. The debugger modules window confirmed that the CRT had been loaded from app-local, as expected.

    I believe this is exactly the scenario you described as not working, and I see it working fine here.

    Can you perhaps send me an example of a program where you see this not working, and what error you are seeing?

    Martyn Lovell
    Development Lead
    Visual C++ Libraries

    Thursday, June 15, 2006 9:57 PM
  • Hi Martyn,

    Thanks for looking at this and creating/testing a sample app.  I'm completely sorry, you're absolutely right.  Taking a fresh look at it, I realized a (huge) mistake that I made on the clean XP machine (no prior 2005 library installations) I was looking at this problem on.   (Months ago, I was screwing around with the version number in the applocal manifests, and forgot to change it back - this was before I learned about 8.0.50608.0 being the correct version)

    I redid all my examples and redist folders and voila, it loaded them fine from the subfolders.  So my apologies again for the confusion (and leading anyone astray)

    But I still prefer them to be in the same folder as the EXE and DLLs as I wish it to work on all downlevel platforms (without WinSxS support)

    Ted.

     

    Friday, June 16, 2006 2:29 AM
  • Applocal redistribution of VC assemblies on Windows OS that does not support Fusion is not recommended and not supported. We have provided minimal testing coverage for this scenario. Our recommendation to use MSMs if you are targetting downlevel OS.

    Nikola

    Friday, June 16, 2006 8:09 PM
  • Just so I understand this correctly, I believe this support statement is due to the servicing model of the 8.0 DLLs.  In previous versions of VC you encouraged people to put them in their local folders due to DLL Hell.  But security issues etc have changed that stance so having them in system32 is much more important than any problems relating to DLL Hell (so in case of a major security flaw you can go out and issue a patch for Windows 2000 and lower that will affect all apps). 

    Under XP and above, even if a user has them applocal, you can still go out and service them because WinSxS always takes precedence (even if they are sitting in your app folder).  So after installing to WinSxS, all apps on that machine start using the ones in WinSxs, nothing a user can do will force usage of applocal.  But under Windows 2000 and below, if you have them sitting in applocal folder and then try to service them by installing to system32, the ones in the applocal will still be used (ignoring the system32), so servicing becomes an impossibility (unless you use the ugly Windows Update gdiplus technique of finding every instance on the machine).  So the benefts to the servicing model are VERY clear here - do NOT put them in applocal in non-Fusion platforms.  (aside: to solve this you could have used the KnownDLL mechanism instead but we all know the problems with this)

    Now for downlevel platforms, since they are not under system file protection (like msvcrt.dll and mfc42.dll) you are a bit more susceptible to a rogue app removing them from under you (breaking your app).  But the news isn't all bad - instead you are relying on Windows Installer self-healing technology when using MSM files in a user-created setup.  So, this problem only comes into play if the MSI "self-healing" ability of the app that installed the CRT msms does not work, or someone does something stupid like roll-their-own install (without MSI technology) to place those DLLs in system.

    Now my question is: on non-Fusion platforms, how does MSI self-healing work when it comes to vcredist_x86.exe?  Is there any? Or can you simply delete the msvcr80.dll from system32?   So am I right in saying ShellExec'ing vcredist_x86.exe from a user-created setup program is highly discouraged?  Or is using vcredist_x86.exe safe?

     

    Saturday, June 17, 2006 1:43 PM
  • Download the missing file from www.dll-files.com and extract it to the correct folder using the information showed by your Norton SystemWorks. I hope that it can help you.

    Friday, June 30, 2006 2:17 PM
  • Fernando,

    Downloading this file from www.dll-files.com is NOT ever the right thing to do for this problem. Please don't do it, or advise others to. Last time I checked the dll-files version was a beta version, but even if it were not, this is not the solution.

    Please see my other posts in this thread for correct advice.

    Martyn Lovell

    Development Lead

    Visual C++ Libraries

     

    Friday, June 30, 2006 4:22 PM
  • I have been having this problem for a while, and I just did a search on the Symantech website, and following is their solution:

    Error: " . . . Cannot access necessary file, msvcr80.dll..." when running One Button Checkup or WinDoctor

    Situation:

    Microsoft® .Net Framework 2.0 is installed on your computer. You run the One Button Checkup or WinDoctor scan, and you see the following error messages:

    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\AppLaunch.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_state.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_wp.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\cvtres.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ilasm.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorsvw.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe" cannot access a necessary file, "msvcr80.dll"
    "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\vbc.exe" cannot access a necessary file, "msvcr80.dll"


    Solution:
    To fix this problem, tell One Button Checkup or WinDoctor to ignore the errors. If you tell One Button Checkup or WinDoctor to fix the errors, the messages will reappear in the next scan.


    Monday, July 03, 2006 4:09 AM
  • After over a year of running VS2005 from beta to release on several systems, I have just now run into this problem for the first time. I installed VS2005 Standard (JPN) on a system that has 2003 installed, but never any of the betas. Installation completed fine without any problems. As a first test, I ran the Windows wizard. Without any changes, I immediately tried to execute it and encountered the problem. Disabling embedding the manifest resolved the issue for me. (Curiously, re-enabling embedding of the manifest did not reproduce the problem...)

    Has the issue been identified yet?
    And if so, will it be addressed in the forthcoming SP1?

    Regards.
    Ben

    Wednesday, July 26, 2006 3:42 AM
  •  Intelligence wrote:
    I've created a simple Win32 console application. When I try to debug it, I get the message:
     "This application has failed to start because MSVCR80D.dll was not found. Re-installing the application may fix the problem."

    The Release version runs fine.

    Any idea as to what the problem could be?

    Thanks,
    Jonny

    I am having almost the exact same problem, but in my case it is the "MSVCP80D.dll" that VC2005 can't find.  I have found a solution that has made the problem go away for me.  I haven't seen this solution posted yet (in this thread), so I thought I'd mention it here.  THe problem appears for me when I create a project with Visual Studio 2005, and leave the "Create directory for solution" box checked.  I'm not exactly sure why this is the case, (or if this fact is related) but when this box is checked the default location for the manifest file is the "prj\prj\debug\" directory, while the default location of the executable file is "prj\debug\". 

    ((Is this bad? Is this getting at a root cause?))

    I've noticed that when I create the project and do NOT check the "create directory for solution" button, then I am able to debug without seeing the the "msvcp80d.dll not found" message. 

    When the project does not create a separate directory for the solution, then the X.exe and X.exe.*manifest* files get created in the same directory, and I am postulating that this is important. 

     

    Wednesday, August 16, 2006 1:27 AM
  • The manifest does need to be in the same directory as your EXE. However, the IDE will always create it there by default (whether or not you check the create solution directory).

    The IDE will also normally embed the manifest, so the external one won't matter.

    I suspect something else is going on in your scenario, though I am not sure what.

    If you want to report this as a bug and help us fix it, I recommend reporting throught the MSDN product feedback centre (http://msdn.microsoft.com/productfeedback).

     

    Thanks,

    Martyn Lovell

    Development Lead

    Visual C++ Libraries

     

    Wednesday, August 16, 2006 9:57 PM
  •  Ashan wrote:

    Hello,

    I have changed the "Properties Pages->Conf. Properties ->Linker -> Debugging-> Generate Map File" switch to Yes. Now the error does not occour and the app runs well. I do not know why. The map file dipicts sm'thing like this

    ".....
    0002:00001ea6 __CRT_RTC_INITW 00412ea6 f MSVCRTD:MSVCR80D.dll
    0002:00001eb0 ___report_gsfailure 00412eb0 f MSVCRTD:gs_report.obj
    0002:00002000 __configthreadlocale 00413000 f MSVCRTD:MSVCR80D.dll
    ....."

    I do not knoow for what or why this happened nor the meaning of a map file nor the crptic words init, please be kind enough to explain.

    Thanks a Billion

    Ashan

     

     

    I had the same problem... the above solution  fixed my problem.

    --VISUAL STUDIO INFO--

    Microsoft Visual Studio 2005
    Version 8.0.50727.42  (RTM.050727-4200)
    Microsoft .NET Framework
    Version 2.0.50727

    Installed Edition: Professional

    Microsoft Visual Basic 2005   77626-009-0000007-41620
    Microsoft Visual Basic 2005

    Microsoft Visual C# 2005   77626-009-0000007-41620
    Microsoft Visual C# 2005

    Microsoft Visual C++ 2005   77626-009-0000007-41620
    Microsoft Visual C++ 2005

    Microsoft Visual J# 2005   77626-009-0000007-41620
    Microsoft Visual J# 2005

    Microsoft Visual Web Developer 2005   77626-009-0000007-41620
    Microsoft Visual Web Developer 2005

    Crystal Reports    AAC60-G0CSA4B-V7000AY
    Crystal Reports for Visual Studio 2005


    SQL Server Reporting Services  
    Microsoft SQL Server Reporting Services Designers
    Version 9.00.2047.00

    -----SYSTEM INFO----

    OS Name Microsoft Windows XP Professional
    Version 5.1.2600 Service Pack 2 Build 2600
    OS Manufacturer Microsoft Corporation
    System Name JHERED
    System Manufacturer NVIDIA
    System Model AWRDACPI
    System Type X86-based PC
    Processor x86 Family 15 Model 43 Stepping 1 AuthenticAMD ~2210 Mhz
    Processor x86 Family 15 Model 43 Stepping 1 AuthenticAMD ~2210 Mhz
    BIOS Version/Date Phoenix Technologies, LTD 6.00 PG, 8/5/2005
    SMBIOS Version 2.2
    Windows Directory C:\WINDOWS
    System Directory C:\WINDOWS\system32
    Boot Device \Device\HarddiskVolume1
    Locale United States
    Hardware Abstraction Layer Version = "5.1.2600.2765 (xpsp.050928-1517)"
    User Name JHERED\Parnell
    Time Zone Central Daylight Time
    Total Physical Memory 1,024.00 MB
    Available Physical Memory 538.22 MB
    Total Virtual Memory 2.00 GB
    Available Virtual Memory 1.96 GB
    Page File Space 2.40 GB
    Page File D:\pagefile.sys

    Saturday, August 26, 2006 6:26 PM
  • Eric's solution works for me! I am here just to say: many thanks!
    Monday, October 02, 2006 9:11 AM
  • What does the "Use FAT32 workaround" actually do? Does it just add another mt.exe switch to the command line?

    -Tony

    Friday, November 17, 2006 6:11 PM
  •   Thank-You Martyn,

       Now thats a fix and explanation I can appreciate ! !  I am sure glad I looked through this discussion far enough to find this particular post. I have installed and reinstalled .NET Framework 2,   4 times with the same results everytime I run "Windoctor"! I tried downloading from different sites thinking maybe I got a corrupt download. The post on "downloading"      the dll sounded like a solution to me, the "WinDoc" does say "file msvcr80.dll not found" !

                        Thank-You Again,  BCnAZ

    Friday, November 24, 2006 6:31 AM
  • Super.  Much obliged.  Works a treat now after pulling my hair out performing re-installs, deletes and creating new projects...

    This is the only thing that fixed it for me...  (Using official 2005 express edition release on a FAT32 drive).

     

    Thanks again.

    Steve.

     

    Saturday, December 09, 2006 8:07 PM
  • Hi VC Team,

                    I am using VC++ 2005 XPress under windows XP, x86 system. After compiling I could not launch my program in debugger. It always crashes looking for "MSVCR80.dll" !!!!!!

    I have the following question:

    A. Why is it looking for MSVCR80.dll but not the debug version.

    B. None of the MSVCR80*.dlls exist under win/system32 directory.

    C. How can I fix this problem.   I already tried Nikola's suggestions above (with no luck.)

    D. How can I open an executable in VS?? as mentioned in the previous posting by Nikola?

    E. I deleted RES file as mentioned in another message and no luck.

    Sincerely,
    Venkata.

     

    Details of Microsoft Visual Studio 2005:
    Version 8.0.50727.42  (RTM.050727-4200)
    Microsoft .NET Framework
    Version 2.0.50727

    Installed Edition: VC Express

    Microsoft Visual C++ 2005   76542-000-0000011-00125
    Microsoft Visual C++ 2005)

    Saturday, January 06, 2007 11:50 AM
  •  

    Thanks Tom! I had the same problem and found that adding MSVCRT.lib to the "Ignore Specific Library" section of the Linker settings page fixed the problem for me.

    (I was porting a large VS6 C++/MFC app to the VS2005 compiler and could build and run the Release version fine but when I ran the Debug version I got an error about not being able to find MSVCR80.DLL.)

    Anthony.

    Monday, January 08, 2007 6:13 AM
  • Help

    I am trying to install nokia pc suite n80-1, but i have a runtime error or cannot find the msvcr80.dll and msvcp80.dll.  I am not sure if there any more to come but i cannot get passed these 2 first.  I have net frame 2 installed and my system is ntfs,  I do know that they are on the directory as i have seen them myself but the nokia suite cannot see them.  The msvcp80.dll however, the pc suite states that window defender cannot locate this.  Weird!!!

    Any suggestions....

    If i did need to reinstall them where toooo....

     

    Lisa

     

    Friday, January 19, 2007 9:21 AM
  • Hi Martyn,

    I'm very glad I found your message;  it has saved me a lot of potentially wasted time. Great stuff!

     

    Steve

    Friday, January 19, 2007 4:54 PM
  • hi,

    I have a private .dll with a manifest beside it. I am using /MD option while compiling. But as long as I dont copy the msvcr80d.dll and msvcp80d.dll to the system32 folder it is not able to find these to dlls ( as per dependency walker's output). I use gmake to build the project. I use a sample test file which uses my private dll. When I compile this test file I dont get any manifest along with it. Now even if I keep the dlls in the system32 folder and build the project and the try to run my test file I get the following :

    R6034

    An application has made an attempt to load the C runtime library without
    using a manifest.
    This is an unsupported way to load Visual C++ DLLs. You need to modify your
    application to build with a manifest.
    For more information, see the "Visual C++ Libraries as Shared Side-by-Side
    Assemblies" topic in the product documentation.

    I have tried to embed the manifest for my private dlls using mt.exe.  I new to the concept of manifests. So can any one help what all changes I got to do to make it work.

    Thanks

    _drp

    Thursday, January 25, 2007 9:24 AM
  •  feuerste wrote:
    Ok, same problem here:
    I created the exactly same visual studio project, once on an NTFS partition and once on a FAT32 partition. On FAT32 I get this strange "msvcr80.dll was not found" error, on NTFS I don't get it....
    Removing the .res file every time solves the problem, but is quite a hassle.

    However, here you go, this is the automatic solution:

    In the Visual Studio Project properties of the Manifest Tool, under General you can activate "Use FAT32 Work-around". Now everything works fine.

    I hope, I could help others desperately looking for an easy solution.

    Cheers,
    Marco

    Yes!!  This was EXACTLY the issue.  And I thought I was going mad!  lol  Who would have thought a filesystem work-around would be the correct thing for this issue!

    Thanks!


    Tuesday, February 06, 2007 11:19 PM
  • Hi there,

    I read every post in this thread without any help in my case.

    The problem turned out: The DEBUG version was trying to link with BOTH msvcr80.dll and msvcr80d.dll.

    Check if this is the case for you using the "dependency walker" on your executable. If these two are both loaded, then you got the same problem as I did.

    The solution is to set "Properties->Linker->Input->Ignore Specific library" to "msvcrt.lib".

     

    More details below:

    I was compiling and running a program that uses opencv library. One of the libraries in opencv (highgui to be exact) was linking with non-debug versions of some graphics libraries even in its debug version. Apparently this was OK before. 

    This resulted in my debug version program linking with both msvcr80.dll and msvcr80d.dll. It appears this is a problem since the manifest only mentions one of these libraries and the other one (msvcr80.dll) appears not to be found causing the error mentioned in this thread. Why no-one in this thread mentioned that this could be the case is beyond me. I found out about this using "dependency walker" on the .exe that I compile and/or the highgui100d.dll that I load from the library.

    That is the reason the complaint is about msvcr80.dll and not msvcr80d.dll in VS8!!!

    The fix is to re-compile highgui100d.dll (debug version) with Properties->Linker->Input->Ignore Specific library set to singly "msvcrt.dll".

    Just wanted to add this so other people do not waste time as I did...

    Hakan

     

     

     

     

     

     

     

     

    Sunday, February 11, 2007 3:00 PM
  • Just go to map c:\Program\MSN Messenger and delite the file msnmsgr.exe.manifest,
    Saturday, February 17, 2007 12:32 PM
  • I have butted my head against this problem over the past year and have usually been able to get by it.  However, now I find myself at a dead end.  I usually defeated this problem on my FAT32 laptop with the FAT32 work around flag.  However this time I am on my desktop which is NTFS and the flag obviously makes no difference, as I have tested this. 

    I have read through every post in this forum and can't seem to fix this problem.  Perhaps because I barely understand what is going on!  Wink

    In the top level debug folder I have the .exe file.

    I have three files in the lower level debug folder:

    MyMultiThread.exe.embed.manifest.res
    MyMultiThread.exe.embed.manifest
    MyMultiThread.exe.embed.intermediate.manifest

    This file MyMultiThread.exe.embed.manifest read as follows:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urnTongue Tiedchemas-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"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>

    I can't judge what I am supposed to do now that I know this information. Can either Nikola or Martyn help me with this error?

    Thanks,
    Scott
    Wednesday, May 02, 2007 9:52 PM
  • I'm having a problem like this, only the debug version is not involved at all.

     

    I recently converted an application compiled in VS6 to VS2005, and all seemed well until I got reports from some customers that it just was not working at all.  I've since been able to reproduce the problem and have traced it back to failing to find MSVCR80.DLL.

     

    I've got a clean version of XP SP2, with the VC Redist package installed on it, and my application installed.  Even though the manifest is properly embedded and the various DLL's appear to be in the correct place in WinSxS, it's not managing to find them.

     

    Any ideas on where to look next?  I've tried uninstalling & reinstalling everything from the OS on up on my test machine, but it stubbournly refuses to find those DLL's.

     

    On my development machine, I have no trouble at all.

    Monday, May 14, 2007 8:35 PM
  • Hi,

    I realize this thread is old, but I am encountering this problem in VS 2005 Express Edition and haven't been able to solve it.

    - I have an application that compiles and runs in release, but reports 'msvcr80.dll not found' in debug mode.
    - It has an embedded manifest referencing Microsoft.VC80.DebugCRT.
    - WinSxS contains msvcr80d.dll and msvcr80.dll in a directory matching the name, version, and public key in the manifest.
    - I have tried deleting all intermediate files and rebuilding from scratch, restarting the editor, rebooting, etc. many times without result.

    I don't understand why Windows thinks the DLL is missing; the manifest and everything seems to be in order.  Any help you can give would be appreciated.

    Thanks,
    Nathan Reed
    Sunday, May 20, 2007 10:26 AM
  • I just realized that I'm linking with a DLL that's built using the non-debug CRT.  So, I'm guessing this is being caused (somehow) by using the debug CRT for the executable that also links with a DLL using the non-debug CRT.  Linking the executable with the non-debug CRT even in debug mode works around the problem.  However, if I'm not mistaken the executable and the other DLL should be able to use independent copies of the CRT if they want to, so I'm confused as to why this should happen?  And also why the error message is so cryptic (if the problem is mismatched CRTs then it really shouldn't be reporting that it can't find the CRT at all!)
    Sunday, May 20, 2007 10:39 AM
  • To answer my own question...

     

    Turns out the trouble was that I was creating my program on VS 2005 SP1, and I was installing the "Visual Studio C++ Redistributable Pack".  What I really needed was the SP1 version of the redistributable pack.

    Tuesday, May 22, 2007 8:37 PM
  • Hi,

     

    There appears to be a *bug* in Visual Studio. The /outputresource under the Manifest Tool (under properties) is not being set. Simply select Release Configuration & copy from [Properties][Manifest Tool][Command Line] & paste it to [Properties][ManifestTool][Additional Options] of the Debug Configuration.

     

    -- Bill Shurtleff

    Wednesday, June 20, 2007 10:06 PM
  • I have a similar problem - crash on startup of my application with the message "msvcr80.dll not found".

    I have found many bugs containing "msvcr80.dll" as keyword on VS2005 site, but none of them was exactly about the problem I have:

    I am porting several big C++ applications (not MFC) from Visual Studio 6 to Visual Studio 2005 (Windows XP 32 bit). These applications use lots of external libraries, both static and dynamic.

    The Dependency Walker utility showed that the problem with msvcr80.dll comes from TCL, TK, TIX, and BLT dll libraries.

    I have compiled these libraries on the same computer with nmake. Following the guidelines for this case, found on

    http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx, I have changed the makefiles and recompiled the four dlls but the problem is stil there.

    I have noticed that nmake continued to produce external manifest files for each dll despite the modifications I have made in makefile.vc.

    Then I have used the mt.exe -manifest MyLibrary.dll.manifest -outputresource:MyLibrary.dll command and could obtain dlls with slightly bigger size than before, but the problem with msvcr80.dll not found is stil there. I have this problem with both Debug and Release configurations of our software. I am trying to start the application on the same computer, on which I am compiling.

    My executable, created with the IDE, is not in the default Debug folder, but somewhere else, because it needs special environment to be executed.

    When I linked this executable with TCL, TK, TIX, and BLT libraries, compiled on another computer with Visual Studio 6 compiler, the application started normally. This makes me think, that the problem is not in the project, created with the VS2005 IDE, but in the Tcl/Tk libraries, compiled with nmake.

    To compile Tcl\Tk, I have used the makefile.vc scripts supplied with TCL8.4 and BLT2.4 distribution.These makefiles work fine with Visual Studio 6.

     

    Can you suggest a solution or workaround for this problem?

    Is this an already reported bug and is there a patch of VS 2005 in which the problem is fixed?

     

    Monday, July 02, 2007 7:41 AM
  • I would like to thank you Martin as I have known for some time that the WinDoctor solution was wrong as it simply did not make sense.  I have noticed quite a few times WinDoctor has given a similiar response to other errors of this type.  I ignored it's advice as the solution did not make any sense.

     

    WinDoctor is a nice Utility but it needs some fixing as to many times it repairs a missing file by wanting to point to a similiar named file from another application especially in the case of shortcuts.  I still think it is a useful utility just be careful when using it and if you have any questions email Symantec so they can look at it and update the utility.

     

    I for the same reason do not use any registry cleaner as there is a tendency to use a broad solution for a given category of problems.

     

    Kelteel

    Friday, July 20, 2007 7:05 AM
  • One way to avoid the problem in Visual C++ 2005 is to us the C/C++ Code Generation option for "Runtime Library".

    For Release version, set this line to: "Muti-threaded (/MT)"

    For Debug version, set this line to:  "Multi-threaded Debug (/MTd)"

     

    All other Code Generation/Manifest defaults should be left unchanged. The MT option embeds the standard Win32 run-time in the exe so no external dll files should be needed.

     

    Dan Randolph

     

    Saturday, August 25, 2007 4:49 AM
  • It seems this manifest thing has everyone back in dll hell. I say you either embed the dll libray in the exe or copy the dll's to the same path as the executable. There is no good reason for doing it otherwise except to help Microsoft do their auto-update patches.

     

    Too much work about nothing for my simple cmd line executable as far as I'm concerned. And the wizard STILL has that pesky "Precompiled Header" option checked by default. At least there is an easy check to turn it off. Now how about NOT building the PDB by default in the release build so that when I run the debugger on the release build by accident, I don't get a bunch of nasty results in the debugger window. Setting up simple projects is such a pain with C++ and VS. No wonder everyone is switching to that nasty Java language.

     

    Dan Randolph

     

    Saturday, August 25, 2007 7:17 AM
  • I had the same problem. It all started when I started another debug and it needed to recompile my files. I noticed that I now got warnings that I had not gotten before (regarding strcpy being unsafe). So I went to the properties and pasted in the suggested define to disable those warnings. After I started the debug again I started getting the message. When I checked drive C msvcr80.dll was no place. Perplexed, I went to an old folder where I did a clean and started a debug on that and got the same message. I then made a brand new folder and copied just the .c and .h files (it was a small test program so not much to copy). Then built a brand new project ... that gave the same problem. Then I read Aner's solution which fixed the problem.

     

    I went to Properties->C++->Code Generation and changed from /MDd to /MTd and that fixed the problem.

    Friday, September 21, 2007 4:04 PM

  • YES! A solution at last. Thank you Anthony. I have a big old MFC dll I was compiling in vs2005: Multibyte characterset; MFC linked as a dll. I also have a small winforms client compiled with /CLR and MFC (dll) which calls methods in the big old dll. Was getting 'missing MSVCR80.dll' error messages on running the client even though everything was compiled for debugging. On closer inspection on the linker messages of my big old MFC dll, I saw this...
    LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
    Inserting MSCVRT.lib into the 'ingnored libs' settings for the big old MFC dll fixed the problem.

    Please note - nothing to do with manifests, nothing to do with installing other applications or any other solution suggested in this mammoth thread.

    regards.
    Tuesday, October 09, 2007 1:43 PM
  • Hi,

    I have a problem that is more than a bit frustarting. I have a collection of dlls (namely ORBacus dlls) which I managed to compile with VS2005. There exist a collection of programs in VC6. I should run these programs (ones in VC6) with the new dlls(Orbacus dlls compiled with VS2005).

    I've got the same sort of error messages  pointed out in this  thread.
    I've tested either manifast embeded in dlls, or separated from them. Although I knew that it would not work, I also tested dllls without any manifast at all.

    When I put these MSVC80 ... dlls beside my exe. An assertion with number R6034 will be presented to me saying that an application is trying to loasd a dll without its manifast. After that all things will go wrong.

    I've also tested all sorted possible solution suggested in this thread.

    Thanks in advance,
    Mohamad Ali Honarpisheh

    Thursday, October 25, 2007 9:41 AM
  •  

    Hey, my program builds and runs perfectly on Win XP. But when I run it on Windows 2000 Advanced Server, SP4 I get the missing dll error:

     

    "The dynamic link library MSVCR80.dll could not be found in the specified path".

     

    I searched for MSVCR80.dll on the 2000 box and it is present in some weird directory:

    C:\Program Files\Network Associates\ Common Framework \ Microsoft.VC80.CRT

     

    This is definitely /not/ one of the directory where it searches for .dll. Is this the problem of the system itself ?

     

    Is there anyway I can make sure that the program runs even on systems which do not have that dll ?

     

    I tried to build the application using /MT so that it does not depend on any dll. However, this gave me LNK2005 error such as: _malloc already defined in LIBCMT.lib and LNK4098 warning. If I choose to "ignore specific library: msvcrt.lib" the linker gives me lots of unresolved external symbol errors. (I am actually making use of statically linked pthreads library. I am just a newbie and dont know how all this works but I feel thats the reason I am unable to use /MT)

     

     

    Please help !!!  

    Friday, October 26, 2007 2:05 AM
  • Can anybody please help me !!
    Friday, November 02, 2007 2:29 AM
  • If the files are missing on a particular machine, you'll probably need to install this:

    http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en

    or this:

    http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en

    Tuesday, November 20, 2007 3:30 AM
  • I ran into a similar problem. I had Visual Studio .NET loaded and Visual Studio 2005 at the same time. Then I removed .NET. Now while debugging (using C) I get the message "This application has failed to start because MSVC80D.dll was not found".

     

    I did a search and found it here:

    c:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT

    But I think it needs to be somplace else for development (I think the above is for redistribution). Does anyone know where this dll needs to go?

    Wednesday, November 28, 2007 9:05 PM
  • I am experiencing the same problem. I am using Visual C++ Express 2005 on my Athlon XP 64 and curiously the manifest has this:

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

    I dont know why, but the manifest is being generated with 'x86' instead of 'amd64'.
    How can I fix it?



    Saturday, January 19, 2008 1:14 AM
  • Ok, I'm having the same problem with this.dll, I'm a "layman" when it comes to tech talk, don't understand all this VC++, is there an easier solution to this problem without having an engineering degree. It just seems if this problems is as common a as this forum makes it appear to be. Why hasn't someone developed a "Hot Fix" or something a long that line. For information purposes, I'm running a laptop with Vista Home Premium, Office Home and student and Office Outlook 2007 stand alone which the error message happened.

     

    Thank you

    C.W. Stacey

     

    Sunday, January 20, 2008 5:36 AM
  • I had a similar problem after building a dll. When I tried to register the dll, there was a message that it could not be loaded. Using Dependency Walker showed that MSVCR80D.DLL was not found. I cannot find this file anywhere on my system. The version of Visual Studio is Microsoft Visual Studio 2005
    Version 8.0.50727.867  (vsvista.050727-8600)
    Microsoft .NET Framework
    Version 2.0.50727

    Installed Edition: VC Express

    Microsoft Visual C++ 2005   76542-000-0000011-00125
    Microsoft Visual C++ 2005

     

    Thursday, February 14, 2008 12:12 AM
  •  steve thomas wrote:

    I had a similar problem after building a dll. When I tried to register the dll, there was a message that it could not be loaded. Using Dependency Walker showed that MSVCR80D.DLL was not found. I cannot find this file anywhere on my system. The version of Visual Studio is Microsoft Visual Studio 2005
    Version 8.0.50727.867  (vsvista.050727-8600)
    Microsoft .NET Framework
    Version 2.0.50727

    Installed Edition: VC Express

    Microsoft Visual C++ 2005   76542-000-0000011-00125
    Microsoft Visual C++ 2005

     

     

    Steve, your project is linked to the debug version of the C++ runtime. This DLL is not re-distributable, so if you try to use the executable on another system that doesn't have Visual Studio installed, you will get this error.

     

    The simplest way to avoid DLL dependencies is to use statically link the project by using the /MT switch. This pulls in all the code from the libraries and makes it part of your executable. The /MT switch can be turned on by "Project Properties", "Configuration Properties", "C/C++", "Code Generation", "Runtime Library" -> Multithreaded /MT.

     

    The OP can also follow these instructions.

     

    Brian

     

    Thursday, February 14, 2008 12:24 AM
  • My goof.... I didn't see this incredibly long thread! (That's one big disadvantage with these browser-based forums).

     

    Sorry for the wasted bandwidth.

     

    Brian

     

     

    Thursday, February 14, 2008 12:28 AM
  • OK, sorry, I've found it now, in Winsxs.

    I have a manifest, which I have included below.

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

    <assembly xmlns='urnTongue Tiedchemas-microsoft-com:asm.v1' manifestVersion='1.0'>

    <dependency>

    <dependentAssembly>

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

    </dependentAssembly>

    </dependency>

    </assembly>

    What else do I need to do?

    BTW, the processor on my machine is AMD64, not x86 as shown above?

     

    It is all working now! Sometimes it seems mt.exe is unable to embed the manifest, also I hadn't embedded the .def file correctly, so the exports were not visible.

    Thursday, February 14, 2008 12:50 AM
  • I had exactly the same problem: I have VS installed on C: and was keeping my projects on G: (other partition). That was the problem, i.e., when started to keep the projects under the C: partition everything worked well.
    Tuesday, March 04, 2008 1:36 AM
  • I had this error while building mozilla thunderbird with MSVC-2005 express.

    I had this problem with the xpt_link.exe, which fails to run if it is in the dist/bin directory, but ran fine in the original source directory...  After an attempt to reinstall MSVC, which was the wrong answer (WHY DOES MS SUGGEST THAT?), I copied the xpt_link.exe.manifest file into the dist/bin directory, and it worked. 

    I would certainly perfer that it had just said, "can not find xpt_link.exe.manifest".

    I guess the manifest's can be built-in to the .exe file, but this was not done.

     

    Wednesday, April 16, 2008 4:54 PM
  • Hi Nikola;
    I have a very similar issue. I am a Java developer and need to call some C++ functions found in a DLL by another company. I create the second DLL that serves as bridge between Java and the external DLL to handle the parameter and return type conversions. I run my Java application successfully on my development machine and able to call the native libraries I created that in turn call the other company's library. When I put the application on a different machine, it give the error that:
    "This application has failed to start because it is configuration is incorrect. Reinstalling the application may fix the problem". I have been following blogs and msdn help and done:
    1- Installed redistributable package for 2005,2008, and their service packs.
    2- Used depends.dll to find the DLL I am depending on(MSVCR80.dll for 2005 and MSVCR90.dll for 2008 version) and manually copied them int the same folder structure (created the folders).
    I do not know what to do. The only time I could run the app was after installing the Visual C++ version on the target machine.
    Do you have any idea where I am missing something. Your help is really appreciated.
    Thanks
    Kamal
    Friday, October 24, 2008 6:56 PM
  • Where can I find the .res files?
    Sunday, November 16, 2008 11:35 AM
  • hi,

    i had the problem "mfc80d.dll" not found.
    then i tried to copy the dll into the exe directory         -> R6034 ... no manifest ...



    the solution for me was to copied the generated manifest file from
    \somedir\projectname\Debug\Win32\projectnameD.exe.embed.manifest (projectdir\Debug\...)
    to
    \debug\win32\projectnameD.exe.manifest (my output dir for dlls, exe, ..)

    regards



    Thursday, November 27, 2008 2:18 PM
  • Hi All,

    I am using a liberary that works with /MD Switch, but when used with /MDd it throws Error R604 "Msvcr80.dll" Not found at runtime. I have attached the manifest.

    Is there anything i can use without changing the lib and use the /MDd Switch.

    Could someone help?

    Regards,

    Ajay
    Wednesday, February 11, 2009 6:50 PM
  •  Hello All:

    I use VS version 8.0.5xxx and am fond of cooking up DLL's which I call from Excel/VBA routines.  I've run into this exact problem recently which led me to this thread.

    In reading this, I decided to download Dependency Walker and with it as an aid, did indeed determine that no entry points were visible even though they were listed explicitly in a text file in the project.

    I did delete all versions of the MSVCR80D.dll file as was suggested and that didn't change anything.  In fact, in Dependency Walker, I found that, in a healthy, working dll, there were actually two versions of that file (in two separate directories) so I actually put a copy in the appropriate second directory for the problematic dll.  Whether the existence of two copies is a fluke or not I cannot say: I can only say that another dll worked just fine that way.

    I then went on to compare the project properties of the working dll with that of the problematic one, and, by doing this, was able to discover that, in the working dll, the property "Configuration Properties > Linker > Input > Module Definition File" was populated with the name of the text file that contained the entry point names, but that field was blank for the problematic one -- for some reason unbeknownst to me.

    So I populated the field accordingly and the debug version of the dll now works perfectly.  However, the release version still shows no entry points in Dep. Walker, and I'm at a loss to know why.

    FWIW....
    Wednesday, March 25, 2009 4:11 PM
  • does the manifest of your project show the same version as the msvcr80d.dll that you have?

    oh yeah, the project properties are different from debug to release so make sure the part where you put the module definition file is filled in in the release properties as well.
    Wednesday, March 25, 2009 8:50 PM
  • Not sure about the first part, but probably neglected the second.  Thanks.
    Thursday, March 26, 2009 4:42 PM
  • Ironically, there's not a mention of the dlls in the manifest, at least that I see.  Example:

    <?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"></assemblyIdentity>
            </
    dependentAssembly>
        </
    dependency>
    </
    assembly>

    Thursday, March 26, 2009 9:46 PM


  • I have somehow similar kind of problem,, i m preparing a dll,, for realease configuration it works, well, good and gets properly registered through regsvr32.exe. However when i generate a debug version of the same dll, it is generated properly & without any errors. But i m unable to register the debug dll. Registering the debug dll through regsvr32 pops the following error:

    LoadLibrary("____path of DLL___") failed - The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

    Checking the file with dependency walker, shows me three dlls missing:

    MSVCR80D.DLL

    Dependency Walker shows the following error in error log:

    Error: At least one required implicit or forwarded dependency was not found. Error: The Side-by-Side configuration information in "DLL PATH" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001). Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

    I have NTFS file system,, I guess i have some operating system relating problem,, and not with my development environment,, as i can register the same dll on another system (my laptop).

    MSVCR80.DLL is present in WinSxS path, but dependency walker shows it missing on path "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\MSVCR80D.DLL

    Can someone please help me to resolve the issue.
    Thursday, May 14, 2009 7:23 AM
  • Installing SP solved my problem.
    Friday, May 15, 2009 10:15 AM
  • I am also facing the similar problem

     we are using MSVC2005, and we are linking the MSVCPRTD.lib and MSVCRT.lib.

        As per my knowledge these two libs should handle the opening of msvcp80d.dll and msvcr80d.dll, since we are using MSVC2005. But actually these two libs are opening msvcp60d.dll and msvcrt.dll.

    Actually, the manifest file is creating by itself.

    We are using the option Generate Manifest  ---------- Yes.

    Manifest file contains nothing, like shown below

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
    <assembly
    xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0
    '>
    </assembly
    >


    issue: Our dll is building properly,
       After building it is containing a depedency with "msvcp60d.dll and msvcrt.dll"
       Which is not available in WinSxS folder, so unable to use the dll properly.

    Actually we are using msvcprtd.lib,msvcrtd.lib from wdk6001.18001.
    could any body tell me how do i get the msvcprtd(msvcp80d.dll), msvcrtd(msvcr80d.dll) in MSVC2005

    Regards
    Ramesh.




    I want to share about xps printer driver
    Friday, May 22, 2009 10:31 AM
  • I am also facing the similar problem

     we are using MSVC2005, and we are linking the MSVCPRTD.lib and MSVCRT.lib.

        As per my knowledge these two libs should handle the opening of msvcp80d.dll and msvcr80d.dll, since we are using MSVC2005. But actually these two libs are opening msvcp60d.dll and msvcrt.dll.


    For the benefit of others, Ramesh's situation is discussed in a thread created by Ramesh; see debug dll not working in xp.
    Sam Hobbs; see my SimpleSamples.Info
    Tuesday, May 26, 2009 3:39 PM
  • Go into the project properties page and then Select Configuration Properties> Linker> General
    Select the Enable Incremental Linking combo box  and select Default
    This should correct the problem.
     Why this is set automatically to something that does not work is unknown?

    Another solution I had found is a method on entirely erasing the operating system "Windows XP PRO" and visual studio 2005 then I had reinstalled it and now it works fine.
     Also try to keep in mind that the initial installation was a clean installation and no files were deleted or anything like that. This to me presents a huge bug and is associated with other bugs "It has a mind of its own".
    Also If you just copy the DLL into your program and distribute it, Well congratulations you just made yourself a target for a lawsuit. 
    • Proposed as answer by AllAroundAuto Sunday, February 14, 2010 5:31 AM
    • Edited by The HAMMER Wednesday, March 10, 2010 6:24 PM
    Thursday, February 04, 2010 10:54 PM
  • I Want to thank The Hammer for his excellant answer!

    Boy, what an embarrasing problem for microsoft!   This thread is 5 years old and still no update to fix this bug.

    I saw other fixes posted, such as using a FAT32 workaround option (that option didnt seem to exist in my version of VS) and modifing manifest and resource files, but The Hammers fix of changing the Enable Incremental Linking option to Default solved the 'MSVCR80D.DLL not found' problem for me. 

    Great job!

    Also want to 2nd his comment "Why this is set automatically to something that does not work is unknown"

    Im just a hobbyest, not a professional.  I have no idea what incremental linking is.   But I think default settings that simply dont work is typical microsoft.    Product testing, what's that?  We've never heard of such a thing.     Release updates to fix bugs?  Why would we do that?  If we perfect this version no one would ever buy the next version!

    Sunday, February 14, 2010 5:41 AM
  • Incremental linking is the ability to not link the entire file, but only replace the parts which were updated. This speeds up linking a debug application a lot. The funny thing is, switching incremental to default does nothing, the default for incremental linking for debug is set to on anyway.

    As for why it is automatically set to something which doesn't work and why it hasn't been fixed? Well you see, in all my time using VS2005 I never once had that problem. Most developers using VS2005 never had this problem. As I said earlier, the settings that it use ARE the default.
    Visit my (not very good) blog at http://c2kblog.blogspot.com/
    Sunday, February 14, 2010 8:34 AM
  • Martyn:

    Thanks so much for your very direct response as it relates to WinDoctor.
    So many others were talking about C++ or whatever, that were beyond my knowledge base, and I was only having the issue with Norton; so I appreciate you addressing that specific issue.

    Steve
    Tuesday, February 16, 2010 12:34 PM
  • When you buy a car does someone else have rights to it?
    Yes, in most countries the government has the right to:
    • Require the driver to be licensed
    • Require the driver to obey traffic laws
    • Require the automobile to have necessary equipment
    Also, in many states in America, and I assume in many countries, the driver must be able to show proof of financial liability in the event of an accident.

    It is totally reasonable that users of these forums be required to know what they are talking about. You don't understand how linking works yet you criticize it, which wastes people's time.

    Sam Hobbs; see my SimpleSamples.Info
    Thursday, February 18, 2010 9:14 PM
  • Hammer

    For the VC linker, setting it from yes to default means that it will decide what to use depending on the other linker switches.
    With /debug the linker will default to incremental linking anyway.

    If you test it out on a debug build of a program, look at the output after a full rebuild (or a clean). The one project I was using gave this output with Incremental set to Yes.

    1>------ Build started: Project: test2, Configuration: Debug Win32 ------
    1>Compiling...
    1>main.cpp
    1>Compiling manifest to resources...
    1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
    1>Copyright (C) Microsoft Corporation.  All rights reserved.
    1>Linking...
    1>LINK : d:\test2\Debug\test2.exe not found or not built by the last incremental link; performing full link
    1>Embedding manifest...
    1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
    1>Copyright (C) Microsoft Corporation.  All rights reserved.
    1>Build log was saved at "file://d:\test2\test2\Debug\BuildLog.htm"
    1>test2 - 0 error(s), 0 warning(s)
    ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

    With it set to default it gave

    1>------ Rebuild All started: Project: test2, Configuration: Debug Win32 ------
    1>Deleting intermediate and output files for project 'test2', configuration 'Debug|Win32'
    1>Compiling...
    1>main.cpp
    1>Linking...
    1>LINK : d:\test2\Debug\test2.exe not found or not built by the last incremental link; performing full link
    1>Embedding manifest...
    1>Build log was saved at "file://d:\test2\test2\Debug\BuildLog.htm"
    1>test2 - 0 error(s), 0 warning(s)
    ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

    Do you notice someting, in both cases it tried to incremental link. So this means that incremental linking gets triggered in both cases.
    Now, what this means is that at worst this isn't a case of the switches doing anything, but a bug in the linker (since it would require the abscense of the incremental switch to work correctly.)

    Oh, also there are only 3 settings for Incremental. Incremental (use incremental), Incremental:No (don't use incremental) and Default (not use the incremental switch). The IDE gives you the final option of inherit from parent but that is basically give the parent of the project the final word of what to use, so in the end it will be one of these three cases.
    Visit my (not very good) blog at http://c2kblog.blogspot.com/
    Thursday, February 18, 2010 10:38 PM
  • This is a re post!
    Go into the project properties page and then Select Configuration Properties> Linker> General Select the Enable Incremental Linking combo box and select Default This should correct the problem.

     This is also part of bug to do with file overwriting. Sometimes you have to delete the debug folder and recompile your code because the files had been corrupted this might have to do with one of the files being used by visual studio at the same time it is trying to re write them which cannot happen. It is like trying to delete a file while it is in use which you can not do.
    Also I had reformatted my hard drive and reinstalled Windows XP and Visual studio 2005 this had solved the problem which leads me to believe that the DLL may also get corrupted during installation judging by the 5+ hours of research I had done on this topic.
    Some people delete the DLL  and install a new file. This leads me to believe that what I had said is correct just by observing the facts of the situation and not relying on second hand information that is contaminated by personal opinion.
    Good luck: The Hammer
    Friday, February 19, 2010 5:57 AM
  • That is exactly the type of mentality that I avoid "It serves not Purpose" please stop responding to me I have better things to do.


    Then stop responding. No one will respond to you if they have nothing to respond to. Don't however tell others to not respond and then provide a long response.

    Please note that I am not Crescens2k; you seem to have me confused with Crescens2k.

    Sam Hobbs; see my SimpleSamples.Info
    Friday, February 19, 2010 6:31 AM
  • This is a good one I was ignorant enough to copy files them selves in to running folder.
    Whiter than the white is UV bright!
    Wednesday, March 10, 2010 6:10 AM
  • Thank you very much Hakan. You saved my day.

    I didnt find the solution for my problem initially but for some reason I wanted to search for this error with OPENCV in google and I found your post.

    Good work !!

    Saturday, May 08, 2010 6:50 PM
  • I have a NTFC partition and I was facing the problem when building and running in release mode. I made the changes suggested by you and it fixed the problem. Thanks. You really saved a lot of my time.
    Wednesday, June 02, 2010 9:43 AM
  • There is a lot of stuff not taken into consideration to this post?

    1. I have uninstalled and reinstalled visual studio 2005 and it works correctly now. "I had a hunch" LOL.

    2. Go into the project properties page and then Select Configuration Properties> Linker> General
    Select the Enable Incremental Linking combo box  and select Default
    This should correct the problem.
     Why this is set automatically to something that does not work is unknown?

    During the Initial installation I had "Before" visual studio 2005 installation encounters an error "MSVCR80.dll not found" so this leads me to believe there are some issues with the installation process this is very common with the installation of many programs as most of the installers for windows is somewhat faulty and leaves registry files left on the computer and other numerous files causing corruption to the operating system "ALWAYS HAPPENS".

    Another solution I had found is a method on entirely erasing the operating system "Windows XP PRO" and visual studio 2005 then I had reinstalled it and now it works fine.

     Also try to keep in mind that the secondary installation was a clean installation and no files were deleted or anything like that. This to me presents a huge bug and is associated with other bugs "It has a mind of its own".
    Also If you just copy the DLL into your program and distribute it, Well congratulations you just made yourself a target for a lawsuit. 

    Saturday, June 26, 2010 9:42 PM
  • Another email came in my inbox today. It is about Norton WinDoctor issuing errors about msvcr80.dll.
    Saturday, April 02, 2011 11:07 PM
  • for msvcm90.dll (visual studio 2008)

    http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=29

     

    and for msvcm80.dll (visual studio 2005)

    http://www.microsoft.com/download/en/details.aspx?id=3387

     

    At least that worked for me =)

    Friday, July 22, 2011 8:01 AM