So in
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.