Module List View

Dependency Walker


Module List View


The Module List View displays a list of all unique modules that are dependencies for the root module you opened. This list defines the set of files needed for the module to load and execute as a running process.

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 modules' file names or paths to the clipboard by selecting the Copy Command. The actual text copied will differ depending on how the Full Paths option is set. If more than one module is selected, a list will be copied to the clipboard with carriage returns after each module. The complete contents of the Module List View can also be saved to a text file or comma separated value (CSV) file using the Save Command or Save As Command.

There is not a one-to-one relationship between the modules listed in this list view and the modules listed in the Module Dependency Tree View. This list view shows the unique set of modules, where as the tree view shows all the module relationships. A module like KERNEL32.DLL may show up dozens of times in the tree view since many other modules depend on it, but it will only show up once in this list view. Some instances of KERNEL32.DLL might be implicitly loaded, while others may be dynamically loaded. Some might have import / export mismatch errors, while others may have no errors. Since there is not a one-to-one relationship between the two views, the module list view tries to use images for modules that encapsulate the state of all instances of each module in the tree view. For example, if KERNEL32.DLL appears in the tree view ten times with no errors and one time with an import / export mismatch error, then the list view will show KERNEL32.DLL as having an import / export mismatch error.

Dependency Walker also gives precedence to certain types of dependencies. If a module is implicitly required for an application to load, then it will appear with the implicit module image in the module list view. This is true even if the module is also listed as a delay-load or dynamic dependency in the tree view, since an implicit dependency is the most significant type of dependency and is required for the application to load. If a module is dynamically loaded or is a child of a dynamically loaded module, then it will appear with the dynamic module image in the list view. If a module is delay-loaded or is a child of a delay-loaded module, then it will appear with the delay-load module image in the list view. If a module is both a delay-load and dynamic dependency, it will be shown as a dynamic dependency in the list view since modules that actually get dynamically loaded are given precedence over delay-loaded modules that don't get loaded. This can cause images in the list view to change from delay-load to dynamic as modules get loaded dynamically.

The following is a table of the primary images that can accompany each module in the Module List View. 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 All instances of this module were normal and had no errors. If no delay-load image (hour glass) or dynamic image (star / asterisk) is to the left of this module image, then at least one instance of this module is implicitly required for the root module to load.

bullet All instances of this module are marked as delay-load or are children of modules marked as delay-load. Modules with this image will change to dynamic dependencies at runtime if the module is actually loaded.

bullet All instances of this module were dynamically loaded and detected during profiling. See Using Application Profiling to Detect Dynamic Dependencies for more information.

bullet All instances of this module were dynamically loaded by calls 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. If a module with this image is later loaded without the DONT_RESOLVE_DLL_REFERENCES and LOAD_LIBRARY_AS_DATAFILE flags, then the image will change to the standard dynamic dependency image above.

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. This module will be accompanied by an error message to describe the problem.

bullet Module warning. At least one instance of 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 load at runtime. Locate the offending module(s) in the Module Dependency Tree View and then look in the Parent Import Function List View for that module to see the actual unresolved functions that are causing the problem. This may or may not be an error. If the offending module(s) are marked as dynamic, then this is just a warning since it is valid for modules to call GetProcAddress to dynamically check for a function and fail to find it. If the offending module(s) are delay-load, then this is also probably not an error since one reason developers use delay-load dependencies is when they are unsure if a function exists in a dependent module. If the offending module(s) are implicit or forwarded dependencies, then this is an error and will cause the parent of those modules to fail to load. If no export functions are missing, then check the Log View to see if the module error is related to a load failure.


See the How to Interpret Warnings and Errors in Dependency Walker section for more details on module errors.

The Module List View contains several columns of information about each module. These columns include:

