none
"MSVCR80.dll not found" : Release only

    Question

  • I have a project that extracts data from a access database on my local drive. Originally the program used DAO but was recently converted to be using ADO for the extraction.
    The program worked in release and debug before when it was on DAO. The program runs fine in debug after the switch over but recently was tried to run in release and the MSVCR80.dll not found error pops up.

    I receive the following "Linker Tools Warning LNK4098 defaultlib 'library' conflicts with use of other libs; use /NODEFAULTLIB:library"

    I believe this warning stems from me using the ADO dll below.

    #import "c:\Program Files\Common Files\System\ADO\msado15.dll" \
    rename("EOF", "EndOfFile")

    Since the program works in debug I think the problem is that I am not using the correct ADO dll for running in release, however I am not sure if that is the problem. If it is the issue, I'm unsure of how to find the proper .dll

    This is not a widespead issue, as I am able to compile and run other projects in release mode. I am running Visual Studio 2005 on Windows XP. If any other information is needed please let me know, Thank you for any assistance!
    • Edited by Draznar Tuesday, February 10, 2009 5:10 PM Updating Information
    Monday, February 09, 2009 9:14 PM

Answers

  • In your "Release" configuration, make sure your settings in C/C++ code generation for Runtime library are multi-threaded DLL and not multi-thread debug dll, and make sure _DEBUG is not defined in the "Release" configuration.

    • Marked as answer by Nancy Shao Monday, February 16, 2009 11:19 AM
    Sunday, February 15, 2009 3:57 AM

All replies

  • First have a look at the following in case it helps.

    http://social.msdn.microsoft.com/Search/en-US/?query=LNK4098%20MSVCR80&ac=3
    Sam Hobbs; see my SimpleSamples.Info
    Wednesday, February 11, 2009 9:03 AM
  • I ran a program called dependency walker on my release .exe and it did find two issues.

    It can't find MSVCR80.dll or this mysterious one I have never heard of DWMAPI.dll. I did a search on my system and MSVCR80.dll is on my system in multiple folders, but this DWMAPI.dll is not on my system, so that is obviously a problem. A quick google search for this DWMAPI.dll seems to indicate that this .dll is a Vista specific .dll. I am perplexed why my project would be dependent on such a .dll

    Also as an experiment, I copied MSVCR80.dll into my project folder and ran it. When I do this i get a different error, maybe this is link with the DWMAPI.dll. The box just says Runtime Error! Lists the file path to my .exe and then says, "R6034"

    I forgot to mention is earlier and I'm not sure if this is relevant but my project is using COM. I'm still a bit lost so any further advice would be appreciated.
    Thursday, February 12, 2009 3:04 PM
  • During my investigation I've come across that something could be wrong with my manifest file.  Posted Below is a copy of my "MyProgram.exe.embed.manifest",   It seems odd that this mentions debug, could my manifest file be wrong?  I have never messed with these before.

    <?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.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.DebugMFC" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>
    Thursday, February 12, 2009 3:58 PM
  • Draznar said:

    A quick google search for this DWMAPI.dll seems to indicate that this .dll is a Vista specific .dll. I am perplexed why my project would be dependent on such a .dll

    I think if you search a little more you will discover that this is normal. I think that DWMAPI.dll is used when it is available (in Vista) but it is not required. I think I recall researching it for someone else; that name seems familiar becasue MAPI is the acronym for the eMail API but that DLL is not for email.

    Draznar said:

    Also as an experiment, I copied MSVCR80.dll into my project folder and ran it. When I do this i get a different error, maybe this is link with the DWMAPI.dll. The box just says Runtime Error! Lists the file path to my .exe and then says, "R6034"


    This is probably why use of Depends is bad advice for situations such as this. Many runtime DLLs cannot be simply copied. Unless there is documentation or you have other instructions from Microsoft, don't try shortcuts such as that. If you do, you are likely to make things worse and if you then ask for help and don't mention you have tried to fix problems in an undocumented manner then that can waste everyone's time.

    I know there is a lot to read. If you did not look at the relevant results from my search and you copied the DLL as a shortcut then you are more likely to solve the problem if you spend a few minutes reading.

    When you try undocumented solutions such as copying a runtime DLL, be sure to keep track of those things so you can undo them when things don't work.


    Sam Hobbs; see my SimpleSamples.Info
    Thursday, February 12, 2009 5:47 PM
  • I had never used Depends before, it was advice given to me by another posted on a different coding help forum.  Also, I only copied the MSCVR80.dll just as a quick experiment, it was never intended to be the end solution.

    I thank you for the search results but I had gone over them  All the solutions I find are either,:
    1) Something is wrong with your manifest file, which doesn't seem to be wrong however I am fuzzy on this.
    2) Change code generation from /MD to /MT, but that's a no go since I am using the afx .dlls.
    3) an issue for being on FAT32, but im on NTFS so no issue.
    4) Repair Visual Studio 2005, I haven't done this yet but I am about to.

    Thank you for you advice / direction thus far.
    Thursday, February 12, 2009 6:21 PM
  • And thank you for not taking my comments too personally. My response is significantly motivated by past experience in which people try solutions that just make things worse.

    I do understand the tempation to try things out of desperation. I do that too.

    If it is possible that there is something in the project that you have modified and do not realize it is a problem, something else you can try is to create a new project and copy the source code files into the project. It is important that for this you don't use the existing project and solution.

    Just to be sure I understand, is this all for one system? Is this all happening in your development system?
    Sam Hobbs; see my SimpleSamples.Info
    Thursday, February 12, 2009 7:46 PM
  • Fear Not! I take nothing personally, I just want to get my code to work.

    I haven't tried putting the source code into a new project, Ill give that a shot and see what I get.

    Eventually, this will be built on other machines, but right now this is all on my development machine.  I have tried taking this and running it on other development machines and I get the same issues from what I can tell.
    Thursday, February 12, 2009 7:54 PM
  • Update:  I made a new empty project and put all my source code in there.  I made a few changes for it to compile.  I am not the original author of this project, I just made the update/change from DAO to ADO. 

    After I got it all in the new empty project, I could not compile in /MD but I could successfully compile using /MT in release.  But after adding in #define _AFXDLL I could compile both ways.  I'm not sure which method is the "correct" way.  So I guess this means there is something in my original project / solution settings that are messed up.  I guess Its time to go through one by one to track it down?  One thing that I notice is different is the RT_MANIFEST when I open the .exe in VS2005. 

    [New Project RT_MANIFEST made from empty solution]
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>

    [Original Project RT_MANIFEST]
    <assembly xmlns="urn:schemas-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"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.DebugMFC" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>

    I had tried to edit the original manifest earlier but it didn't seem to make a differnece so I dissmissed it.  Now I think that may be the root of the problem.   I don't know why the original project manifest keeps generateing DebugCRT and DebugMFC.  Perhaps if I figure that out I will have my final answer...

    This has been very informative! The idea to try a new project was great. 
    Thursday, February 12, 2009 9:46 PM
  • In your "Release" configuration, make sure your settings in C/C++ code generation for Runtime library are multi-threaded DLL and not multi-thread debug dll, and make sure _DEBUG is not defined in the "Release" configuration.

    • Marked as answer by Nancy Shao Monday, February 16, 2009 11:19 AM
    Sunday, February 15, 2009 3:57 AM