191

Sometimes when I'm doing a little project I'm not careful enough and accidentally add a dependency for a DLL that I am not aware of. When I ship this program to a friend or other people, "it doesn't work" because "some DLL" is missing. This is of course because the program can find the DLL on my system, but not on theirs.

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

TylerH
  • 19,065
  • 49
  • 65
  • 86
orlp
  • 98,226
  • 29
  • 187
  • 285
  • 2
    The debugger shows every DLL that gets loaded in the Output window. The Debug + Windows + Modules shows a list of them. Be sure that you can account for all of them. And test your installer like you test your code, use a VM. – Hans Passant Sep 11 '11 at 15:26
  • @Hans Passant: Can I find a full list of standard windows DLL's somewhere? – orlp Sep 11 '11 at 15:34
  • Yup, in c:\windows\system32 with a Microsoft copyright. – Hans Passant Sep 11 '11 at 15:37
  • 6
    @orlp - You might also try `dumpbin /dependents `. I'm guessing the list will be more relevant than listing all DLLs in `%SYSTEM%` or `%SYSTEM32%`. Also see [DUMPBIN Options](https://msdn.microsoft.com/en-us/library/756as972.aspx) on MSDN. – jww Jan 10 '17 at 08:00

14 Answers14

243

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

dumpbin /dependents your_dll_file.dll
JeffRSon
  • 8,871
  • 3
  • 22
  • 47
  • 7
    Handy little tool, and saves having to install anything new when you already have VS installed. – James Apr 30 '15 at 11:20
  • 14
    Yes, `dumpbin.exe` is very useful to figure out `/dependents` and `/imports`. You can also use it on other machines if you copy `link.exe` along with it and make sure the corresponding [x86 Visual C++ Runtime Redistributable (`msvcr120.dll` for Visual Studio 2013)](https://www.microsoft.com/de-de/download/details.aspx?id=40784) is available on the target machine. Some options have additional dependencies. - By the way, they screwed up the option name, it should have been `/PREREQUISITES` rather than `/DEPENDENTS`, they should have studied Latin. – Lumi Nov 07 '15 at 20:18
  • If you get an error message with `mspdb110.dll not found`, try launching the 64 version instead `VC\bin\amd64\dumpbin.exe` before re-installing Visual Studio ;) – ThomasGuenet Aug 08 '17 at 10:25
  • 2
    It's so great, we added this into our build system as a verification step when the final executable is generated so we don't depend on something that is not included in the shipping. – Lothar Nov 09 '17 at 00:45
  • 7
    The only drawback is this handy tool is very hidden: c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\Hostx64\x64>dumpbin – rkachach Sep 27 '18 at 09:48
  • `dumpbin` only lists DLLs but doesn't check for their presence. – ivan_pozdeev Feb 04 '19 at 15:25
  • For VS2017 or VS2019 this answer works perfectly well to ensure `dumpbin` is available on your machine: https://stackoverflow.com/a/50710182/4625433 – Amaury Levé Sep 03 '19 at 16:00
  • 5
    @rkachach If you open the Visual Studio command line (Tools -> Visual Studio Command Prompt) this is recognized as an external command and you only need to type "dumpbin". – Bemipefe Oct 23 '19 at 14:59
  • @JeffRSon this didn't work for my DLL. I know the tensorflow.dll I downloaded epends upon a cuda DLL. It displays an error stating such when I run the program. However the dumpbin command does not list any cuda DLLS as a dependency. – John Rocha Dec 05 '19 at 18:42
  • 1
    Well, that's probably because the tensorflow dll loads this cuda dll via LoadLibrary. Such dependencies cannot be detected. – JeffRSon Dec 05 '19 at 19:29
  • 1
    @rkachach just open start menu, type "dev" and open Developer Command Prompt (which is the same as Tools > Visual Studio Command Prompt in VS), or run vcvarsall.bat manually – phuclv Mar 18 '20 at 03:09
  • This is the best answer for me! – yushulx May 27 '20 at 00:55
  • @JeffRSon `ldd` (see the answer below this one) detects recursive DLL dependencies just fine. – Will Jul 26 '20 at 07:34
  • "The code execution cannot proceed because mspdb110.dll was not found"... the project builds fine on another machine... just kill me. – B H Aug 19 '20 at 16:51
138

Try Dependencies (Dec 2019) which is a modern rewrite of the famous Dependency Walker (last update in 2006)

np8
  • 14,736
  • 8
  • 50
  • 67
