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
Related
I have a project that I build with CMake, which is composed of a library black.dll and an executable black.exe that depends on the DLL. The DLL in turn depends on libz3.dll which is an external dependency.
When I build from the command prompt using CMake I cannot run the executable because of the error "The application was unable to start correctly (0xc0000142)". The external dependency libz3.dll is correctly copied into the executable directory.
But, when I build the project from Visual Studio 2019 (making it use CMake under the hood as well), everything works properly (when I copy libz3.dll into the executable directory).
I've looked at the two executables with Dependency Walker to understand what's the different between the two but there are no differences (both show errors of missing strange libraries such as API-MS-WIN-CRT-RUNTIME-L1-1-0.DLL but in the case of the executable built with VS it seems to not be a problem).
I've also checked to be building for the correct architecture: both the executable, the library and libz3.dll are built for x64.
What can I check to understand what's going on?
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 am trying to deploy a simple C++ Open GL graphics program using InstallShield Limited Edition. I have managed to create an example installer, but my main program crashes on start up. My debugger gave me a pretty vague error
error_text 0x00cceb28 L"R6010\r\n- abort() has been called\r\n" const wchar_t * const
in file crt0msg.c
I have run dependency walker and it says that I am missing the following:
API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL
API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL
API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL
API-MS-WIN-CORE-SHUTDOWN-L1-1-1.DLL
EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
IESHIMS.DLL
As far as I know these are windows systems .dlls? I cant seems to run the profiler as dependency walker always hangs and crashes. I have tested my example project and it seems to be missing the same .dll's but runs fine.
The project has 2 external libraries in the dependencies (Never built one with external libraries before). I have also included a folder with text files next to the Primary output as is the structure in the release folder of VS2013. The assets folder etc seem to be compiling.
I have never deployed a project before, could anyone let me know what might be the cause?
The error was due to the assets folder not linking correctly. I am going to try a different installer however.
When running my Visual Studio C++ application debug version through VS2010 by Project Only > ProjectName the generated exe runs well. However when I generate a release version and go to the folder where the exe is created I get the following error:
The application was unable to start correctly (0xc000007b). Click Ok to close the application
The files in the folder is only the exe file whereas my project uses various boost libraries.
Is it possible that its giving this message because of the missing boost dlls ? Is there a way to make the compiler paste all the necessary dlls in the exe folder.
Is there any way to launch the release version from VS2010 like we have for the debug version as in Debug >> Start new instance
I hate when that happens. It could be the fact that its missing the bloost DLL's: the easiest way to fix this is to add the folder to the Path environment variable. Sadly enough, we don't have enough information from your post to confirm that this is the problem. Common other problems include: you are linking to libraries that were built for a different architecture/are using a different runtime library, you are missing other 3rd party dlls, the .lib file you used in the linker is pointing to a different version of the code than the dll you are pointing to...the list goes on.
As for copying the dlls at runtime, you can do this using the custom build events [http://msdn.microsoft.com/en-us/library/e85wte0k%28v=vs.80%29.aspx]. Just write a batch script that copies the dlls as a "Post Build Event" and you should be good to go, but I'd suggest the Path way first.
I've recently downloaded Assimp and I've run into some troubles.
I've linked the libraries and I can get the program to compile and it runs fine in Release mode; however, the Debug .exe hits me with this error:
The application was unable to start correctly (0xc0150002). Click OK to close the application.
Some more details:
I'm using VS2010 with Target Machine set to x86.
I am using the 32bit debug dll (Assimp32d.dll) that was provided, and I've tried setting runtime libraries to /MT, /MTd, /MD, and /MDd with no luck.
I read from other similar threads that I should run Dependency Walker on the .exe, but I'm not sure what the output means. I'll paste it here if this helps you guys.
Error: The Side-by-Side configuration information for "c:\users\-----\documents\visual studio 2010\projects\AssimpTest\debug\ASSIMP32D.DLL" contains errors. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail (14001).
Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Rather than rebuilding the libraries, I downloaded a different set of libraries (it was the SDK installer) and the debug dll's from that are working perfectly.
Just in case anyone has the same problem with the same software, this was the exact name of the installer that worked for me: assimp-sdk-3.0-setup.exe
I ran into the same problem when trying to run a 64-bit project in Debug mode when using Assimp 3.0.
What I did was go to assimp/workspaces/vc9, open assimp.sln in Visual Studio 10, convert the project, then rebuild the 32 and 64-bit dll.
Mind you, you've got to install boost for that as well, and edit the project properties so it points to the boost directory for includes.
There's probably a way to do it using CMake as well, but I found the whole process too cumbersome to bother with in the first place.
My solution was just to link the debug build to the release .dll files. No more issues, and I wasn't that interested in debugging the Assimp library anyway!
I faced the same issue, later on I downloaded the "assimp-sdk-3.0-setup.exe" file & installed it as a standard windows application.
I pointed Visual Studio Solution Include & Lib directories to respective folders from newly installed location, copied DLL to my application location. The problem was resolved. Hope this helps someone.
Cheers.