I'm trying to send a game made with SDL2 to a friend.
I found out that Visual Studio 2013 has an option called "Multithreaded",
which basically puts all the dll's into the exe. This doesn't work
because of the SDL2.dll and glew32.dll, which means I get weird build errors.
A different approach is to put all the required dll's into the same folder,
so I now have:
SDL2.dll
glew32.dll
msvcp120.dll
msvcr120.dll
Now my friends get the error message: "the application was
unable to start correctly 0xc00007b". How can I fix this?
I opened the exe with Dependency Walker, which gave me a huge
amount of dll's, and I don't know which I need (if I need any).
make sure you and "your friend" both use the same architecture
x86 or x64,...etc.
make sure that you give him the
redistributables for VC 2013 or whatever IDE you are using.
Related
So I recently finished a VC++ console application I have been working on and I sent it to one of my friends to try out but he cant even open it because he keeps getting an error.
A box will open up with the title Bad - Image and then it shows the error and stuff, it says it cant find the file MSVCP140D.dll on my friends computer but when I start the program it runs fine.
Can anyone tell me why he cant play the program and how to fix it?
You have built your project in debug mode and you are using Multi-threaded Debug DLL (/MDd) RunTime library.
In Visual Studio main menu, select Project -> Properties
Go to "Configuration Properties" -> C/C++ -> Code Generation
In Runtime Library, select Multi-threaded Debug (/MTd) and rebuild your project.
Alternatively you can build your project in Release mode, then select Multi-threaded (/MT) Runtime library.
This will make a stand-alone executable file which uses standard windows libraries, you won't have to provide additional dlls with the *.exe file.
You need to ship your program with the Microsoft Visual C++ Redistributable package. That's MSVCP140D.dll.
As user4581301 pointed out, the D in MSVCP140D.dll means 'Debug'.
You shouldn't ship a debug-enabled executable. It makes reverse engineering, hacking, and other modifications easier.
You should instead compile a release build, and ship it with the redistributable.
Well you need to do one thing(the easy solution), you just go to your system32 directory at system where you have built the code and find out the file MSVCP140D.dll, put it with your executable(.exe) and give it to your friend, and tell him to keep the dll in same folder as the exe.
MSVCP140D.dll (redistributable pack) is one of the run time dependencies you need to provide to run your application.
Now it will get installed. Or you can copy the dll at system32 at target system and then try.
But you shouldn't provide the debug build if you are giving it to client, you should provide the release version of it.
I've written a game using OpenGL, GLFW, C/C++. I use third party libraries like SOIL and irrKlang. I use Microsoft Visual 2015. Both the debug and release version run ok from visual studio. In properties -> C++ -> Code Generation-> Runtime Library I selected /MDd. I did try other settings but the release version wouldn't work with any other. All of my .dll are saved in the release and debug folders.
However, when I go to my release folder and copy and paste the .exe found there, onto my desktop,it no longer runs. I keep getting a message that says the irrKlang.dll is missing. Could someone please explain how to get a standalone .exe of my game up and running?
Two things here. First, the .exe is the executable which contains the entry point of your application. So this is indeed the first piece you need. However, your application is allowed to depend on code that's not linked into it statically, but rather dynamically -- such dynamically linked code is only loaded at runtime. These runtime libraries of code are called DLLs ("dynamically linked libraries").
If your application depends on a DLL, it will look for that DLL while it's running. If it doesn't find it, you'll see that message box about a missing DLL. So, you need to copy not only the .exe file, but all the .dlls it depends on (and that they depend on) too. Note that your application links against many default system DLLs, e.g. kernel32, but these don't need to be copied next to the .exe because they're always present in the system search path.
Now, the second part. If you want to run your application on a PC that doesn't have Visual Studio installed, you need to make sure that computer has the C/C++ runtimes that the VS2015 toolchain automatically links against installed. These are not DLLs that you copy by hand; rather, there is a redistributable installer for them which installs them globally on the PC for all applications. You can ship this with your own installer.
For this to work, you want to be linking with just /MD in Release (the debug CRT is for debugging only, and is only installed when Visual Studio is installed -- it's not meant to run outside your PC).
This statement:
"Both the debug and release version run ok from visual studio. In properties -> C++ -> Code Generation-> Runtime Library I selected /MDd. I did try other settings but the release version wouldn't work with any other."
Leads me to believe that maybe you don't have a release version of one of your third party libraries.
/MDd causes your application to use the debug version of the MS runtime, which means that something in your project is being built with or as a debug version.
I use the 'depends.exe' application to see the dependencies of my executables and DLLs. It used to be provided directly by Microsoft, but now seems to be supported via a third party. Older SDKs will have it.
http://www.dependencywalker.com/
I have environment where both VisualStudio 2005 and VisualStudio 2013 are installed. And I have strange situation with some of the projects. I compile such projects with VS2013 and when I try to launch them through Explorer or command line I get an error - "The program can't start because MSVCR80.dll is missing ...". Why msvcr80 when I compile with msvcr120?
What I tried:
Put msvc*80.dll to directory with executable. I got runtime error "R6034. An application has made an attempt to load the C runtime library incorrectly..."
Checked binary dependencies with Dependency Walker. I saw that binary has dependencies to VS2013 runtime, and there is no mention about msvcr80.dll
Launched binary with empty PATH. I gave no positive effect.
Launched binary on another 'clean' pc. And it worked all right with vs2013 runtime.
How can this be?
Thank you for all, you was right. I just forgot, that I have installed old version of my product. It was launched in background and used old versions of libraries. So when I ran my new application it tried to use libraries that already had beed loaded. In another way Dependecy walker didn't check already loaded libraries and looked only in PATH.
MSDN link about DLL loading - https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms682586(v=vs.85).aspx
I'm trying to compile a SDL-program I've written, but when I do, this error shows up:
The program can't start because SDL.dll is missing from your computer.
Try reinstalling the program to fix this problem
I have no idea as to why. I have SDL.dll.
I have put it in the correct folder: C:\Windows\System32.
I have the correct PATHS to all the SDL headers and such as well.
VS says:
Build succeeded: 1
and THEN the error above pops up on screen.
Add it into your debug folder or whatever directory your program is currently located at.
SDL.dll has to either be in the same directory as your application, or in a directory that's in the PATH environment variable.
IfSDL.dll is 32-bit and you're running a 64-bit system you have to place the dll into /Windows/SysWOW64/ rather than /Windows/System32/, which is used for 64-bit dlls.
EDIT:
You probably shouldn't be deploying your DLLs by copying them into the System32 directory, unless they're common libraries that are used by several applications, and even then I would use discretion. For example, an application could update the DLL, which could break other applications that rely on an older version of the library.
Instead, copy the DLLs into the same directory that the executable is being built in. If you're building and executing with Visual Studio it will look for the DLL in the Project directory, where your source files are probably located.
Just place your SDL.dll in the same folder and your problem will be solved.
And to answer to your problem with the PATH, you can specify in visual studio where he will look for executables while debugging. Maybe this isn't set correctly and that's why VS can't find SDL.dll?
I'm trying to run an OpenCV application through Microsoft Visual C++ 2010 Express, and get the following message:
How can I solve this issue?
I agree with Brandrew, the problem is most likely caused by some missing dlls that can't be found neither on the system path nor in the folder where the executable is. Try putting the following DLLs nearby the executable:
the Visual Studio C++ runtime (in VS2008, they could be found at places like C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86.) Include all 3 of the DLL files as well as the manifest file.
the four OpenCV dlls (cv210.dll, cvaux210.dll, cxcore210.dll and highgui210.dll, or the ones your OpenCV version has)
if that still doesn't work, try the debug VS runtime (executables compiled for "Debug" use a different set of dlls, named something like msvcrt9d.dll, important part is the "d")
Alternatively, try loading the executable into Dependency Walker ( http://www.dependencywalker.com/ ), it should point out the missing dlls for you.
In my case, Visual Leak Detector I was using to track down memory leaks in Visual Studio 2015 was missing the Microsoft manifest file Microsoft.DTfW.DHL.manifest, see link Building Visual Leak Detector all way down. This file must be in the folder where vld.dll or vld_x64.dll is in your configuration, say C:\Program Files (x86)\Visual Leak Detector\bin\Win32, C:\Program Files (x86)\Visual Leak Detector\bin\Win64, Debug or x64/Debug.
I take it that is a Vista Window! I often got this when first trying to port a DirectX program from XPsp3 to Vista.
It's a .dll problem. The OpenCV runtime.dll will call upon a system.dll that will be no longer shipped Vista, so unfortunately you will have to to a bit of hunting to find which system.dll it's trying to find. (system.dll could be vc2010 or vista)
This error is also caused by incorrect installation of .dlls (i.e not rolling out)
hth
Happy hunting
I got this error when trying to run my friend's solution file by visual studio 2010 after convert it to 2010 version. The fix is easy, I create new project, right click the solution to add existing .cpp and .h file from my friend's project. Then it work.
Just run .exe file in dependency walker( http://dependencywalker.com/)
and it will point you the missing dlls and download those dll (www.dll-files.com) and paste in the c:windows:system32 and the folder as your .exe and even provide the path of those dll in path variable.
Even I faced same error, I fixed it afterwards...
Two things you need to look into
Whether your system path is correctly set in your environment variables
Check the pre-processors in Project Properties->c/c++->Pre-processors. Check whether you have included _CONSOLE, this was causing error for me. For Some applications you need to include WIN32;_WINDOWS;_CONSOLE;_DEBUG;QT_DLL;QT_GUI_LIB;QT_NETWORK_LIB;QT_CORE_LIB;COIN_DLL;SOQT_DLL;QT_DEBUG;
I got this error while I was working in coin3D Application.
I met such problem. Visual Studio 2008 clearly said: problem was caused by libtiff.dll. It cannot be loaded for some reasom, caused by its manifest (as a matter of fact, this dll has no manifest at all). I fixed it, when I had removed libtiff.dll from my project (but simultaneously I lost ability to open compressed TIFFs!). I recompiled aforementioned dll, but problem still remains. Interesting, that at my own machine I have no such error. Three others comps refused to load my prog. Attention!!! Here http://www.error-repair-tools.com/ppc/error.php?t=0xc0150002 one wise boy wrote, that this error was caused by problem with registry and offers repair tool. I have a solid guess, that this "repair tool" will install some malicious soft at your comp.
It is because there is a DLL that your program is missing or can't find.
In your case I believe you are missing the openCV dlls. You can find these under the "build" directory that comes with open CV. If you are using VS2010 and building to an x86 program you can locate your dlls here under "opencv\build\x86\vc10\bin". Simply copy all these files to your Debug and Release folders and it should resolve your issues.
Generally you can resolve this issue using the following procedure:
Download Dependency Walker from here: http://www.dependencywalker.com/
Load your .exe file into Dependency Walker (under your projects Debug or Release folder), in your case this would be DisplayImage.exe
Look for any DLL's that are missing, or are corrupt, or are for the wrong architecture (i.e. x64 instead of x86) these will be highlighted in red.
For each DLL that you are missing either copy to your Debug or Release folders with your .exe, or install the required software, or add the path to the DLLs to your environment variables (Win+Pause -> Advanced System Settings -> Environment Variables)
Remember that you will need to have these DLLs in the same directory as your .exe. If you copy the .exe from the Release folder to somewhere else then you will need those DLLs copied with the .exe as well. For portability I tend to try and have a test Virtual Machine with a clean install of Windows (no updates or programs installed), and I walk through the Dependencies using the Dependency Walker one by one until the program is running happily.
This is a common problem. Also see these questions:
Can't run a vc++, error code 0xc0150002
The application was unable to start (0xc0150002) with libcurl C++ Windows 7 VS 2010
0xc0150002 Error when trying to run VC++ libcurl
The application was unable to start correctly 0xc150002
The application was unable to start correctly (0*0150002) - OpenCv
Good Luck!
In our case (next to trying Dependency Walker) it was a faulty manifest file, mixing 64 bits and 32 bits. We use two extra files while running in Debug mode: dbghelp.dll and Microsoft.DTfW.DHL.manifest.
The manifest file looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- $Id -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<noInheritable />
<assemblyIdentity type="win32" name="Microsoft.DTfW.DHL" version="6.11.1.404" processorArchitecture="x86" />
<file name="dbghelp.dll" />
</assembly>
Notice the 'processorArchitecture' field. It was set to "amd64" instead of "x86". It's probably not always the cause, but in our case it was the root cause, so it may be helpful to some. For 64-bit runs, you'll want "amd64" in there.
I faced this issue, when I was supplying the executable folder with a, by the .exe requested DLL.
In my case, the DLL I supplied to the .exe was searching for another necessary DLL which was not available.
The searching DLL was not capable of telling that it can not find the necessary DLL.
You might check the DLLs you're loading and the dependencies of these DLL's.
Here is my solution for this error:
(The Application was unable to start correctly (OXO15OOO20).Click to close the application).
From the Start menu, click Administrative Tools, and then click Windows Server Backup.
Click File, Click Option, and then in Disk Cleanup press Delete files and then press O.K,
and delete till it reaches to 0 byete
No Worry About it just it deletes the amount of disk space on your computer.