I am developing a 64 bit C++ application using Visual Studio 2015, Qt 5.5 and OpenCV3.0. The application runs well on the pc I use for developing in Release and Debug version. But the same application runs only in Debug on other PCs, and in release version I get this Error Message:
The application was unable to start correctly 0xc0000005, Click Ok toclose the application:
I created a dump file to open it using visual studio debugger, it shows that the application stops when loading the dll before loading opencv_imgproc300.dll.
I tried to review the event viewer but I did not find this error there.
Is there a method to debug a release version in startup when loading the dlls to know which the cause of the problem?
After a great effort, I solved the issue, It was because the opencv_imgproc300.dll was corrupted, It has the true size but inside is corrupted, I checked with dependency walker and found that there is great difference between the linked DLL in the Application folder and the original dll file.
As a summary, If you want to debug a release version when starting up, you have many methods. We will describe two of them:
Compiling your Release version with Debug Info, and run your application like if it was in Debug version. If the application stops before loading a DLL. This DLL is probably corrupted or missing. This link show how to compile your Release version with Debug informations: How to: Debug a Release Build.
Using Dependency walker, You open your release version application with this tool and you will find if there is any corrupted or missing dll that it needs when starting up (It is marked with red color in dependency walker). If you application is built in 64 bit, your should use the x64 version of dependency walker. If it is x86, you should use the x86 version of dependency walker. If you use the x86 version to open the x64 version of your application, you can see some false error related to linking with system DLL in their x86 version, but don't care about it, it is a bug in Dependency Walker itself.
Related
I'm trying to release the mfc app which can execute without installing visual studio 2015.
First, When I'm on google, this suggested that I can execute like above by installing vc++ redistributable package.
So I've installed packages but it doesn't work.
And I got the error message. The message is like - "The program cannot start because of missing mfc140ud.dll. ...."
Second, someone said that the release app instead of debug mode can be executed without visual studio.
So I compiled the app on release mode, then I didn't get the error message but it doesn't executed. What's wrong with this?
What can I do?
You distributing a DEBUG version of your application. You can tell that by the name of the DLL it says it can't find. The "d" suffix of "mfc140ud.dll" indicates it's looking for the DEBUG version of the MFC libraries. I don't think that the redistributable contains debug version. Nor should it.
Try releasing a RELEASE build to your clients.
Your application don't run on other PC because is the debug version, compiling to release and distributing on other PC having the visual studio redistributable package will do.
If you want your application to run not depending on the mfc140u.dll you can simply static link your application with MFC. This is easily accomplished going into your project properties.
Your application exe will be bigger but you won't have to bother with these kind of errors anymore. Please note that while this method works on debug too you better not distribute debug code on other machines for a number of reasons.
-Part0
My EXE(Debug) using mfc built with vs2012, fails to work on a PC with only vs2013.
Error Information: lacking mfc100ud.dll
It is quite similar when the EXE using mfc built with vs2013 runs on my pc with only vs2012
Error Information: lacking mfc120ud.dll
I think it is because of the building mode for mfc in the properties of building setting. But I do not know how to solve the problem properly.
I try to build the project (release), but the exe immediately breaks down even on my own pc.
-Part1
I try to abandon mfc, and build the core program only with console. The Debug edition can run successfully, but the release edition again breaks down quickly when linking to dll (either built in debug mode or release mode), cout some messy codes.
My question is:
How to ensure a mfc EXE or at least a Console EXE smoothly run on most pc with Windows?
Thanks for your help!
You'll need to build in release mode. If you build in debug mode, the EXE expects to have certain DLLs present, and if I recall correctly those are only present when the same version of Visual Studio that you built the app with is installed.
I have a C++ project I am building in VS2008. This project also links against a library (DLL + Import lib) that was built using VS2005 and thus loads VS2005 debug CRT library (everything is a debug build).
When attempting to run this executable built in VS2008, I get an error on loading due to that VS2005 DLL not finding the Debug CRT libraries, even though I have VS2005 installed with SP1. I've checked Windows updates too, so I'm not really sure what more I can do.
How do I diagnose this problem? I've looked at the Event Viewer in Windows and noticed that it can't find the debug VC80 CRT library, but that's all I know. There's a version mismatch somewhere in here I guess, I just don't know how to fix it since I don't know much about this manifest/side-by-side stuff.
The OS I'm building on is Windows XP 32-bit. I have VS2008 SP1 and VS2005 SP1 installed (so all debug manifests/CRT dlls should be available)
Learn to check or create or check appropriate assembly manifests.
Here is more info once you get that done.
On Windows XP, if an external manifest is present in the application's local folder, the operating system loader uses this manifest instead of a manifest embedded inside the binary. On Windows Server 2003 and later versions of Windows, the opposite is true—the external manifest is ignored and the embedded manifest is used when present.
For reasons beyond my control, an app I am working on deploying needs to use the debug version of the Microsoft Visual C++ 2005 library. I tried to register the msvcr80d.dll with regsvr32.exe and it fails. Is there a work around to get the debug libraries to register?
They shouldn't be registered, and the debug version isn't redistributable. It's best to fix the build of your project to get rid of the debug build, because you can't deploy it this way.
this is the visual studio run time library debug version. besides being non optimized this dll contains additional code to detected various run time errors. you should not use that for distribution, in addition to being slower your application might display all sorts of ungainly debug message boxes. skip the shortcut and recompile a release version.
This dll do not export DllRegisterServer and so cannot (and should not) be registered with regsvr32
If you install VC++ 2005 Express edition on each target PC that should include the non-redistributable DLLs. Then maybe you can deploy your app on those PCs.
I've got a minimal app I just created, using VS 2008 SP1 on Vista x64. Its a Console app, created with the wizard, no MFC or anything, I'm building it in 64bit.
When I run the debug exe, on my development box, by pressing F5 in Visual Studio 2008, I get this error:
TestApp.exe - Unable To Locate Component
This application has failed to start because MSVCR90.dll was not found.
Re-installing the application may fix this problem.
OK
I don't get this error when I run the release exe, it works as expected.
This problem started when I added some include dependencies on iostream and fstream and started calling some winsock API calls.
Any suggestions?
UPDATE: I copied msvcr90.dll (not msvcrd90.dll) into the correct folder, and now I get a different error:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: [snip]...
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
OK
Alex
You application is using the DLL CRT runtime. The machine you want to run it on requires the installation of the debug CRT runtime dll's (which is a pain in the ass...). I think the better solution is to change the compile options to use the static linked CRT runtime (that means the runtime is linked into your application instead of using the DLL version).
In visual studio go into the Properites for your project then select the Configuration Properties / C++ / Code Generation and change the "Runtime Library" from "multi-threaded debug dll" to "multi-threaded debug".
You may like to do the same for the release build as well because some versions of the OS will not come with the V9 release CRT libraries pre-installed, or you can include the v9 release crt dll as part of your install.
How are you running the release exe (Ctrl+F5 in the IDE)? You should set the Runtime Library to the same thing you are setting the release exe.
Are you linking your debug mode program to a release mode library? You mention this error in a comment:
Error 13 error LNK2005: memmove already defined in LIBCMTD.lib(memcpy.obj) MSVCRT.lib DataEngineSocketsAPI
What that looks like to me is you have a library named DataEngineSocketsAPI that links to MSVCRT.lib, which defines memmove(). But, your exe links to libcmtd.lib, which also defines a different (debug mode) version of memmove().
Third-party (e.g. your own) libraries must have debug and release versions too, and you must use the one appropriate to the mode you're building your exe for.
The Debug exe is linked to the headers for the debug runtime library, MSVCR90D.dll. You need to make sure that dll is in the path. Static linking is, as Shane says, a viable option, but the typical solution is to deploy the dependant dlls with the exe. Statically linking everything leads to bloated exes and lots of duplicated copies of runtime libraries.
Seeing your edit, the problem is certainly the msvcr90d.dll, but it needs to be deployed correctly in the WinSXS folder. You might be able to re-install the service pack for VS 2008 and get it to redeploy.
Thanks again for all the help with this. It turns out I'd just made a mistake and not noticed that a library I was using was statically linked against a different version of the MSVC runtime. That was causing on end of problems.
See this link
http://www.insidercoding.com/post/2008/07/21/Debugging-issues-with-MSVCR90DLL.aspx
You need (for debug mode only) to ignore on the link input tab MSVCRT; MSVCR90; as you want to be using the debug version of the CRT.
I can confirm this problem: letting Visual Studio 2008
create the project (Visual C++/Win32 Console Application)
and pressing F5 will display that error.
There is a simple solution:
Turn incremental linking off. HOWTO: open properties page
for the project. Set Configuration
Properties/Linker/General/Enable Incremental Linking to "No
(INCREMENTAL:NO)".