I'm' trying to build a C++ application with Visual Studio 2015 using OpenSSL.
The application experiences a 0xC0000007b error with the message "The application was unable to start correctly". Using Dependency walker I saw my application, built as x86, uses the X64 OpenSSL DLL (in System32 instead of SYSWOW64).
How can i force Visual Studio to use the 32-bits DLL?
I just added these two dependencies :
libeay32.lib
ssleay32.lib
And visual studio loads automatically ( or windows ? ) the 64 bits version, which gets me the 0xc0000007b error
Edit : Yeah, the DLL 32-bits are in the SysWow64 too.
Any idea please ?
Thanks a lot :)
You cannot force Visual Studio to automatically find proper libraries for your architecture. Instead of it you should point to it explicitly via Library Path. Use $(PlatformName) there if you have multiple target platforms.
If you compile application as x86 than Windows automatically redirects you to the proper 32 bit system32 folder. But don't rely on it, deploy required OpenSSL dlls locally, into your application folder. If you have multiple target platforms it's also handy to use $PlatformName macros in post-build event. E.g:
copy "$(SolutionDir)3rdParty\OpenSSL\$(PlatformName)\ssleay32.dll" "$(TargetDir)"
copy "$(SolutionDir)3rdParty\OpenSSL\$(PlatformName)\libeay32.dll" "$(TargetDir)"
Related
I’m having trouble generating a deployable binary for a C++ wxwidgets project using Visual Studio. After the build completes, the exe that is generated does not seem to get installed in any other Windows machine.
Visual studio 2019 is used to create GUI library with openCV included in it. I’m trying to create a standalone executable .exe to run it in any other Windows computer without installing visual studio or opencv in it.
Earlier, while opening the executable file in other computer, it gave error that dll’s are missing for openCV and wxwidgets. So, I have copied the required dll’s from the directories of openCV and wxwidgets bin folder. Now, when I try to execute the exe file, it shows the following error. Kindly help me to resolve this issue.
Applications built with the C/C++ runtimes dynamically linked (/MD[d]) require the appropriate x86 (32-bit) or x64 (64-bit) VC++ redistributables on the target machine. They can be installed from The latest supported Visual C++ downloads, or they can be included alongside the application for local deployment.
Also, be sure to only send out non-debug (Configuration = Release) builds.
MSVCP140D.dll
VCRUNTIME140D.dll
VCRUNTIME140_1D.dll
ucrtbased.dll
The 'D' suffix in the names of those missing DLLs stands for "Debug". Those are the debug C/C++ runtime DLLs, which are used by the Configuration = Debug builds, and are installed as part of the Visual Studio setup. They are to be used during development, but not otherwise deployed, per Determining Which DLLs to Redistribute:
Debug versions of applications and the various Visual C++ debug DLLs are not redistributable.
It also seems that you are using DLL build of wxWidgets and you build OpenCV as DLL.
If you yourself does not create a DLL and your software is one self contained binary ou will be better off using static linking wxWidgets and OpenCV.
And on top of what #dxiv, not everything in MS CRT can be used statically linked. That's why it is strongly recommended to install MS CRT by creating an installer, which should take care of all those dependencies.
HTH.
Thank you.
I created a client server application in C++ using Visual Studio.
Now I want to run the client EXE file on another computer (which doesn't have Visual Studio installed),
but when I try run the EXE file, it gives the following error message:
This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem.
How can I run the EXE file without installing anything on the computer?
Applications built with Visual Studio depend on Visual C++ Redistibutable (VCRedist). When the program is being linked dynamically, then your binaries will need
MSVCR**.dll (Microsoft C Runtime Library).
On MSDN, there is a nice article called Redistributing Visual C++ Files (for Visual Studio 2008), that states that there are Potential run-time errors in case that required Visual C++ library is not installed:
you may get one of the following error messages depending on the version of Windows on which you try to run your application:
The application failed to initialize properly (0xc0000135).
This application has failed to start because the application configuration is incorrect. Reinstalling application may fix this problem.
The system cannot execute the specified program.
Basically you have two options:
The simplest possible solution is to change the dynamic linking of runtime libraries to static linking. Go to project properties and under C/C++ → Code Generation you will find Runtime Library option. You need to change it from Multi-threaded DLL (/MD) to Multi-threaded (/MT).
Another possible solution is to make sure that the right version of Microsoft VC++ Redistributable Package is installed on the target machine.
But your application might depend on other DLL files as well. In case you want to find out what are the dependencies of your program, there is a great utility called Dependency Walker that will help you in this and many other situations :)
Background:
C++ applications need run-time assemblies (DLL files) to run in any Windows computer.
Normally these run-time assemblies are located at C:\Windows\Winsxs directory.
All the Windows operating systems by default comes with several run time assemblies.
But if your application is developed in a newer version of the run-time assembly environment, the target computer also needs the same version of the run time to exist there.
When you're installing Visual Studio, most newer versions of the run-time assemblies comes to your computer.
Solution:
Finally by anyway the target computer should have the exact run time assemblies. There are a few ways to do this (for more details search each in Google).
Statically link run-time assemblies with your application (troublesome for large application).
Install the C++ redistribution environment on the target computer (the easiest way).
Creating a setup project to deploy the run-time on the target computer when installing the application (not bad).
For deploying run-time assemblies as private assemblies (professional), see here for more details
Conditions:
You must not use .NET framework in your application.
You must not use the common language run-time support for your application
I deployed my program in release instead of debug, and the EXE file now works on the other computer.
I haven't seen that specific error before. Usually it's an error around a missing DLL (Windows redistributable). Assuming there isn't actually a problem with the configuration, you have two choices:
Change the compile mode from Multithreaded DLL to Multithreaded. This can be done from the C++ section of project properties under code generation. In multithreaded mode your binary will be statically linked against the Windows redistributable. This is probably what you want.
Install the Windows redistributable on the target machine. This probably isn't OK, because you state that you don't want to install anything on the target machine.
A warning about option 1: Different versions of Windows have different versions of the redistributable. It's possible to encounter a highly specialized environment in which a statically linked program will not behave as expected.
It look like you're missing some DLL files. Be sure to copy appropriate DLL files along with EXE file.
I am running Visual Studio 2019 and I found a very helpful configuration property to address the problem of moving a simple application to another computer without an installation package.
Open the project Property Pages.
Choose which configurations this change should apply to, I used “All Configurations”.
In the left-hand window click to expand the top node called “Configuration Properties”.
Click on "Advanced". In the right-hand window look for the property called “Copy C++ Runtime to OutDir” and set that to “yes”.
Click OK to close the Properties window.
Rebuild your project. All the necessary dlls will be copied to the project’s output directory. Copy your exe and all dlls to another computer. The exe should find everything it needs to run.
Consider a machine(64bit) is not having visual studio 2008 and redistributable package x64,
1. To run 64bit application(built by visual studio 2008 sp1) on that machine, do we need Redistributable package on that ?
Consider a machine(64bit) is having visual studio 2008 but it is not having redistributable package x64,
2. To run 64bit application(built by visual studio 2008 sp1) on that machine, do we need Redistributable package on that ?
what is the relation between redistibutable package x64 and 64 bit applications ?
First off, this requirement exists for both 32-bit and 64-bit code. You're just a bit more likely to be lucky with 32-bit code and somebody else having it installed before you. As it was on your dev machine by the VS installer.
It is induced by a compiler setting. Project + Properties, C/C++, Code Generation, Runtime Library setting. All the project templates in VS have this setting at /MD. You can change it to /MT and no longer have a dependency on the runtime DLLs, like msvcr90.dll. The runtime library code will be linked into your program instead of relying on the DLLs to be present on the target machine.
You have to be careful however, the /MD setting is the safe setting. It ensures that you won't get into trouble when you create your own DLLs and write code that returns C++ objects (like std::string) or pointers that must be released by the caller. This won't work well if the DLL and the EXE each have their own copy of the CRT linked into them. They will use different heaps, releasing a pointer across heaps cannot work properly. A silent leak on XP, a crash on Vista and up.
The redistributable .exe is actually meant as a downloadable installer that your customer can use when you forget to write an installer for your program. The much better solution is for you to write an installer that gets everything copied and installed properly. It takes less than a minute to make one. Add a Setup and Deployment + Setup project to your solution. Right-click it, Add, Project Output. Project + Properties, Prerequisites and tick the "Visual C++ Runtime Libraries (x64)" checkbox. If you prefer to create your own installer then you can use the merge modules in C:\Program Files (x86)\Common Files\Merge Modules
Oh, and deploy the Release build, not the Debug build. The debug version of the CRT is not distributable.
In many cases, you can link your programm statically against the C runtime library. In this case the redistributable package is not needed because all necessary functions are copied into your application's executable. If you however link against it dynamically, you should deliver the redistributable package with your application. While many other applications do this as well, there is no guarantee that the necessary runtime is available on the target system.
You can change how you link against the runtime in your project's settings dialog under "C/C++ > Code Generation > Runtime Library".
The following MSDN article explains how you redistribute the necessary VC++ files: http://msdn.microsoft.com/en-us/library/ms235299%28v=vs.80%29.aspx
I have a C++ .exe compiled with /MDd (since I can't use CLR with /MTd). At first I was getting couldn't find x.dll that is installed when installing the VC++ runtime. After I installed the VC++ 2010 runtime, I still get the error. I've verified that the .dll it's looking for (msvcpsomethingd.dll) is located in the correct folder ([SystemDrive]\Windows\system32). Has anyone run into this problem before?
How to deploy debug CRT .dlls
How to deploy CRT .dlls in general to the application local folder
The short answer is you have to explicitly install the CRT debug runtime for VS 2010 with a custom setup project on the target machines OR ensure the CRT .dlls for the platform are in the same folder as the application.
You will have to explicitly install the CRT if you are using multiple versions of the debug CRT (i.e., x86 and x64).
The best way to solve these issues is to use the depends.exe tool. Profile the program and it will tell what you are missing.
Compile with release mode and run on different PC. It seems like one/more of your DLLs are compiled using Debug build or dependencies.
It could be your referenced library as well..
Ensure that correct Redestributable of VC++ 2010 is installed:
32-bit OR 64-bit, depending on your application, not as per target OS.
Appropriate RTM or Service Pack version.
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