I put MSVCR100D.DLL into the c:\windows\system32 folder but dependency walker is still complaining about it being missing. Any ideas?
Dependency walker hasn't been updated in a very long time. I think the author just gave up trying to keep up with Windows development. Particularly resolving side-by-side manifest lookup rules is a very hard problem to solve. SetDllDirectory() is impossible to resolve statically. It isn't very smart about delay-loaded DLLs and it doesn't know anything about DLL exports that are forwarders. You almost always get a big list of missing DLLs that are not actually missing.
Using the 32-bit version on a 64-bit operating system does not work well either, your probable mistake in the case of msvcr100d.dll. Which must be copied into c:\windows\syswow64, not system32 for a 32-bit executable. You really want to favor local deployment for msvcrt versions 10 and up. In other words, simply copying the DLL into the same directory as the EXE. Putting it in the Windows system directory exposes you to too much DLL Hell, well beyond picking the wrong system directory.
If you still have trouble then SysInternals' ProcMon is the better tool. The trace it generates shows you exactly where it looked for the DLL.
Related
As we know, when trying to run a program with some of its dependent DLL missing, the system would complain about "missing dll" error. The approach I'm using to avoid this is to pack all those dependent DLL into the installer, so that the software could run in other devices. Yet with the growing number of dependent DLL, manually search and copy DLL turns out to be such a chore, especially considering that these direct dependent DLL are likely have their own dependencies.
I have known dumpbin, Dependency Walker and Dependencies to track DLL dependencies. But they only list the dependent DLL. I was wondering is there any command/script/tool that could:
recursivly search the dependent DLL of an executable
copy those dependencies to a specified directory
preferably, support exclude DLL from specified directories, like C:\WINDOWS\system32\
To be honest, I don't know if this kind of thing ever exists. If it doesn't, how do you guys deal with this DLL issue?
I have been using InstallAware Express CodeGear Edition under this link http://cc.embarcadero.com/Item/24997
It was no longer continued. But there is a menu there that it finds and locates the depended dll or bpl files, and you create a quick and dirty install project, all copied into one folder. Than you can use them for your application. This is no longer works for me, and I am also looking for another tool for this.
If you find something please let me know.
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.
Some of our users have been complaining about a libmmd.dll not found error on our plugins loading.
Some background:
I'm talking about an issue occurring on Windows (8, for that matter).
We develop plugins for Digital Audio Workstations (for digital sound
processing purposes).
Our plugin is a DLL coded in VS2012 and compiled with Intel Compiler 2015 via Perl scripts calling icl.exe
from the cmd.
One of its dependencies is an Intel-supplied math
library provided in the 2015 flavor of its redistributables (which we
install together with our plugins) called libmmd.dll.
For a matter of convenience, let's call the plugin DLL plugin.dll (!!!).
I didn't have much time on one of the affected users' machine but from what I saw, reinstalling Intel's redistributables package didn't help, only moving libmmd.dll to the same folder as plugin.dll.
Whatever the reason for this (sudden and unexpected) behavior, we want to be able to deliver software protected against this kind of issues (DLL Hell).
What we want is for plugin.dll to look for libraries first in a specific directory (configurable would be even better), then in its usual search order.
I tried playing with manifests, registry, library names, linker options...
The only things that actually worked were switching the /MD option with /MT (but recompiling with static libs really adds to the size of plugin.dll) and copying the library to the folder plugin.dll is in.
Any ideas ?
Thanks !
The SetDllDirectory function lets you add a folder path to the DLL search order. It will be added in second place, immediately behind the program folder itself.
This only affects DLLs loaded via LoadLibrary however; if your DLLs are loaded statically it won't make any difference.
I have written a little driver DLL which I hope to deploy on a lot of XP machines some of which are bound to have missing dlls and such. Until today my Dll depended only on KERNAL32.DLL and I was happy. I just added a call to RegOpenKeyEx because I need to know that a registry kex exists and suddenly Dependency walker lists a dependency on ADVAPI32.DLL which in turn depends on many many dlls.
Should this be worrying to me that I now depend on 100+ DLLs or will this only cause problems on a system that is so broken that nothing is going to run anyway?
Is there a way to read the registry with less dependencies?
advapi32.dll and all its dependencies are built into Windows.
You don't need to worry; if those DLLs were missing, nothing would work.
(And note that you mustn't try to install any of those DLLs - that will cause problems, not solve them!)
My basic issue is this: my program (MyProgram.exe) has a dependency on a DLL from another program (OtherProgram), and I'm trying to avoid repackaging a new DLL every time OtherProgram updates. I'd like to have MyProgram.exe link in OtherProgram's DLL when it launches, but I'm not completely sure that Windows allows for this. So if there is some kind of workaround that would also be acceptable.
And just for some background, the platform is Windows 7 x64, and MyProgram.exe runs fine when I create a symlink in the MyProgram.exe project directory to the DLL in OtherProgram's install directory. When I try to run it without the symlink, I get the "program can't start because OtherProgramDLL.dll is missing from your computer" error.
Any advice or links to relevant info is greatly appreciated!
EDIT: Clarification: the DLL is not linked at compile-time, this issue crops up at runtime
There are two types of dynamic linking in the Windows world:
Load-Time linking is when a DLL is loaded automatically when your program starts up. Windows finds this DLL using a specific algorithm I'll discuss below.
Run-Time linking is when you specifically load a DLL by calling LoadLibrary in your code. Similar rules apply as to how the library is found, but you can specify a fully-qualified or relatively-qualified path to control the search.
In the case of Load-Time linking, MS recommends that your program's DLLs are stored in and loaded from the same directory where your application is loaded from. If this is at all workable, this is probably your best option.
If that doesn't work, there are several other options, outlined here. One is to leverage the search order by putting the DLL in either the working directory or the directory where the application was loaded from.
You can change the working directory of an application by:
Create a shortcut to your application.
Bring up the shortcut's properties
Edit the "Start in" property with the directory where the DLL is located.
When you launch your application using the shortcut, it will load the right DLL.
Other options for load-time linking include:
Adding a manifest to your application which specifies where your dependent assemblies are, or,
Setting the PATH.
You could use LoadLibrary, but you would need a way to guarantee the DLL's location. This Wikipedia article provides good example on how to use the DLL after it has been loaded.
You can add the directory where the dll is located to the PATH environment variable.
I have struggled with the same problem and also found a dead end with the suggested methods like LoadLibrary, SetDllDirectory, Qt's addLibraryPath and others. Regardless of what I tried, the problem still remained that the application checked the libraries (and didn't find them) before actually running the code, so any code solution was bound to fail.
I almost got desperate, but then discovered an extremely easy approach which might also be helpful in cases like yours: Use a batch file! (or a similar loader before the actual application)
A Windows batch file for such a purpose could look like this:
#echo off
PATH=%PATH%;<PATH_TO_YOUR_LIB>
<PATH_TO_YOUR_APP_EXE>
/edit: Just saw #SirDarius comment in Luchian's answer which describes that way, so just take my batch code bit as a reference and all credits go to him.
I have the same problem with one application I am working on.
I do not want to use runtime loading because there are tens of functions I would need to manually create function pointer for.
Mr Dibling's mention of manifest file opened a new door for me but I sadly found out that the oldest version of windows that supports the feature is Windows 7. It won't even work on Vista.
Long story short, a friend familiar with Windows Application development told me to look up Delay-Loaded DLL, which turns out to solve the problem perfectly with minimal effort. It delays the loading of DLL library to either the point you manually do, or the first time its function is called. So you just need to add your DLL path to the search path before that happens, where SetDllDirectory helps.
Here is the steps to make it work:
1) Specify the DLL to be delay-loaded to linker, either through your makefile, cmake or VS property page (Linker->Input of VS2015)
2) Call SetDllDirectory at the beginning of your program, before any call to the DLL is made.
Delay-loaded DLL is supported all the way back to VC6.
SetDllDirectory is supported after XP SP1.
Use Symbolic Links to the 3rd Party Executables
I found the approach advocated by Aaron Margosis useful. See:
Using NTFS Junctions to Fix Application Compatibility Issues on 64-bit Editions of Windows
Essentially, create symbolic links to each of the dependent 3rd Party executables. Place these symbolic link files in and amongst your own dependent executable files. Except for filename changes to the targets, the 'soft' symbolic links will resolve the load-time dependencies even as the target of the links are changed by future updates.