I recently ran into a frustrating problem when trying to dynamically load a Windows DLL: on some machines it worked fine, but on others I got the the following error:
Unable to load DLL ‘Foo.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The DLL was, in fact, present and readable.
A response in the Microsoft Developer Network forum on error 0x8007007E suggested that the problem was caused by missing DLLs referred to my the unloadable DLL:
This occurs when a dll dependancy is missing. To solve the problem, our build guy had to remove all the dlls from the website and rebuild by putting them back one by one until the problem dll was found. The problem dll used external libraries that did not have all supporting dlls in the bin dir.
But which DLL? The only Microsoft tool I could find for static dependency analysis was the long-in-the-tooth Dependency Walker. I gave it a shot, but when I tried running it on a machine where the DLL loaded without problem, it claimed that there were missing dependencies.
I use the ldd command all the time when I’m working with shared libraries on Linux; it never dawned on my to use it on native Windows. But it works like a charm! Below is output on the machine where Foo.lib successfully loaded:
The only difference between this and output where loading failed was that references to VCRUNTIME140.dll and MSVCP140.dll were satisfied on the host where things worked, but missing where the load failed. In short, I forgot to copy over the Visual Studio runtime for Foo.dll. After adding the two DLLs to the directory in which Foo.dll resided, the load worked fine on the problem machine.
Maybe there is a Windows utility as easy to use, as informative, as easy to acquire and install as Cygwin’s ldd, but I have not found it. Meanwhile, I’m glad to have learned this trick.