I have a mfc c++ project on vs2010.
I am able to build it in both debug & release mode , but when I run it in debug mode, it gives the follow mfc100d.dll error. I have also installed C++ runtime environment vcredist_x86.exe still the issue is not fixed. Also I have set the Multi-threaded DLL (/MD) as the Runtime Library.
How do I fix it ?
The d suffix on the name of the DLL indicates that it's a debug version of the runtime DLL. That's confirmed by the fact that you say the problem happens when you try to run the debug version of the application.
By default, and for good reason, debug builds link to debug versions of the runtime libraries. These versions are not redistributable, and thus are not getting installed with the redistributable package (vcredist_x86.exe). That's not normally a problem: you aren't supposed to ship debug versions of your application.
The non-redistributable debug libraries are, however, installed with Visual Studio, so the debug version of your app should run fine on the computer you used to develop and build it. Which is likely the same computer you're going to use to debug it.
Also I have set the Multi-threaded DLL (/MD) as the Runtime Library.
Three important things to note about this:
You have to make sure that you set it for the correct build configuration (i.e. "Debug").
This is not recommended. Debug builds of your application should use the debug versions of the runtime libraries. They do a lot of things behind the scenes that help you to catch bugs. That's why they exist. If you don't want a dependency on the debug version of the runtime libraries, compile and distribute a Release build of your application.
That switch changes the version of the C/C++ runtime library that your application links to. The DLL you're getting the error message is an MFC runtime library.
The MFC headers test whether the _DEBUG preprocessor symbol is defined in order to determine which version of the runtime libraries should be linked in. Since _DEBUG is defined automatically in a debug build, it's linking in the debug version of the MFC libs.
To change that, you're going to need to do a lot of manual labor, undefining this symbol before you include the MFC headers, and then re-defining it afterwards.
Alternatively, you can statically link to MFC, which is a setting in your project's properties. But do be careful with this: you'll end up inadvertently mixing versions of the CRT, which can leave you in a world of hurt. Better to just ship release versions and keep debug versions for internal debugging.
Reinstalling the Microsoft SDK fixed this error.
Related
I was working on a MS Visual Studio project and noticed that the Debug build was Linking to a Release library (DLL), when a Debug library with the same name was also available. I switched the path to Link the Debug library, and it seems to still work. Is there any way to know if my change was correct?
Additional Information:
Using the debug DLL triggers a small memory leak that wasn't triggered with the release DLL. Or possibly that is debug related cache data. That leak made me question if it was including the lib headers without _DEBUG somehow. Thus this question.
It is the preferred way to link Debug builds of your program with Debug version of external dynamic libraries as it guarantees that uniform Visual C++ runtime libraries will be used. Mixing libraries built in Debug and Release mode will result in both Debug and Release VC++ runtimes being linked and annoying linker warnings about multiple symbol definitions in conflicting Debug/Runtime libraries.
Sometimes it may be inevitable as i.e. only Release version of some external library may be available. Hence in VC++ there are linker settings allowing to ignore some specific libraries. So you may start checking in the Linker-Input settings of the Debug build if such ignores are already defined for existing conflicts. With some luck you might be able to remove them now.
If using the Debug version of some library breaks the whole program it might be an insight how to improve the whole system, it is that what a Debug build is for anyway.
Assuming that it is the right library (as in the same code compiled to a different configuration), you are right to link to the debug dll on your debug configuration (and should link to the release dll on your release configuration).
The differences tend to be related to the optimisation level (Debug is usually compiled without any optimisation at all) and any symbols that might be included to make it easier to develop with and maybe step into.
I'm trying to make a binary that can be run on any windows machine without the visual c++ stuff installed (I'm assuming that's what MSVCP120D.dll is however my searching was not very fruitful as to what this actually is). I made a game for an assignment and wanted to have other people (non-devs without VS stuff installed), help me test it but they kept getting errors saying that the above dll is missing. I'm not using any Visual C++ stuff and have the /Za flag set to ensure that it's just ANSI C++. Does Visual Studio support compiling ANSI C++ and if so how do I go about making it not use Visual C++ stuff, if it doesn't support this what compiler should I use?
As you can see here, the MSVCP DLL is the platform's implementation of the C++ Standard Library. In short what that means is you cannot distribute your application without needing the "stuff" that these libraries provide. All compilers regardless of platform would need some kind of implementation of the Standard Library. Typically this is distributed in the form of libraries.
However you can distribute your application so that the "stuff" is built in to your program directly, rather than being shipped in a separate DLL. In order to do this, you must statically link your application to the Standard Library.
There are a few ways to accomplish this. One way is in Project Settings. In "Project" > "Configuration Properties" > "C/C++ Code Generation" > "Runtime Library", choose "Multithreaded (/MT)" as opposed to "Mutithreaded (Static)".
By the way, the "D" in "MSVCP120D.dll" you mentioned above means "Debug." This means that you are trying to distribute a debug build of your program. You should (almost) never do this. Distribute release builds instead.
You have three options (in the order I'd recommend):
Don't statically link, instead get people that want to run your game install the visual studio re-distributable package. 32-bit VC 2010 version here: http://www.microsoft.com/en-us/download/details.aspx?id=5555
Statically link the CRT (the dll you don't want to require at runtime) see here for details: How do I make a fully statically linked .exe with Visual Studio Express 2005?
Build an app that doesn't even use the CRT at all. Here you will have to implement your own operator new that calls HeapAlloc(), and operator delete that calls HeapFree(), its an interesting challenge ;). To do this you tell the linker to ignore all default libs.
Build with the static runtime libraries rather than the DLL versions.
Go to Properties, C/C++, Code Generation, Runtime Library and select /MTd or /MT rather than the /MDd and /MD options.
Configure your project to link against the runtime statically rather than dynamically.
First of all the D on the end of the name indicated a debug build. If you make a release build then it will need it without the D. This is important because microsoft do not allow the debug libraries to be distributed without visual studio.
The machine you are trying to run the program on may already have the release runtime installed as lots of programs use it. If not then install http://www.microsoft.com/en-us/download/details.aspx?id=30679 on the machine ( I think that's the right one but can't check at the moment)
You'll want static linking, that 'builds in' the external library calls into your binary. It does have the added affect of larger binary file, but in your case that doesn't sound like that big of a deal.
On a side note, MSVCP120D.dll is the Microsoft Visual C++ 12 debug DLL (dynamic link library) that contains all of debug C++ libaries (i.e. iostream, string, etc). That library is what you would be 'baking in' to your final binary.
Hope that helps.
I encountered this error when I tried to execute my exe on a different machine that had a newer version of Visual Studio on it. You need to change the project properties and re compile in order for this to go away.
To do this:
Open up solution that you are trying to run
Right click on the Project file - > Properties
In Configuration Properties and General, Ensure Platform Toolset is configured to be the correct compiler on your machine. If it is not correct, it should give a message next to it saying that it's not installed.
Build and run the code again and you should no longer get the issue.
I am new to C++ programming and had just finished making a simple calculator. I decided to share it with my friends and after several attempts figured out how to compile it in release mode. However, even in release mode it is still dependent on the MSVCP110D.dll. I was wondering if there was a way to fix this?
1) MSVCP110D.dll is the runtime .dll for the "Debug" version of the MS C Runtime Library. So it looks like your .exe might not have been built for "Release" correctly after all.
2) Here is information for the "Visual Studio Runtime Redistributable":
http://www.microsoft.com/en-us/download/details.aspx?id=30679
3) Here is more information on this particular problem:
http://social.msdn.microsoft.com/Forums/en-US/Vsexpressvc/thread/e128dff6-cef5-4a81-b6de-fcbcaa7a23bb
Unfortunately the msvcp100D.dll is a debug dll and it isn't included
in the Microsoft Visual C++ Redistrutable package. This is becouse
normally debug version aren't release to other than developer.
Developer have installed it by default with Visual Studio.
You can compile your project in "Release" so all dll which you'll need
will be included in the Microsoft Visual C++ Redistrutable package.
Otherwise you can do the static link of all libraries(specify /MT in
Release and /MTd in Debug configuration into compiler options): but
personally I don't recommend it becouse you put in the executable many
information(used by the debugger) which will slow down your app.
I am guessing your issue is with dependency on the debug version of the dll & not the dependency on the dll itself.
It's highly likely you doing one of these 2 things
compiling with /DDEBUG or /D_DEBUG OR
linking with msvcpd.lib
When you compile with /DDEBUG or /D_DEBUG, and #includeing one of the standard C++ headers, then msvcpd.lib is pulled in (with a #pragma(lib)which leads to a dependency on msvcpd***.dll.
msvcp(d)*.dll is the dll version of the standard C++ library.
If instead, your issue is with a dependency on any version the dll i.e. you want to staticly link with the C++ library, then you can compile your program with _STATIC_CPPLIB.
Are you using any additional libraries?
Maybe you have included a debug version of a dll file with your executeable.
I have a dll that I distribute that will not run on some windows OS. Using dependancy walker I discover msvcp90d.dll missing on these systems. I DO NOT want any run time dependancies that require the C++ redistributable, and since the application that calls the DLL is not written in C++, it does not have any dependancy on the C++ redistributable.
I am guessing the I left the DEBUG option in the linker preferences on when I compiled the dll which is why it needs msvcp90d.dll?
ADDED:
Appologies, I pasted the wrong dll name in my original question.... too many hours in front of the monitor...
THe dll is a third party dll that I did not write compiled by me in VS2008.
MSVCP90 is nothing to do with debug (that'd be msvcp90d). You can remove your dependency by switching the compiler to /MT (instead of /MD). You also need to ensure that every static library you link to was also compiled /MT.
I recommend against building apps /MT because it has a significant negative effect on system performance and makes servicing take longer in the event of a security issue with the CRT.
Finally, note that /MT means that your CRT is private. So you must ensure that CRT/STL types don't pass across your DLL boundary.
Martyn
Your options as I see them:
Compile the DLL with the /MT option to use static linking to the C runtime.
Continue with dynamic linking to the runtime, but distribute the C runtime with your app.
It needs MSVCP90.dll because the dll was compiled with Visual Studio 2008 most likely. That is the release runtime. The short answer is if you don't want C++ runtime dependencies don't use C++ libraries or applications.
However you can do any of the following to solve your problem:
Install the redistributable to the target system to satisfy the dependency
Remove the dependency on that dll from your application
Recompile the dll against the version of VC you prefer that is already present on the target system
I've downloaded a 3rd party library, and built the .lib file in 'release' mode.
After adding the lib to my project, if i run my project in release mode, it's fine. But if i run my project in debug mode, i get an error:
_iterator_debug_level value '0' doesn't match value '2;
I could rebuild the library in debug mode, but I don't think I'll need to be debugging the library itself? And I've downloaded prebuilt 3rd party libraries before which only come with a release build (i assume?) that link fine whether my project is in debug or release. I'm wondering how that is done.
If you want to distribute a release library that others can use in either release or debug mode, you need to do two things:
Build a DLL, so that you get your own copy of the C runtime library
Not share CRT resources, such as the heap, across the library boundary. The biggest thing for C code is that dynamically allocated memory has to be deallocated on the same side of the boundary. For C++ code, you can use the std namespace inside your DLL, but not pass those objects across the boundary.
That's what the pre-built third-party libraries have most likely done. You can do the same thing with your library only if the external interface doesn't share CRT objects. Or you can build separate release and debug versions as static libraries.
Looks like your debug binary and the library you downloaded use incompatible iterator debug modes. Iterator debugging is usually controlled by macros. Depending on macro values the sizes of interators and many other objects can change. You are lucky that your program emitted useful error message instead of simply crushing.
Check the library documentation and make sure that your project uses the same iterator debug mode. You may also try recompiling the library in release mode. If that doesn't help, you would have to recompile the library in debug mode, even if you don't intend to debug the library itself.