Module Dependency Tree View

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:


Normal Images

bullet Normal module with no errors.

bullet Duplicate module. This module has already been processed somewhere else in the tree. You can use the Highlight Original Instance Command to find the original instance of the module in the tree.

bullet Forwarded module. This module is a dependency because the parent module has forwarded one of its functions to this module.

bullet Delay-load module. This module will be dynamically loaded if any of its exported functions are actually called at run-time.

bullet Dynamic module. This module was detected during profiling and was dynamically loaded or used by its parent module. If the module has no parent, then Dependency Walker was unable to determine who loaded the module. See Using Application Profiling to Detect Dynamic Dependencies for more information.

bullet This module was dynamically loaded by a call to the LoadLibraryEx function with the DONT_RESOLVE_DLL_REFERENCES flag and/or the LOAD_LIBRARY_AS_DATAFILE flag. These flags cause the module to get mapped into memory without loading its dependent modules or calling the module's DllMain function.

bullet 64-bit module. This module is designed to run on a 64-bit versions of Windows. Modules are assumed to be 32-bit if this image is not present.


Warning and Error Images

bullet Missing module. This module could not be found in the search path. See the Configure Search Order Command for more information.

bullet Invalid module. See the Module List View for an error message describing the module error.

bullet Module warning. This module is either missing one or more export functions that are required by its parent module, is of the wrong CPU type, or failed to initialize when being loaded. For a missing export, the Parent Import Function List View will list the actual unresolved functions that are causing the problem. For implicit dependencies, this is an error that will cause the parent module to fail to load. If the module failed to load or initialized, then check the Log View for details on the failure.

bullet Delay-load module warning. This module is either missing one or more export functions that are required by its parent module, or is of the wrong CPU type. For a missing export, the Parent Import Function List View will list the actual unresolved functions that are missing. For delay-load dependencies, this is most likely not an error since one reason developers use delay-load modules is when they are unsure if a particular function exists in dependent module. Parents of delay-load modules have techniques for recovering from missing exports in the delay-loaded dependent module.

bullet Dynamic module warning. This module is either missing one or more export functions that the parent module attempted to retrieve using GetProcAddress, is of the wrong CPU type, or failed to initialize when being loaded. For a missing export, the Parent Import Function List View will list the actual functions that the parent module could not locate. For dynamic dependencies, this is usually just a warning, since it is perfectly valid for a module to dynamically check for the existence of a function in another module, even if the function does not exist. If the module failed to load or initialized, then check the Log View for details on the failure.


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.