ldd for Windows - and more!
.dwp
files.vcxproj
and .vcxproj.user
filesTry it out:
dependency_runner> cargo run --bin deprun -- test_data\test_project1\DepRunTest\build\DepRunTest\Debug\DepRunTest.exe --check-symbols --userpath test_data\test_project1\DepRunTestLibWrong\build\Debug
DepRunTest.exe => C:\Users\Marco Esposito\Projects\personal\dependency_runner\test_data\test_project1\DepRunTest\build\DepRunTest\Debug
DepRunTestLib.dll => C:\Users\Marco Esposito\Projects\personal\dependency_runner\test_data\test_project1\DepRunTestLibWrong\build\Debug
Checking symbols...
No missing libraries detected
Missing symbols detected!
[Importing executable, exporting executable, missing symbols]
DepRunTest.exe
DepRunTestLib.dll
public: float TestClass::testMethod(int)
This repository contains tools to analyze the dependencies of a Windows Portable Executable (PE) file, usually in order to debug application startup problems.
These tools are:
wldd
, a reimplementation of GNU ldd
for Windows PE executables (exe
and dll
files).
An effort is made in order to keep the output similar to that of the original tool, so that
existing scripts targeting Linux executables can be reused easily. The current
API may be extended in the future to include new features allowed by the Win32 executable format.
However, priority will be given to avoiding breaking changes in the output format.
While ldd
invokes the loader and inspects the result in memory, wldd
doesn't. The
Windows loading process is emulated, thus the address at which each library is loaded is not
included into the output. This may change in the future.deprun
, a further CLI tool that, in contrast to wldd
, is not limited by the
constraint of keeping compatibility with ldd
. By default, dependencies are printed as a tree
for better readability. It supports multiple lookup path specifications
and output formats, including to a JSON file. It includes a DLL and symbol browser with fuzzy search integrated
through skim. It can parse Dependency Walker's .dwp
files,
as well as Visual Studio .vcxproj
and .vcxproj.user
files to read the executable location,
working directory and user path.All these tools target Windows PE exe files, but are designed to be portable. The default behavior attempts to guess sane defaults to make it easy to inspect executables located on a neighboring Windows installation from another operating system, or to ignore missing system libraries if no such partition is available on the system. The example above should work on any operating system.
/usr/local/bin
is a good placecd
into itcargo build --release
target/release
to somewhere on your PATH
/usr/local/bin
is a good placedeprun path/to/your/executable.exe
Default behavior:
C:\Windows
and C:\Windows\System32
as "Windows" and "System" directoriescwd
C:\Windows
and C:\Windows\System32
directories will be usedcwd
deprun --depth 4 path/to/your/executable.exe
deprun --output-json-path path/to/output.json path/to/your/executable.exe
Each executable will be represented by a single object. The dependency tree can be reconstructed from the dependency list of each node.
deprun --print-system-dlls path/to/your/executable.exe
deprun --skim path/to/your/executable.exe
deprun --dwp_path=path/to/config.dwp path/to/your/executable.exe
deprun --vcx-config=Release path/to/visual_studio_solution/executable.vcxproj
The configuration must only be provided if more than one are listed in the vcxproj file.
deprun --vcx-config=Release --vcxproj_user_path=path/to/visual_studio_solution/executable.vcxproj.user path/to/visual_studio_solution/executable.vcxproj
The configuration must only be provided if more than one are listed in the vcxproj file. The executable can also be referred to directly, instead of providing the path to the .vcxproj file.
deprun --check-symbols path/to/your/executable.exe
deprun --skim-symbols path/to/your/executable.exe
a subset of the above, check with -h
Help is welcome in the form of issues and pull request!
ldd
functionalities in wldd
.dwp
file.vcxproj.user
files, picking configuration.vcxproj
files, picking configurationldd
functionalities in wldd
dependency_runner
GUI?
LoadLibraryEx
and similar mechanism can't be inspected without letting the program run.
This limitation is common to other similar tools that recursively scan executables files and parse their import tables. LGPLv3