On windows10 I have unzipped the repo but there are no Dependencies.exe files to be found. do I need to build them? I have ms VisualStudio but no idea what to do.

On the Windows x64 machine, if you open the following file:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Common7\IDE\Remote Debugger\x86\msvsmon.exe

An error occurs at this location.

DependenciesGui\DependencyWindow.xaml.cs:627 AssemblyDefinition PeAssembly = AssemblyDefinition.ReadAssembly(newPe.Filepath);

Maybe when you open a file that's not a dotnet assembly, you get a fault.

I've revised it. Please review it.

Ordinals and hints shall be unsigned 16bit numbers, but Dependencies displays them as signed 32bit numbers. Tested on 64bit Windows 7 with 64bit Dependencies v1.10.0.0 inspecting a 64bit version of API Monitor (https://www.rohitab.com/apimonitor).

Best regards, Marek Knápek

Hi,

First of all, this tool has been a lifesaver for me! I use it to ensure that no new API functions are used unless reviewed for compatibility (such as software designed to support Windows 7 starts using something available from Windows 8 only).

I wonder if "dependencies.exe -imports" output can be optionally sorted by name? The issue here is every time the exe dependencies are changed, the order of imports changes too. Which makes it difficult to DIFF during our reviews. If these are sorted, DIFF would work just fine.

I could try to post-process it via command line sort utilities, but it's not an easy solution because the output is structured by module name and line-level sorting breaks this structure.

Thanks!

Something that initially threw me off when I tried this utility out was that the import list (top right) behaves differently than the original Depends utility.

In the original Depends, when you select a module from the tree view (left), the import list shows those functions that are imported from the selected module by its parent in the tree. Modules would also be shaded red if any of the functions expected to be imported from them were missing.

In this Dependencies utility, when you select a module from the tree view or from the module list, the import list shows those functions that are imported by (i.e. exported to) the selected module from its child dependencies in the tree.

I actually prefer the old Depends behavior. From the tree view I can easily see the module dependencies of a particular parent. And from the import list I can easily see the parent's function dependencies from a particular module. In this Dependencies utility I have to select a parent, sort its imports by module, and search through the list to find out what it imports from a particular module.

I'd like to see a user setting to enable the old Depends behavior. In this mode, the Module and Delayed columns of the Import list might be removed, and selecting a module from the module list (bottom) would have no effect on the import/export lists.

I downloaded version 1.10 and I use Windows 8, but I got this when opening a dll:

What is this dbghelp.dll he is looking for?

Is this related to https://github.com/lucasg/Dependencies/issues/108 Crash in undecorator ? When would a new version be released with that fix?

In Windows 7 64bit there is rpcrt4.dll listed as known DLL. In its 32bit variant rpcrt4.dll statically depends on sspicli.dll which statically depends on cryptbase.dll. But 64bit variant of rpcrt4.dll depends on sspicli.dll only as delay loaded and sspicli.dll depends on cryptbase.dll also only as delay loaded. So this means that both 32bit variants of sspicli.dll and cryptbase.dll are considered as known DLLs and both 64bit variants of sspicli.dll and cryptbase.dll are not considered as known DLLs. Yes, it is that crazy. You can check this by using winobj.exe program from http://sysinternals.com/, there are two "folders", one called KnownDlls and other called KnownDlls32.

Now, I create DLL named cryptbase.dll and an EXE which statically depends on it and compile them both as both 32bit and 64bit. What happens is that 32bit EXE loads cryptbase.dll from system directory (because it is a known DLL) and 64bit EXE loads cryptbase.dll from application directory (because it is not a known DLL). You can check this by Process Hacker (https://processhacker.sourceforge.io/).

Both Dependency Walker and Dependencies report cryptbase.dll dependency in 32bit variant wrong.

Best regards, Marek Knápek

Steps to reproduce:

• Download and unzip v1.10.
• Run release version for x86 on Windows 7 x64.
• Main menu -> File -> Open.
• Open itself (DependenciesGui.exe).
• Click on first DLL (C:\Windows\SysWOW64\mscoree.dll).
• CRASH!

I tried to attach an debugger after program startup and before crash and I observed a few things:

• The crash happens in file ref.c, in function PhDereferenceObject, on line 243, variable objectHeader has address of 0xFFFFFFF8.
• That is probably because function sooner on call stack named UndecorateSymbolDemangleName failed to undecorate name in file demangle.cpp on line 221 and is passing a NULL variable into PhDereferenceObject on line 228.
• I think, the program failed to demangle "_CorExeMain" function name.
• Probably because UnDecorateSymbolNameW function was not found.
• Because dbghelp.dll was not loaded.
• Because you tried to load x64 version of that DLL into x86 process in file UnmanagedSymPrv.cpp, on line 70.
• This failed and you tried to load dbghelp.dll from current directory.
• But this failed because some dependency was not satisfied.
• dbghelp.dll depends on _o_memset function from api-ms-win-crt-private-l1-1-0.dll library.
• But that export is not found in that DLL.

So, I think you brought in modern dbghelp.dll (version 10) but not all its dependencies.

I think you should load x86 DLL into x86 process from Windows SDK first. If it fails you should use system version of dbghelp.dll (version 6.1 on Windows 7) and not distribute your own, I don't think it is worth the hassle. If you want to distribute your own version, test if it works correctly first please.

Also, I think you should not dereference NULL object in demangle.cpp file on line 228.

Best Regards, Marek

dependencies.exe my_exe.exe

prints nothing at all (but I think that might be intentional). I can run dependencies.exe my_exe.exe -knowndll to see all the known DLLs and dependencies.exe my_exe.exe -imports to see all listed imports, and manually crossreference them, but there has to be a way to just get the missing ones.

Running dependencies.exe my_exe.exe -modules and dependencies.exe my_exe.exe -chain throw

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 294
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.PeDependencyItem.ResolveDependencies() in C:\projects\dependencies\Dependencies\Program.cs:line 309
   at Dependencies.Program.DumpModules(PE Pe, Action`1 Printer) in C:\projects\dependencies\Dependencies\Program.cs:line 503
   at Dependencies.Program.Main(String[] args) in C:\projects\dependencies\Dependencies\Program.cs:line 591

But this isn't about that, so please let me know what the way to list the missing DLLs, if possible.

I have been attempting to run Dependencies on a Windows image-based Docker container, and I get the following error:

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'ClrPhlib.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

I'd already added the Visual C++ redistributable to my container, which is the solution provided in https://github.com/lucasg/Dependencies/issues/24. The missing assembly is in the same folder as Dependencies.exe

Here's my Dockerfile:

FROM mcr.microsoft.com/dotnet/framework/runtime:4.8
ARG source

ADD https://download.visualstudio.microsoft.com/download/pr/9e04d214-5a9d-4515-9960-3d71398d98c3/1e1e62ab57bbb4bf5199e8ce88f040be/vc_redist.x64.exe /vc_redist.x64.exe
RUN powershell.exe -Command "C:/vc_redist.x64.exe" -ArgumentList '/install', '/passive', '/norestart' -NoNewWindow -Wait

ADD https://github.com/lucasg/Dependencies/releases/download/v1.9/Dependencies_x64_Debug.zip /dependencies.zip
RUN powershell.exe -NoP -NonI -Command "Expand-Archive 'C:\\dependencies.zip' 'C:\\Dependencies'" 

WORKDIR /app
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["C:\\app\\ConsoleApp1.exe"]

As you can see, it's nice and simple (it's a test app that I'm using to try to work out why an asp.net app can't find a C++ DLL, ironically enough).

I'm building the Docker image on the command line:

docker build . --no-cache -t consoleapp1:testing

and entering it using:

docker run -it --entrypoint="cmd.exe"

Any idea what I've done wrong here? I've also tried it with the 4.7.2 version of the dotnet framework image.

This is because Dependencies resolves vcruntime140.dll in its own directory. Please link with static runtime or avoid resolving Dlls in the directory of Dependencies(Gui).exe.

When clicking on the executable in the treeview DependenciesGui crashes with the stack trace shown below

It's a 100% repeatable event for me, so hopefully would be easy to identify. I suspect it should just not do anything if this is selected.

This is on a Windows 11 x64 22H2 install with v1.11.1.0 release of Dependencies

Currently, this project uses .NET Framework 4.6.1 which has been unsupported as of earlier this year. While the easiest fix would be to simply target .NET Framework 4.6.2 (or a newer version of .NET Framework), it may make sense to use this opportunity to migrate to the modern .NET. The current version, .NET 6, is a Long Term Support (LTS) version, making it a good candidate for a significant upgrade. And while it would definitely require more testing and validation, there are numerous advantages:

• .NET 6 is much faster than .NET Framework. This blog post lists some of the performance improvements in .NET 6 over previous versions of .NET Core (that already had improvements over Framework). You will also have new ways of publishing the application including using AOT compilation and bundling the framework with the app, so users don't need to install a runtime.
• Migrating sets up Dependencies for success with modern technologies and platforms including native Windows Arm64 support.
• All currently supported Windows versions (including Windows 7 SP1 ESU) are supported by .NET 6, so you won't be removing OS support for many potential users.

Here are some dependencies I've identified with their current status:

• Dragablz: It appears that the repo contains a .NET Framework 4.5 version of this component as a build dependency. I'm not sure what the reason is behind this but if the component is unmodified from the original, this may no longer be necessary. Dragablz is available as a NuGet package that supports .NET 6. A simple drop-in replacement seems to work at first glance for me.
• Mono.Cecil: This NuGet package is also supported on .NET 6.
• NDesk.Options: This package appears to be deprecated but there's NDesk.Options.Core which supports .NET 6 and the app builds just fine using it (no extensive testing done).
• Newtonsoft.Json: Supported on .NET 6.

Based on a preliminary attempt to port, this shouldn't be too hard. In fact, I've got a basic proof of concept working.

@lucasg If you approve of this change, I can formalize the work and create a PR, though I'll need help with testing and validation.

Opening a context menu in a view e. g. with the right mouse button, and then leaving it by pressing the ESC key, the application will be terminated by the next press of the ESC key. All views besides the files view (top,left) are concerned. It seems to be a crash, because it takes a little bit longer (hourglass) and the list of recent files didn't get updated.

In the view menu and the context menu of the import and export view F10 should toggle "Undecorate C++ Functions". But it doesn't. It just activates the menu bar.

Releases 1.11 and 1.11.1 don't include peview.exe. Specifically:

1.11\Dependencies_x64_Debug.zip 1.11\Dependencies_x64_Release.zip 1.11\Dependencies_x86_Debug.zip 1.11\Dependencies_x86_Release.zip

1.11.1\Dependencies_x64_Debug.zip 1.11.1\Dependencies_x64_Release.zip 1.11.1\Dependencies_x86_Debug.zip 1.11.1\Dependencies_x86_Release.zip