Image See above list for descriptions.
Module Full path or file name for the module file. See the Full Paths option for toggling between the two modes.
File Time Stamp Date and time of the module file. This is the time that the file was last saved.
Link Time Stamp Date and time that the module was built. This is a value that the linker stores in the file itself.
File Size Size of the module file.
Attr. Attributes of the module file. Possible values are R (read only), H (hidden), S (system), A (archive), C (compressed), T (temporary), O (offline), and E (encrypted).
Link Checksum The module checksum from when the module was built. This value is set by using the linker's /RELEASE command line option. If this linker option is not specified, then the checksum may be zero. This value will be shown in red if it is not zero and does not match the actual module checksum. If the values do not match, it means that the module has been modified after it was built.
Real Checksum The actual module checksum. This value is computed by Dependency Walker and should match the checksum computed by the linker when the module was built.
CPU Type of CPU that the module was built for. Possible values are x86, Intel 64, Alpha AXP, Alpha 64, PowerPC, MIPS R3000 BE (big endian), MIPS R3000, MIPS R4000, MIPS R10000, MIPS WinCE V2, SH3, SH3E, SH4, SH5, ARM, Thumb, MIPS 16, MIPS FPU, MIPS FPU 16, CEE, and CEF. This value will be shown in red if it does not match the CPU type of the root module in the session. This value is set by using the linker's /MACHINE command line option.
Subsystem Type of subsystem that the module was built to run in. Possible values are Native, GUI, Console, Win9x driver, OS/2 console, Posix console, WinCE 1.x GUI, and WinCE 2.0+ GUI, EFI, and Xbox. This value is set by using the linker's /SUBSYSTEM command line option.
Symbols Type of debugging symbols that are associated with the module. Possible values are None, DBG (debug), PDB (program database), CV (codeview), COFF (common object file format), FPO (frame pointer omission), OMAP, and Borland. If one or more of the debug blocks are invalid, then the word "Invalid" will also appear. This usually means that debug symbols have been striped from the file, but the debug entries were left behind.
Preferred Base The preferred base load address of the module. This will be 32-bits for 32-bit modules and 64-bits for 64-bit modules. This value is set by using the linker's /BASE command line option.
Actual Base The actual base load address of the module. This value will read "Unknown" until the module has actually been loaded into memory by Dependency Walker's profiler. See the Start Profiling Command for more information. This value will be shown in red if it does not match the preferred base address for the module. Your application will suffer a load-time performance hit for every module that does not load at its preferred base address. This value will read "Data file" if the file was loaded as a data file via a call to LoadLibraryEx with the LOAD_LIBRARY_AS_DATAFILE flag.
Virtual Size The virtual size of the module. This is the size of memory that will be reserved for the module to be mapped into.
Load Order The load order of the module with respect to other modules. This value will read "Not Loaded" until the module has actually been loaded into memory by Dependency Walker's profiler. See the Start Profiling Command for more information.
File Ver The file version found in the module's version resource. This value represents the FILEVERSION field in the VERSION_INFO resource structure. It will read "N/A" if the module does not contain a VERSION_INFO resource.
Product Ver The product version found in the module's version resource. This value represents the PRODUCTVERSION field in the VERSION_INFO resource structure. It will read "N/A" if the module does not contain a VERSION_INFO resource.
Image Ver The image version found in the module's file header. This value is set by using the linker's /VERSION command line option.
Linker Ver The version of the linker that was used to create the module file.
OS Ver The version of the OS that the module file was built to run on.
Subsystem Ver The version of the subsystem that the module file was built to run in. This value is set by using the linker's /SUBSYSTEM command line option.


The module list can be sorted on the data in any column in the list. Simply click on the column header button for the column you wish to sort by. An arrow (^) is displayed in the column header for the column that the list is currently sorted by. You can also size a column to its "best fit" width by double-clicking the divider line between two columns in the column header. You can search for text in the currently sorted column by simply typing in the first few characters of the item you wish to find.

If a module was not found or was not a valid 32-bit or 64-bit Windows binary, then an error message will be displayed in place of the normal column information for that module.