How to check for DLL dependency?

dumpbin from Visual Studio tools (VC\bin folder) can help here:

dumpbin /dependents your_dll_file.dll

I can recommend interesting solution for Linux fans. After I explored this solution, I've switched from DependencyWalker to this.

You can use your favorite ldd over Windows-related exe, dll.

To do this you need to install Cygwin (basic installation, without additional packages required) on your Windows and then just start Cygwin Terminal. Now you can run your favorite Linux commands, including:

$ ldd your_dll_file.dll

UPD: You can use ldd also through git bash terminal on Windows. No need to install cygwin in case if you have git already installed.

Figure out the full file path to the assembly you're trying to work with Press the start button, type "dev". Launch the program called "Developer Command Prompt for VS 2017" In the window that opens, type dumpbin /dependents [path], where [path] is the path you figured out in step 1 press the enter key

Bam, you've got your dependency information. The window should look like this:

https://i.stack.imgur.com/Qn0PC.png

https://i.stack.imgur.com/8gsSW.png

There is a program called "Depends" If you have cygwin installed, nothing simpler then ldd file.exe

The safest thing is have some clean virtual machine, on which you can test your program. On every version you'd like to test, restore the VM to its initial clean value. Then install your program using its setup, and see if it works.

Dll problems have different faces. If you use Visual Studio and dynamically link to the CRT, you have to distribute the CRT DLLs. Update your VS, and you have to distribute another version of the CRT. Just checking dependencies is not enough, as you might miss those. Doing a full install on a clean machine is the only safe solution, IMO.

If you don't want to setup a full-blown test environment and have Windows 7, you can use XP-Mode as the initial clean machine, and XP-More to duplicate the VM.

On your development machine, you can execute the program and run Sysinternals Process Explorer. In the lower pane, it will show you the loaded DLLs and the current paths to them which is handy for a number of reasons. If you are executing off your deployment package, it would reveal which DLLs are referenced in the wrong path (i.e. weren't packaged correctly).

Currently, our company uses Visual Studio Installer projects to walk the dependency tree and output as loose files the program. In VS2013, this is now an extension: https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d. We then package these loose files in a more comprehensive installer but at least that setup project all the dot net dependencies and drops them into the one spot and warns you when things are missing.

NDepend was already mentioned by Jesse (if you analyze .NET code) but let's explain exactly how it can help.

Is there a program/script that can scan an executable for DLL dependencies or execute the program in a "clean" DLL-free environment for testing to prevent these oops situations?

In the NDepend Project Properties panel, you can define what application assemblies to analyze (in green) and NDepend will infer Third-Party assemblies used by application ones (in blue). A list of directories where to search application and third-party assemblies is provided.

https://i.stack.imgur.com/bT0I8.png

If a third-party assembly is not found in these directories, it will be in error mode. For example, if I remove the .NET Fx directory C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319, I can see that .NET Fx third-party assemblies are not resolved:

https://i.stack.imgur.com/7vWUV.png

Disclaimer: I work for NDepend

In the past (i.e. WinXP days), I used to depend/rely on DLL Dependency Walker (depends.exe) but there are times when I am still not able to determine the DLL issue(s). Ideally, we'd like to find out before runtime by inspections but if that does not resolve it (or taking too much time), you can try enabling the "loader snap" as described on http://blogs.msdn.com/b/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspx and https://msdn.microsoft.com/en-us/library/windows/hardware/ff556886(v=vs.85).aspx and briefly mentioned LoadLibrary fails; GetLastError no help

WARNING: I've messed up my Windows in the past fooling around with gflag making it crawl to its knees, you have been forewarned.

https://i.stack.imgur.com/kfCu9.png

Note: "Loader snap" is per-process so the UI enable won't stay checked (use cdb or glfags -i)

Please refer SysInternal toolkit from Microsoft from below link, https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

Goto the download folder, Open "Procexp64.exe" as admin privilege. Open Find Menu-> "Find Handle or DLL" option or Ctrl+F shortcut way.

https://i.stack.imgur.com/FMQyf.png

Try Dependencies it is described as "An open-source modern Dependency Walker".

It has a GUI but it also works from the command line with optional JSON output!

To display recursively the dependencies of mydll.dll up to a depth of 1:

Dependencies.exe -chain mydll.dll -depth 1

Example of output:

  □ mydll.dll (ROOT) : C:/.../mydll.dll
|  □ USER32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\user32.dll
|  □ ADVAPI32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\advapi32.dll
|  □ ole32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\ole32.dll
|  □ GDI32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\gdi32.dll
|  □ CRYPT32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\CRYPT32.dll
|  □ Secur32.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\Secur32.dll
|  □ MSVCP140D.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\MSVCP140D.dll
|  □ USP10.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\USP10.dll
|  □ KERNEL32.dll (WellKnownDlls) : C:\WINDOWS\SysWOW64\kernel32.dll
|  □ VCRUNTIME140D.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\VCRUNTIME140D.dll
|  □ ucrtbased.dll (WindowsFolder) : C:\WINDOWS\SysWOW64\ucrtbased.dll

Note that it may take a long time to produce a result if the maximum dependency depth is deep.

Was the DLL compiled in "Debug Mode" and then deployed?

If so, it may depend on "D" versions of DLLs. For example:

  MSVCP140D.dll
  VCRUNTIME140D.dll

These would not be dependents if the DLL is built in "Release Mode." The D versions do not come with the Microsoft Visual C++ Redistributables.

To see if that is the case, as others have pointed out:

From Visual Studio: Tools -> Visual Studio Command Prompt.

In the command prompt run dumpbin /dependents against the DLL.