I tried to run a program I wrote on a remote computer. As I knew there might be a dll problem, I set the runtime library option to /MT, so I can rely on static linking.
However, I still receive the error message on my remote computer, stating that MSCVP140.dll is missing. Isn't this what the /MT flag should take care of?
I even tried to install the redistributable, but no luck. I'm still stuck with the error.
Another thing I tried was placing a MSVCP140.dll I downloaded in the folder, but that way my program is simply crashing on startup. I suspect that the MSCVP140.dll version is not the expected one, so I'm not relying on the validity of this test.
Any ideas?
Try to open your exe with depends.exe and find the dependancies in the machine it crashes. Probably the MSVCP140 might have other dependancies. Copy all dependancy dlls into same folder and give a try.
Someone please punch me for being this stupid... I was compiling on x86 instead of x64 all the time. No surprise the dlls didn't work.
Thanks for the help nevertheless. At least you got me on track to take a closer look at my dlls.
Related
This is somewhat an addition to this question (MSVCP140.dll missing).
I am trying to compile a program for a windows machine. Something huge to note here is I do not have the privileges to install software on it, but I may run executables.
Every time I run it on the windows machine in question I get a missing MSVCP140.dll problem. I have followed the solution of the question I have linked (which is static linking) and for some VERY odd reason I am still getting the error (even though I know this enabled the program to run on colleagues computers when they were getting the same error).
Is there anything more I can do that will make the program (for lack of better terms) fully portable? Any more settings I need to change in VS such that it will fully compile the libraries into the executable?
I am going to further stress the fact I have seen the solution to use static linking using the /MT option for compilation and I am still getting missing .dll problems.
I tried copying MSVCP140.dll next to my executable and it did solve the issue, but there is another missing .dll and I cannot incrementally add .dlls until the program starts working. I am happy to bundle all the .dlls with the program if that is the only solution but I would like to know which ones are needed so I don't have to copy my entire system32 folder out of desperation.
Have a go at using dependency walker to figure out what dlls you need, and why you need them. This can be enlightening, and lead to a path of cutting out many dependencies by using alternatives. If you are sure you aren't importing certain functions at consumer runtime (e.g. you are only importing them for debug purposes), then you can choose to delay load them.
I've done some searching and seen questions similar in nature to mine, but none that quite hit the nail on the head of the issue I'm having.
I'm making C++ game in Visual Studio (with the Allegro 5 library) and encountering difficulty running it on other computers. I'm well aware of the 'MSVCR##.dll is missing from this computer' issue, but what I'm wondering is why I'm unable to run my Release build because I'm missing the MSVCR##'D'.dll on a certain computer, when I was under the impression that the 'D' suffixed .dll was exclusively required for running the debugger. I've checked in my configuration manager for release build settings and I have 'Generate Debug Info' set to No, which I thought was the only thing I needed to do. My question I guess is whether or not there are any other settings I need to configure to make sure my Release build isn't looking for the MSVCR##D.dll. Thanks in advance anyone who has any info!
You're a bit confused about the use of the *D libraries. They're indeed used for debug builds, but debug builds differ in multiple ways from release builds. For starters, debug builds by default come with a *.PDB file that contains all the function names (This is your "Generate Debug Info" option). A debugger looks into the .PDB file to find a readable name for a crash site.
Another debug option is to not inline code - this keeps your named functions intact. Inlining may put that single finction inside three other functions, which complicates debugging a bit.
Finally the Debug CRT includes functions that perform extra error checking against bad arguments. Many functions exhibit Undefined Behavior when passed a null pointer, for instance. The Debug libraries will catch quite a few of those, whereas the Release versions assume you pass valid pointers only.
Now DLL's can reference each other; there's a whoel dependency graph. That's why the Dependency Walker tool exists: it figures out which DLL's rqeuire which other DLL's, and this will tell you why you need the *D version.
Thank you very much for all your inputs, I was able to learn a fair bit from this. It turns out the issue was (of course) entirely my fault, as when setting up the Allegro 5 dependencies in the project settings (under General->Linker) I was accidentally including a dependency for the debug version of the Allegro monolith-md.dll as well as the non-debug version in my Release build, and that .dll was in turn referencing the *D version of the MSVCR .dll. The issue has been resolved by removing that dependency from the Release build of my game.
Install dependency walker on that machine. Load the exe. Check if any of the dependent dlls are missing.
I guess everyone has run into missing dll's issues from time to time. What I am trying to get is the 'recommended' method to find and install the dll's. Finding out which dll's are missing is easy enough using depends.exe.
Don't use depends.exe anymore, it hasn't kept up with developments in the Windows core and deployment strategies like the side-by-side cache. Trying to fix the warnings it gives will actually mess up your machine pretty badly. Only use it for hints if a program actually fails to start.
99% of the missing dll errors that I tend to come across are missing C++ runtime libraries (eg =MSVC*.dll=) or the .Net framework, where the developer has built with dynamic linking to the C++ runtimes but hasn't created an installer with the required merge modules, or they have built a debug version which links against the debug runtime libraries which you are not permitted to redistribute.
In the vast majority of these cases, simply installing the correct Visual Studio 2005/2008 C++ runtimes (eg see here) or .Net framework will fix the problem.
That depends greatly on which DLLs are missing and why they are missing, I don't know that there is a one-size-fits-all answer.
My advice would be to use depends to find which DLLs are missing, try to find out where those DLLs were supposed to be installed (and what application was supposed to install them), and then try to reinstall that application or find out what happened to screw up the dlls.
Another thing to check is for 32bit/64bit mismatches, that can make it seem like DLLs are missing sometimes, especially on 64bit platforms.
Or if you are using .NET, you can have trouble with assembly versions and the GAC sometimes.
You can also check the PATH environment variable, I would advise against blindly adding to your PATH to get it to find DLLs you want, that can cause all sorts of other weird problems.
Sometimes you have to hack around with the PATH or copy files to get things to work, but it is usually better if you can figure out what went wrong in the first place and fix it.
Get the DLL from its publisher's website, if possible, and then follow the publisher instructions to install. Don't forget to respect licensing rules!
I am trying to use a library (.dll) in my project. Everything seems to
be set up fine. It all works in release mode.
When I go debug on it, I get this darn error on startup:
ldr: ... application couldn't be initialized error (or similar, I translated it)
I learned that this has to do with manifest files.
I fumbled around a bit, in the project settings, but nothing really worked / I couldn't get my head around it.
The error persists.
Does anyone know a quick solution to this?
I don't care if it is dirty.
I think I liked dll-Hell better than manifest-Hell!!
The solution:
The wrong version of the .dlls got loaded. I didn't know that they were still
lying around on the system. Depedency Walker is a great tool and set me on the right track. So I will accept this answer.
Thanks a lot!
I always use Dependency Walker for debugging this sort of thing. It will tell you which dependencies your dll is missing.
Are you trying to run Debug-mode executables on a PC without Visual Studio installed? If so, you'll need to copy the Debug CRT DLLs onto it. See here: http://msdn.microsoft.com/en-us/library/aa985618(VS.80).aspx
Probably has something to do with dependent DLLs that are not available in debug mode (but are there in release mode). Make sure the debug DLLs you need are available (e.g. in the path).
I'm using boost for several C++ projects. I recently made a upgrade (1.33.1 to 1.36, soon to 1.37), since then I cannot run any debug-builds anymore.
To be sure that no other project issues remain, I've created a minimum test-project, which only includes boost.thread, and uses it to start one method. The release build can be started, the debug build cannot, although the Dependency Walker shows that all required libraries are found (this also means that the required MS Debug CRT is found in the SxS directory).
On startup I only get:
Die Anwendung konnte nicht richtig initialisiert werden (0xc0150002).
Klicken Sie auf "OK", um die Anwendung zu beenden.
Which means nothing more than "failed to initialize app". An internet research primarily lead to an MS Office installation problem, which recommends to perform a repair of WinXP.
So, beside the repair setup (which I think will not help as I'm talking about debug-dll issues), any ideas?
Ah, before I forget: Absolutely the same source-code leads to no errors on the build-machine (i.e., DLLs can be registered, means executed). So it's obviously an installation problem, but as the DLLs are there, and dependency-walker finds it, what else have I forgotten?
(edit) Well, I have not yet resolved my problem, but thanks to deemok I'm a step further. For the sake of reducing misunderstandings I give some clarifications below:
The program fails to run on the developer-machine
I am working with an installed VS2005 (it's a VC++8 project)
I used the boost-setup from BoostPro, compiled all possible build-versions, and I double-checked that they are there (otherwise I'd already get linker-errors during build).
and I double-checked any corner of include/lib/bin configuration I can think of -- as boost uses auto-linking on windows, with a special naming convention, the build or start-up would have failed, with a much more comprehensible error-message.
I cannot use static linking, as boost.thread requires dynamic linking for DLL projects (I maybe could mess around here, but as this problem seems to happen only on my machine, I do not want to mess with this, as I'm sure the boost-guys had a reason to place that check in there in the first place)
As I wrote, I checked with Dependency Walker, and it says everything is just fine.
Currently it seems to be an error in the boost-dll (maybe incorrect Manifest), will check that.
It's a Side-by-Side (SxS) issue – simply copying the DLLs is not enough anymore.
Regarding your specific problem concerning the Debug build, see: Running vc2008 debug builds on non-dev machines
Short answer:
You can't, because there's no installer redist for the debug runtime (and in fact the software license forbids distributing it, so you'd be breaking the EULA even if you did get something put together).
So, you'll need to install Visual Studio there.
However, if you still want to try without taking that path, you could read puetzk's answer in its entirety.
Or, you could try to link everything statically.
So you are using the pre-built libraries from BoostPro? If so, your environment might somehow be slightly different to the one they were built in (TR1 feature pack or not, etc). Perhaps best to try building Boost yourself in your specific environment.
This might turn out to have nothing to do with SxS. I suggest checking the Event Log for SxS error messages and using dependency walker to check for most probable DLL dependency issue, or one of the DLLs is returning FALSE from its DllMain (for whatever reason).
Also, enabling loader snaps:
gflags -i yourapp.exe +sls
might shed extra light when run under debugger (or dependency walker for that matter).
Note: gflags is part of Windows debugging tools.
Get yourself the dependency walker. Open your application exe in it. It will show you all the dlls that your application needs but can't load/access.
If that's not enough, you can also profile your app with the dependency walker, which will give you a lot of output to find out where the problem is.
[edit]
since you only have problems with the debug build:
make sure that when you upgraded boost, you also rebuilt not just the release binaries but also the debug binaries of boost. And of course, make sure that the debug build was built with the same version of VisualStudio than you're using now.
And make sure that the include paths (tools->options->projects and solutions->VC++ directories) are correct: the paths to the latest boost version must be there, not maybe to an older version.