Luchian Grigore
  • 236,802
  • 53
  • 428
  • 594
  • 6
    If possible, I will trust only the original OS provider, since ddl dependency should be OS job.. Does any Microsoft utility program can do this? Command line is fine for me. – Robin Hsu Jan 19 '15 at 03:50
  • 4
    @RobinHsu: DependencyWalker used to ship with Visual Studio until Visual Studio 2005. The most recent build is included with the [Windows Driver Development Kit](https://msdn.microsoft.com/en-US/windows/hardware/gg454513) (and not available through the official web site). Still not officially a Microsoft tool, but sanctioned, promoted, and advertised by Microsoft. – IInspectable May 02 '16 at 10:14
  • 1
    @TankorSmash: [pestudio](https://www.winitor.com/index.html) is seemingly more robust in listing dependencies. The tool is available both as a free download as well as a professional (commercial) version. Both editions are capable of listing a module's dependencies. – IInspectable May 02 '16 at 10:31
  • 8
    `dumpbin` over dependency walker. https://msdn.microsoft.com/en-us/library/756as972.aspx | http://stackoverflow.com/a/28304716/3543437 – kayleeFrye_onDeck Apr 27 '17 at 20:06
  • @TankorSmash No, it's not dated. It works very well on a Win10 machine to check c++/cli dlls. See how up to date it is? – Felix Jun 29 '17 at 08:46
  • 10
    There is now an open source rewrite partially done in C#, meet "**Dependencies.exe**": https://github.com/lucasg/Dependencies. Test impression: **a bit beta-ish**, but it handles **API-sets** and **SxS** apparently (missing from Dependency Walker). – Stein Åsmul Dec 14 '17 at 12:15
  • 3
    Additionally, you can always use [**procmon.exe**](https://docs.microsoft.com/nb-no/sysinternals/downloads/procmon) from Sysinternals to debug advanced dependency problems (and other problems). [**See this answer for how to set an include filter for procmon.exe**](https://stackoverflow.com/a/47792474/129130) so the output is "digestible" (in this case for debugging regsvr32.exe events). – Stein Åsmul Dec 14 '17 at 12:19
  • @SteinÅsmul that tool is amazing – Winston Henke Apr 26 '20 at 15:05
  • Yes, agree. It is the "go to tool" for "anything", but it takes time to look through all the information. – Stein Åsmul Apr 26 '20 at 15:08
57

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.

tro
  • 6,152
  • 5
  • 42
  • 63
  • I just install the cygwin and was happy to find back linux commands, but I could not get out of the Cygwin root to acces other files on my local drive (C:). Is that normal? – ThomasGuenet Aug 08 '17 at 08:37
  • 1
    I think this could help you: https://stackoverflow.com/questions/1850920/how-to-navigate-to-a-directory-in-c-with-cygwin – tro Aug 08 '17 at 13:35
  • 5
    Unfortunately, there are some dependencies that are not found this way: `$ ldd ./Debug/helloworld.exe ??? => ??? (0x77d60000)`. The utility dumpbin shows all dependencies correctly. – fgiraldeau Aug 08 '18 at 22:10
  • 5
    I use ldd through GIT BASH terminal on windows and works fine. So if you have git it wil be easy, no need to install cygwin. Example: borkox@bobipc MINGW64 ~ $ ldd /c/Users/borkox/.javacpp/cache/openblas-0.3.0-1.4.2-windows-x86_64.jar/org/bytedeco/javacpp/windows-x86_64/jniopenblas_nolapack.dll ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe46910000) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffe46610000) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffe42d40000) msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffe44120000) – Borislav Markov Aug 21 '18 at 20:00
  • 1
    As someone who already had git bash installed, this was a preferable solution. Thank you! – Nicolas May 08 '19 at 17:45
34

  1. Figure out the full file path to the assembly you're trying to work with

  2. Press the start button, type "dev". Launch the program called "Developer Command Prompt for VS 2017"

  3. In the window that opens, type dumpbin /dependents [path], where [path] is the path you figured out in step 1

  4. press the enter key

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

enter image description here

Update for VS 2019: you need this package in your VS installation: enter image description here

Iamsodarncool
  • 573
  • 4
  • 9
  • 1
    "Bam" all you want, but I don't find `dumpbin` all that useful, because it isn't recursive. If any DLL dependency in turn depends on a DLL not already among the list of direct dependencies, you're still screwed. Better to use a tool that isn't half-assed, such as `ldd`. – Will Jul 26 '20 at 02:56
