I would like to check whether I am using Dependency Walker correctly. I make simple utility programs which I distribute for free, and I am just trying to ensure that they run correctly on other Windows machines. (I am small-scale; I don't have a separate clean machine for testing.)
List item
Configure Dependency Walker to ignore my PATH, though "Options" -> "Configure Module Search Order..." and then removing my path from the search order.
Open the executable in Dependency Walker.
Ignore these warnings, which seem inevitable "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module."
If there are no further complaints, I assume my application should work on another machine.
Should that work?
In the Qt framework, there are at least two instances in which this will not work.
For a dynamically-linked Qt application, depends will not turn up the requirement for qwindows.dll to be in the platforms folder in the application directory.
For Qt applications using SQLite, depends does notice the requirement for qsqldriver.dll to be in the sqldrivers folder in the application directory.
Related
A customer is using our dll which is creating a child process which uses an open source library, which ultimately fails because of a call to LoadLibraryExW(), the last error returned is ERROR_MOD_NOT_FOUND. This occurs on WinXP 32-bit, but not on other machines. But we know the correct set of dependencies is installed and even in the same directory.
So we thought naturally, to use Dependency Walker to look for what dependency is missing on that particular machine. Unfortunately it doesn't show any missing, just some delay-load warnings that aren't direct dependencies of the library. In my experience using depends.exe has always revealed what the missing dependency is.
So at this point I've pulled my hair out trying to understand why I'm getting ERROR_MOD_NOT_FOUND if all of the library's dependencies are there? The only other thing that makes this machine unique is it's very secure because it's used by the government, but if we were having an access/permissions issue I'd expect a different type of error code.
I've built a small Win32 executable that does nothing but call LoadLibraryExW() on the said library, when it's run from the same directory as the library is located, it loads the library without issue, on the customer's problematic machine.
One thing is that our product is an ActiveX plugin which launches a child process, the child process calls into the 3rd party library, the 3rd party library has the problematic LoadLibraryExW() call. So maybe why it's failing is the context it's running (e.g. from the browser)?
Use the Profiling option of the Dependency Walker on your application. Possibly the library is trying to resolve some APIs dynamically (using LoadLibrary/GetProcAddress) and this won't show up in the static dependencies.
The best way is to use loader snaps. Basically you use gflags.exe (which is included with windbg) to enable loader snaps; then, run the process with the debugger attached. Loader snaps will enable the loader to print out dbg messages of the process and it will print the failures.
gflags.exe -i yourcode.exe +sls
windbg yourcode.exe
Your dependencies might be present on the system but they could be in a folder that is not part of the search order during LoadLibraryExW().
A SetDllDirectory() or AddDllDirectory() call would ensure that the folder containing the dependencies is searched during the LoadLibraryExW() call
I have statically linked the MFC, but when I give the EXE to anyone an error occurs.
I have used Dependency Walker to find all the external DLLs that I needed. I run the Dependency Walker in Profile mode (F7). Running the application after including all the listed files, gives the following error:
msvc100.dll not found
After I add this file in the folder, the application starts. But I can't find all the external DLL dependencies this way. Is there's another (better) way?
There's a tutorial on how to redistribute the MFC libraries. Did you have a look at that?
I was trying to use QOCI plugin for QtSql, until I had some problems:
Why QOCI plugin isn't working
However it turned out that it is a library loading issue (at least I think so), so I decided to change the subject of the question since it is a new question.
I have a dll file (called qsqloci4.dll) When I try to load it with LoadLibrary, it fails and GetLastError returns ERROR_MOD_NOT_FOUND. When I try to load it with LoadLibraryEx and 3rd parameter is DONT_RESOLVE_DLL_REFERENCES, it loads successfully (does not return NULL).
So, i thought it is a dependency issue. I opened the dll file with dependency walker, there were 2 files that couldn't be located: QtCore4.dll and QtSql4.dll.
However, these files are in the working directory of application, and other dll files which are dependent on those dlls (such as qsqlpsql4.dll) are successfully loaded.
Other dlls (which are located by dependency walker) are:
oci.dll : is in same folder as QtCore4.dll and QtSql4.dll, means my app can access it
kernel32.dll : i believe the easiest dll to locate by my app
msvscr80.dll : other dll files which use this can be loaded successfully.
Here is my question: given dependency walker says : "you have all dlls except qt ones" and i am sure that I have qt dlls, what other reason can be for LoadLibrary to fail with ERROR_MOD_NOT_FOUND?
You need to run Dependency Walker in dynamic mode because the are some dependencies that will be resolved by explicit linking. I believe that you do this from the Profile menu.
I am building a win32 executable. The compiler is the latest version of MinGW. The library dependencies are GLUT and libpng.
I first tested on a windows 7 machine, and had to obtain libpng3.dll and freeglut32.dll. However, on XP, I had to (in addition) acquire zlib1.dll.
The XP machine was a VM with a fresh install, so I suspect a fresh win7 machine may also be lacking zlib1.
My question is how do I go about finding out which dll's I need to distribute? How do I know, a priori, which dynamic libraries are needed for my program to run on a particular system? I suppose this is what installer programs are for... I'm guessing that what the installer does is look through the system to find out which dependencies are unsatisfied, and then provides them. So this way if I were to distribute my program I could check if the user's machine already has zlib1.dll, and I won't install zlib1.dll if it's already found in the system directory. However I never found a document that said to me specifically, "libpng requires zlib", and so, until such point as I tested the executable on a machine lacking zlib, I was unaware of this dependency. How can I create my dependency list without having a fresh install of each version of every operating system to test on?
One idea I have is to decompile the executable, or through some method examine the linking process, to find all the libraries that are being linked at runtime. The problem now becomes figuring out which of these are supposed to already be there, and which of them I could be expected to provide in the distribution.
edit: Okay, I looked, and the installation of libpng I downloaded did provide zlib1.dll inside its bin directory. So not including it is pretty much my fault. In any case, Daniel's answer is definitive.
Dependendy Walker shows all deps of your program.
The correct answer to this question, in my view, is to start at the source rather than to reverse engineer the solution with Dependency Walker, awesome and useful tool though it undoubtedly is.
The problem with Dependency Walker is that it only tells you what one particular run of the program requires on the OS on which you run it. If you have any dynamic loading dependencies in your app then you would only pick those up if you made sure you profiled the app with Dep. Walker and forced it through those dynamic loads.
My preferred approach to this problem is to start with your own source code and analyse and understand what it depends upon. It's often easy enough to do so because you know it well.
You need to understand what are the deployment requirements for your compiler. You usually have options of linking statically and dynamically to the C++ runtime. Obviously a dynamic link results in a deployment requirement.
You will also likely link to 3rd party code. One example would be Windows components. These typically don't need deployment, you can take them as already being in place. Sometimes that's not true, e.g. GDI+ on Windows 2000.
Sometimes you will link statically to 3rd party code (again easy), but if you link dynamically then that implies a deployment requirement.
please forgive my windows ignorance,
Is there an application which can show me which dlls an executable is attempting to use (name, path)
I'm assuming this can be done via static analysis of executable and/or when the executable is running by examining system calls
Use process monitor
Try Dependency Walker.
Dependency Walker is a free utility that scans any 32-bit or 64-bit Windows module (exe, dll, ocx, sys, etc.) and builds a hierarchical tree diagram of all dependent modules. For each module found, it lists all the functions that are exported by that module, and which of those functions are actually being called by other modules. Another view displays the minimum set of required files, along with detailed information about each file including a full path to the file, base address, version numbers, machine type, debug information, and more.
Dependency Walker.
Dependency walker
It's fabulous, and lets you see the hierarchy of dependent DLL's. It also shows you functions that the DLL exports.
I've even used it to solve mysterious Error 127 problems.
http://www.dependencywalker.com/