The Module Dependency Tree View displays a hierarchical view of all the modules' dependencies. There are several ways a module can be a dependency of another module. For more information on dependency types, see the Types of Dependencies Handled By Dependency Walker section.
Dependency Walker starts with the root module you chose to open and scans its import tables to build a list of required dependent modules. Dependency Walker then scans each of these dependent modules for their dependent modules. This recursion continues until all modules and their dependent modules have been processed.
To prevent a bloated tree and possible infinite circular loops with dependent modules, Dependency Walker stops processing a given branch of the tree when it reaches a module that it has already processed somewhere else in the tree. Duplicate modules are marked with a small arrow in the middle of their accompanying image (see below). To determine what the branch would have looked like if Dependency Walker had processed it, use the Highlight Original Instance Command to find the original instance of the module in the tree.
Dependency Walker also scans each dependent module looking for forwarded function calls to other modules. If a forwarded function is found and actually called by the parent module, then the module that the function is forwarded to is also pulled in and added to the dependency tree. These forwarded modules are specially marked in the dependency tree with a small state image next to their accompanying image (see below).
While processing the dependency tree, Dependency Walker performs several validity checks along the way. It checks to make sure each module is a valid 32-bit or 64-bit Windows module. It checks for mismatched binaries, such as an x86 module with an Alpha module. It scans import and export function tables looking for unresolved external functions. It checks for circular dependencies, which are allowed, and for circular forwarded dependencies, which are not allowed. Any errors that are encountered while processing the tree will be displayed using a special image (see below) for the particular modules in error and/or by a message box.
The Auto Expand setting controls how much of the tree is initially seen after loading a module. When this option is turned on, the entire tree will be displayed. When the option is turned off, only the root module, its immediate dependencies, and modules with errors will be shown.
Modules can be displayed using full file paths or just the file name to conserve screen space. You can control what is displayed using the Full Paths option. You may also copy the selected module's file name or path to the clipboard by selecting the Copy Command. The actual text copied will differ depending on how the Full Paths option is set. The contents of the Module Dependency Tree View can also be saved to a text file using the Save Command or Save As Command.
The following is a table of the primary images that can accompany each module in the dependency tree. This list is just a subset of all the possible images. Actual images can be a combination of one or more of the following images:
See the How to Interpret Warnings and Errors in Dependency Walker section for more details on module errors.
It is possible for a module to show up more than once as a dependency of a single parent module. Dependency Walker does this to inform you that this module is a dependency for more than one reason. A module can show up as an implicitly linked dependency, a forwarded dependency, and a dynamic dependency, all under a single parent module.
For example, if module A implicitly links to module B, you will see module B under module A as an implicit dependency. The functions listed in the Parent Import Function List View for that instance of module B are what is required for module A to be able to successfully load. During runtime profiling, if module A dynamically loads module B, a second instance of module B will appear under module A, but this time with a different image (see above) signifying that it was dynamically loaded. The functions listed in the Parent Import Function List View for this second instance of module B are what module A looked for in module B at runtime using the GetProcAddress function call.