11
  1. There is a program called "Depends"
  2. If you have cygwin installed, nothing simpler then ldd file.exe
Artyom
  • 30,091
  • 20
  • 121
  • 208
9

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.

eran
  • 20,710
  • 4
  • 52
  • 86
6

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.

mzuther
  • 1,114
  • 1
  • 12
  • 24
Shiv
  • 1,064
  • 1
  • 13
  • 20
3

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.

NDepend Project Properties Application and Third-Party assemblies

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:

NDepend Project Properties Application and Third-Party assemblies not resolved

Disclaimer: I work for NDepend

Pang
  • 8,605
  • 144
  • 77
  • 113
Patrick from NDepend team
  • 12,441
  • 4
  • 53
  • 72
2

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.

enter image description here

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

Community
  • 1
  • 1
HidekiAI
  • 2,783
  • 3
  • 17
  • 22
2

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.

enter image description here

Dattatraya Mengudale
  • 157
  • 1
  • 5
1

If you have the source code, you can use ndepend.

http://www.ndepend.com/

It's pricey and does a lot more than analyzing dependencies so it might be overkill for what you are looking for.

Jesse
  • 1,474
  • 18
  • 18
  • 3
    Being a tool specifically tailored for .NET, does it analyze dependencies for native images as well? – IInspectable May 02 '16 at 10:18
  • Probably not, @IInspectable. I don't think .NET has a way to do that, except possibly using something P-Invoke. – kayleeFrye_onDeck Apr 27 '17 at 23:15
  • @kayleeFrye_onDeck: Parsing import tables boils down to reading files. .NET can read files. – IInspectable Apr 27 '17 at 23:38
  • Yep! And yet, there's no .NET API to do this :( What do you suggest? I'm not really a .NET programmer, just someone who uses it when lower level solutions don't pan out. There's a decent selection of inspection tools out there, but very few for Windows are distribute-friendly, let alone fast... I was looking to use it to inspect an unknown amount of binaries recursively to detect frameworks used when compiled, so I could treat them with special params ad-hoc. I might have to look into using `LoadLibraryEx`... – kayleeFrye_onDeck Apr 27 '17 at 23:50
  • 1
    @kayleeFrye_onDeck: There is nothing in the Windows API either to read import tables of modules. You have to read files and parse the contents. No difference between native code and .NET. `LoadLibraryEx` doesn't help there. – IInspectable Apr 28 '17 at 20:46
  • Would you happen to know if they be parsed using simple string queries, or is traversing the relative virtual addresses required to do so? If I can do simple queries instead of address-based ones, I'd like to know how so I can just make a regex for finding DLL name patterns. – kayleeFrye_onDeck Apr 28 '17 at 20:52
1

Please search "depends.exe" in google, it's a tiny utility to handle this.

shiying yu
  • 103
  • 6
  • 7
    Note that dependency walker is quite dated, and doesn't co-op well with 64 bit. It will definitively show all dependent DLLs, which is what the OP is looking for, but it also adds noise - you'll find you're 32 bit executable missing some 64 bit dlls and so on... Sadly, there's still no better alternative. – eran Sep 11 '11 at 14:57
  • @RestlessC0bra Not that I know of, but I haven't been doing Windows development for the last 5 years. Dependency walker is dead for sure, and it's a shame Microsoft neither bothered to update this useful tool nor opened its source so others could keep it alive. – eran Feb 18 '17 at 20:09
  • 1
    @RestlessC0bra: Dependency Walker is dead. It never caught up with 64-bit modules. If you look closely enough, a lot of that extensive use of Dependency Walker leads to Stack Overflow questions, asking why something is happening. That something never happens, though. It's just a false negative/positive. [Process Monitor](https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) should be your preferred tool. – IInspectable Apr 28 '17 at 20:51
  • 1
    "dumpbin" should be the preferred tool. It's a command line tool. The good is that it can even be scripted and included into your build process and pre-release verification step. Saved us from a few bugs already. – Lothar Nov 09 '17 at 00:50
0

The pedeps project (https://github.com/brechtsanders/pedeps) has a command line tool (copypedeps) for copying your .exe (or .dll) file(s) along with all the files it depends on. If you do that on the system where the application works, you should be able to ship it with all it's dependancy DLLs.

Brecht Sanders
  • 2,726
  • 1
  • 8
  • 18
0

Try JetBrains dotPeek. It's free.

tedebus
  • 669
  • 9
  • 19