I am using Intel TBB C++ for multithreading an application on visual studio 2008. When I run the executable I get a dialog saying "MSVCP80D.dll" was not found. There is so much on the net about this that it confuses me.
Please help.
EDIT: Based on answers, finally I was able to fix the "dll missing" problem. I had given a path to TBB lib of vc8 leading to dependency on vc8 dlls, which are used with visual studio 2005, not with 2008. (Using depends (http://www.dependencywalker.com/ ) it is easy to determine the run-time dependencies of an executable.) I changed by project to depend on vc9 dlls, not vc8 and then it worked fine.
Another thing to note is use of manifest files on windows. Manifest files describe dependencies. The manifest files must be generated while writing an application as it is necessary.
You can find them online at various places. Just scan it for a virus and put it in your program's path and everything should work fine. You may need more than one of the debug dlls, you can use depends32.exe to see what you are missing.
MSVC80D is VS 2005. As part of VS2008 you would have MSVC90D instead.
Your app is compiled with debug version. Debug version of VC runtime is not in path.
Try to generate release version.
Are you running the program on your development machine? If you are not, you might get this error. The "D" at the end of the filename means that the DLL is a debug DLL, and often not on computers without Visual Studio installed. You're not supposed to redistribute it (copy it around), either. You should compile a "release" version of your application and run that. If you really can't do that for some reason, and it's only one or two computers, then try installing the express version of visual studio on that computer.
If you are having this problem on your development machine, it can apparently be caused by a compiler/linker problem. Try doing a clean build ("clean", then "build" in Visual Studio).
Ok, after a lot of search, and by chance, I landed on this forum http://www.codeguru.com/forum/showthread.php?t=446789 which says something I interpret as "the version of TBB I am using does not support VS 2008".
But this still uncertain.
Related
I cooperate on a game project in cocos2dx. I do not code, rather work on scenes in Cocos Studio. When I've tried to run .exe build in proj.win32/Debug.win32 it started to throw errors about missing .dll. I've downloaded them as it was requesting them (msvcp140d.dll, vcruntime140d.dll), but I cannot find appcrt140d.dll anywhere.
What would you recommend me to do?
I've tried to install C++ Redistributables without any effect.
The d suffix there means that this is a debug version of the DLL. Which makes sense—like you said, it was compiled as a "Debug" build, which is going to use a special debugging version of the C runtime library designed to help you catch errors.
You aren't supposed to release debugging versions of your applications for general use. In fact, Microsoft doesn't even make the debug versions of its runtime DLLs available. They are considered "non-redistributable." That's why you aren't getting them when you download and install the C++ Redistributables. All you get are the release versions of the DLLs.
If you are not a programmer, you will probably not find a debugging build particularly helpful. The error messages won't mean anything to you, and the extra error-checking code will just slow things down. Unless your friend the programmer has specifically asked you to help him debug his program, then you should ask him for a release build. That way, all you'll need to install is the appropriate version of the C++ Redistributable (version 14 → VS 2015).
If you want to run the debugging build, you'll need to obtain the non-redistributable debug-only versions of the runtime DLLs from your friend. They are installed with Visual Studio. He should know where to find them. If not, tell him to look in his Visual Studio directory (under the Program Files directory), in \VC\redist\Debug_NonRedist\. Copy the required DLLs to the same directory as the EXE and you'll be in business.
Those are debug versions of the runtime environment. They are normally installed when you install Visual Studio 2015. If you do not want to do that, you can find more instructions on how to proceed here: https://msdn.microsoft.com/en-us/library/aa985618.aspx
I'm building a pure Win32 program (no clr or any assembly) by VC 2012 (VC 2012 (VC11) as my compiler). It uses boost 1.58, wxWidget 3.0.2 series,gsl 1.8, jsoncpp, Open CV 2.4.10, etc... The development box is running Win7 64bits. I would like it to be a single executable and is able to run on both Win 7 32/64 so I built all of the above packages as libs myself by the same VC 2012. (thanks for cmake)...
It works fine on development box but not on a clean one that only installed VC redistribution packages. I got the error message box ask me to use the sxstrace and the message in event log has side-by-side error like below and I also tried the sxstrace and got similar error.
"D:\Release\xxxx.exe" 的啟用內容產生失敗。 找不到依存組合 Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"。 請使用 sxstrace.exe 進行詳細的診斷。
I've been searching around. All and answers simply says I should use all release build for all libs. Yes, it's true if I didn't I couldn't have the single executable at first place. It won't be able to link. (I learned it by made lots of mistakes) I've tried both MD or MT build for my program (not mix them together. They are separated test.). Either of the mode works. The same error remains. I've also installed over lots of VC2008 9.0.21022, -.30729.17, -30729.4148, -30729.6161, VC 2010 10.0.40219, VC 2012 11.0.61030 (x86/x64)
I really don't understand. It's pure win32 release build made by VC 2012. How come it requires VC90 debug dll?
I'll really appreciated if someone can give me more precise advice about how to resolve or even determine where and what goes wrong with the code or the lib I build.
I will suggest that you use the following tool: Dependency walker.
By loading your executable on your PC (where it works) you should find out all the DLLs it uses and so discover any hidden dependencies in the (medium sized) library list on which your project depends (and in turn their dependencies).
This should help you point out DLLs that you have on your PC but not on freshly installed machines.
A pure Win32 release build should not depend on DEBUG CRT dlls, that's for sure. The only project setting to control that is basically that MT/MD ("Runtime Library") setting. You want MT.
I would guess that you have the Debug CRT dll referenced somewhere in the source code (e.g. one of the libraries requires it to be linked in for whatever reason, maybe because there is #define DEBUG or something, thus overriding project settings.
You could try searching #pragma comment(lib, ...bla-bla-bla...) in the source code.
It's resolved by myself. The project is about migrating a big legacy project. So there's a very small lib built by VC90 without source code. So be a detail person is the key to do this kind of job.
I have a Visual Studio 2008 (SP1) program, debug build, 32bit, that can't seem to find the debug runtime DLLs (multithreaded debug DLLs).
But the crazy thing is, depends.exe shows the requisite DLLs as being present (and also missing). It actually looks like it's trying to load those DLLs twice.
Below is a link to a screenshot from depends.exe showing what I'm talking about - analysing a library that is part of the solution.
When I launch the program, I get "The program can't start because MSVCP90D.dll is missing from your computer. Try reinstalling the program to fix this problem."
If I go into the sxs directory and copy the "missing" DLLs into the same directory as the binary, the program runs.
The application manifest specifies the correct DLL versions (as evidenced by them being found by depends.exe). I've checked the manifests of that version of the runtime, and to my untrained eye it looks legit.
The binary itself shows the same problem as the DLL examined in the linked image, but also with MSVCP90D.DLL missing (and yet present).
I've tried building with internal/external manifests, turning incremental linking off and on, as suggested elsewhere, all to no avail. I would try linking a non-DLL runtime, however the libraries I am using are shared across many tens of solutions, so changing the way they are built isn't really an option (unless of course that turns out to be the only solution due to a known issue that my googling didn't turn up).
I've tried running sxstrace, but most of the time the output is empty (!), when it isn't empty it shows no errors.
I tried using windbg, but got nowhere as I'm not particularly experienced with the tool and wasn't sure what I was looking for.
I'm running on 64bit windows 7. One of my early thoughts was that having VS2005, 2008 and 2010 all installed on my box was causing some weird issues, but I've found no evidence to support that supposition.
(PS. Looks like similar issue as msvcp90d.dll is missing msvcr90d.dll which as far as I can see didn't actually get solved, and also mentions C# - my project is pure C++).
PPS. Looks like similar issue as "application configuration is incorrect" and "side-by-side configuration is incorrect" running VS2008 64-bit debug build
However that problem was related to 3rd party libraries and 64 bit builds.
In addition the "solution" to copy the "missing" DLLs manually from SxS to the bin directory (which as is mentioned above does the trick) is not a solution at all - at best it's a work-around.
The redisributable does not include the debug DLL files. You need to install Visual Studio to get them.
"Debug versions of an application are not redistributable and none of the debug versions of the various Visual C++ dynamic-link libraries (DLLs) are redistributable. Debug versions of an application and Visual C++ libraries can only be deployed to another computer internal to your development site for the sole purpose of debugging and testing your application on a computer that does not have Visual C++ 2005 installed."
Here is the topic on msdn about runing debug builds "Preparing a Test Machine To Run a Debug Executable" (solutions and examples are provided):
http://msdn.microsoft.com/en-us/library/aa985618(v=vs.90).aspx
You can choose your version of visual studio (from 2005 up to 2013).
Ok , so i created a program using VC++ 2010. it ran just fine.
Got to work and could only install vc++ 8 due to having a crappy computer that is still stuck on xp sp2...
Everything will link up and build with no errors, But when the program starts to run i get "This application has failed to start because MSVCR100D.dll was not found"
I tried changing the runtime libary from MDd to MTd but still no luck...any idea?
That DLL comes with Visual Studio 2010. If you want to use your program, you'll somehow have to get your hands on it. If possible at your work, you can download it. Another (probably better) option would be to take it with you from home on a USB drive.
Edit: You can also try re-creating the project, and then copying the source code over into the new project. Your newly created project (in Visual Studio 2008) should not be depending on that erroneous DLL.
Edit 2: As Hans Passant added in a comment, this DLL is needed by Debug compilations of your program. So if you simply compile as Release, you can safely ignore the first part of my post. (I hope I'm not breaking gentleman rules by adding this to my post.)
MSVCR100D.dll is for debug mode, and is installed with visual studio 2010, since 2008 has MSVCR80D. You can just google that and download it, and put it in the same direcrory, or just complie in release mode.
here is a download link. You need the small download zip file button, not the big ones.
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d
As I know, MSVCR100D is debug version of runtime library used by VC2010。So, if your point either is:
(1) you do not have that dll which you really need, you can download at http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d or
(2) you want to run that program without requirement of MSVCR100/D.dll, you may need to recreate a project in VC8, then substitute with your source files (not solution file or other files managed by Vistual Studio).
FYI: If my memory were not going wrong, I remember that a project created by higher version of VS cannot be opened directly by lower version one. So, how did you build them?
My C(++) program, written and compiled using Visual C(++)/Visual Studio, runs fine on my own machine, but refuses to run on another machine. The error message I get is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
If you write a C++ program, it links dynamically to the C Runtime Library, or CRT for short. This library contains your printf, your malloc, your strtok, etcetera. The library is contained in the file called MSVCR80.DLL. This file is not by default installed on a Windows system, hence the application cannot run.
The solution? Either install the DLL on the target machine through VCREDIST.EXE (the Visual C++ Redistributable Package), or link to the CRT statically (plug the actual code for the used functions straight into your EXE).
Distributing and installing VCREDIST along with a simple application is a pain in the arse, so I went for the second option: static linking. It's really easy: go to your project's properties, unfold C/C++, click Code Generation, and set the Runtime Library to one of the non-DLL options. That's all there is to it.
The problem here is a missing DLL dependency, such as the CRT (C Runtime Library). A good tool for diagnosing this sort of problem is Dependency Walker (depends.exe), which you can find here:
http://www.dependencywalker.com/
You would run this program on the computer that generates the error message you posted, and use it to open the exe that's generating this error. Dependency Walker will quickly and graphically indicate any DLLs that are required but not available on the machine.
Chances are high that you miss the runtime libraries of Visual Studio (CRT amongst others), you can either get rid of those dependencies (link statically) or install the VC redist packages on the target computer.
Depending on the Visual C++ version you use, you have to install different packages :
Visual C++ 2005
Visual C++ 2005 SP1
Visual C++ 2008
Warning : those packages only contain release versions of the libraries, if you want to be able to distribute debug builds of your application you'll have to take care of the required DLL yourself.
It is much the simplest to link to the runtime statically.
c++ -> Code Generation -> Runtime Library and select "multi-threaded /MT"
However, this does make your executable a couple hundred KByte larger. This might be a problem if you are installing a large number of small programs, since each will be burdened by its very own copy of the runtime. The answer is to create an installer.
New project -> "setup and deployment" -> "setup project"
Load the output from your application projects ( defined using the DLL version of the runtime ) into the installer project and build it. The dependency on the runtime DLL will be noticed, included in the installer package, and neatly and unobtrusively installed in the correct place on the target machine.
The correct VC Redist package for you is part of your Visual Studio installation. For VC 8, you can find it here:
\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
POSSIBLE SOLUTION........
EDIT: (removed most of my post)
Long story short, I was having similar problems, getting the "Application Configuration Incorrect" messages, etc etc.
Depends.exe was only finding ieshims.dll and wer.dll as possible issues, but this is not the problem.
I ended up using the Multithreaded (/mt) compile option.
What HAS worked though, as a workable solution, is making an installer with InstallShield.
I've selected several merge modules in installshield builder and this seems to have fixed my problem. The modules selected were:
VC++ 9.0 CRT, VC++ 9.0 DEBUG CRT, and the CRT WinSXS MSM merge module.
I'm pretty sure its the WinSXS merge module that has fixed it.
DEBUG CRT: I noticed somewhere that (no matter how hard I tried, and obviously failed thus far), my Release version still depended on the DEBUG CRT. If this is still the case, the InstallShield merge module has now placed the DEBUG CRT folder in my WinSXS folder :) Being somewhat of a novice with VC++ I assume that this would normally be used to distribute debug versions of your programs to other people. To test if this is what fixed my problem I removed the DEBUG CRT folder from the WinSXS folder and the application still worked. (Unless something is still running in the background etc etc - I'm not that into it)
Anyway, this has got things working for me on an XP SP3 fully updated machine, and also on a VMWare XP SP3 machine with the bare bones (.net 3.5 and VC++ 2008 RTM basically) - and also on a mate's XP machine where it previously wasn't working.
So give these things a try, you might have some luck.
First thing you must use
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
or add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the preprocessor directives.
The problem is related to binding and the manifest types, you can find more http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/
By doing this your application will run with a larger range of runtime libraries versions.
Often times this error is the result of attempting to run the debug version of an application that uses .NET. Since the .NET redistributable package doesn't include the debug versions of the dlls that are installed with Visual Studio, your application will often get this error when running it on any other machine that doesn't have Visual Studio installed. If you haven't already, try building a release version of your application and see if that works.
Note also - that if you change to static runtime, you will have to do the same for MFC if your app uses MFC. Those settings are in properties->Configuration/General
I ran into this problem and was able to fix it very simply.
Visual studio gives you the option (on by default) to build a manifest for each build.
The manifest was put in the release folder, but it was a different release folder than the exe.
Even when using the setup utilities it was not packaged.
You should look for a file names something like myprogram.exe.indermediate.manifest
If this is in the same folder as the exe (and you have all the dlls) it should run