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!
Related
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.
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'm lost here and I have no clue how to proceed. This is not a question about how to make my program work, this is a question about how to stop wasting my time.
My programming environment is Visual Studio 2013 on windows, in C++.
I use 3 libraries extensively, namely: boost (using dynamic linking), OpenCV, and Qt.
During the development, I have configured VS to look at those 3 libraries by default for include and .lib. I have also added the 3 folders containing all the dlls to my PATH environment variable.
It works, but it is sometime painful, let me explain you when.
First hassle: Anytime I have a LNK error telling me I miss a function, it is usually on OpenCV since it has only one include file referencing all the functions. I have to look at OpenCV's source code to see what module this function belongs to and to know what I must link my program to.
Second Hassle: When comes the time to deploy my application, I have to ship it with all the relevant dlls. To know which one I need, I open dependency walker and try to forget nothing, I have then to test it on a different computer because 102% of the time I have missed a couple, and then I have to configure my Installer generator to include all those one by one.
Third Hassle: To ease a little bit the process of configuring a new development machine, I have recently switched to NuGet. It is great, I add boost with a couple of clicks to any project. But now my boost DLLs are everywhere, I have one folder per boost library, and since there are dozens of those I can't even add them all at once to my PATH now, so I have to move them manually to the appropriate folder, and that is really not what I want to do with my not-so-precious-but-who-are-you-to-judge time
I have looked around and couldn't find any good practice regarding this issue, maybe because they are too obvious, or too specific to a particular setup.
How do you do? How would you do if you were me?
We put all our external dependencies in version control along with the code. This ensures that all code can build "out of the box" on any of our development machines and also ensures that for any given version of the code, we know exactly which dependencies is has.
The best way to check for missing dependencies is how have a good automated test suite, if you've got comprehensive converge then if your tests pass you must have deployed the required libraries.
In terms of linking to the appropriate libraries, unfortunately, that just sounds like an issue with the structure of OpenCV (I'm not familiar with OpenCV). I tend to use dumpbin under Windows and nm under Linux to easily grep for symbols when I get link errors with an unfamiliar library.
I'm having an issue with regards to registering a *.dll under Windows 7 x64.
I've tried placing the *.dll in both, C:/Windows/System32 and C:/Windows/SysWOW64 and attempting to register with "regsvr32 xxxxx.dll" under an elevated command prompt. I also tried to register it from a seperate directory. It responds with the following error:
The module "xxxxx.dll" failed to load.
Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
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.
The EventLog notes:
Activation context generation failed for "C:\(path-to-dll)
Dependent Assembly
Microsoft.VC90.ATL,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found.
Please use sxstrace.exe for detailed diagnosis
N.B. I have installed both x86 and x64 Microsoft Visual C++ 2010 Redistributables.
An interesting aside is that I attempted to register the same *.dll on my work x64 Windows 7 laptop and it registered as expected. I guess this leans towards the fact that some kind of C++ dependency is missing / ATL related?
If anyone could help point me in the right direction or shed any additional light on the matter; i'd be more than grateful.
Regards.
This is almost certainly due to a missing dependency. Use a tool like Dependency Walker to find the required dependencies of the DLL. Or, if the DLL is supplied by a third party, read their documentation which should specify the required dependencies.
Note that Microsoft.VC90.ATL indicates version 9 of MSVC which is VS2008. So you would need to install the MSVC 2008 runtime to meet that dependency. It looks like you installed the MSVC 2010 runtime by mistake.
Finally, please don't put files into the system directory. It belongs to the system and should not be modified by you.
Dependent Assembly
Microsoft.VC90.ATL,processorArchitecture="x86"
This indicates missing Visual C++ runtime module (see Visual C++ Libraries as Shared Side-by-Side Assemblies). It is available as redistributable installer (this is presumably the one you need; x86 variant), which you need to install before registering your DLL (which is in turn dependent on missing component).
There is also another reason why this fails. I just ran into this myself. I was using API methods that did not support Windows 7, such as PathCchRemoveFileSpec which I had to update to the older, deprecated PathRemoveFileSpec. I used Dependency Walker to verify this was the cause. Dependency Walker lies a bit. If you look at my screenshot (below), the red section shows the actual problem - the methods it wasn't able to resolve in DLLs it has, etc. - but the blue shows DLLs that are actually not the problem at all (these DLLs exist). Since Dependency Walker is so old, it lies a bit (its outdated, it thinks something isn't available from time to time), but usually, it also tells the truth...you just have to scroll down a bit from the top left pane like I did. Note to self: please scroll down next time. Anyways, once I ditched pathcch.h, everything worked on 7. Happy coding.
I got relieved from this error message. In my binary path, I had a SPACE. Just replaced the SPACE with UNDERSCORE(_). It worked for me.
as i have also faced the same issue while registering the x.dll through Regsvr32,there is one of the possible reason is that x.dll might be unmaged dll.
To use unmanged dll export function in the dot net code, you have to use Dllimport.
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.