Depends.exe and working with assembly dependencies
So in
my last blog article I talked about using the fuslogvw.exe tool to figure out .NET assembly binding issues. In this article I’m going to look at another tool that I find myself using daily in the debugging world, depends.exe. In a nutshell, depends looks at your binary files and creates a tree of all their dependencies along with some other useful information. Unlike fuslogvw.exe this works with both .NET and native applications. You can get depends from the official site and it also ships with many different Microsoft development products so you may already have it present on your system. You’ll want to use depends when one of your programs fails to load with some sort of system error or initialization message. I make it a habit to check any program that fails on startup with depends first so that I don’t waste any time trying to debug what is just a missing assembly or a versioning mismatch.
At a basic usage level depends is super simple to operate, just load depends and do a file open on the binary file that you are having issues with. When the file opens up you should see something similar to what I’m showing below.
This example I just did using by using notepad.exe. In the top-left pane you can see the tree structure of all the dependent assemblies of notepad. In the middle pane you can see more detailed information about all of the items in the dependency tree. And in the bottom you can see any errors that popped up during analysis. As you can see, some errors are benign as I currently have a possible error in notepad.exe but it runs just fine. Another benign example is that MSJAVA.dll often shows up as missing in the dependency tree but the application will run just fine without it.
So we’ve seen what depends looks like when a binary with all its binaries is correctly added. So what types of errors and mistakes can depends help you to find? Here is a quick list of the ways that I’ve used depends or seen depends used:
1. As a quick way to check the architecture of a binary
2. CRT side by side issues for msvcr80.dll
3. Discovering that a driver was linking in user mode code (a big no-no)
4. Checking the timestamps of dependent files
5. Checking to see what version of a dependent file is being loaded
So if you are running into initialization or dependency issue with your native or managed applications give depends a try to see what you turn up.