Can anyone recommend a tool to...

[Richard Andrew x64]

A tool for diagnosing which DLL is unable to be loaded by a subject DLL? I've used DUMPBIN to list the static dependencies of the DLL and they are very few and all of them are in the same directory as the subject DLL. This isn't my DLL so I have no idea what it's doing in its DllLoad routine. But the Windows loader is just a black box. It gives no insight into what's going on during the DLL load. This is a .NET 8 project that is calling functions in the subject DLL through pinvoke, so maybe the .NET loader knows something. Anyone know how to debug this?

The difficult we do right away... ...the impossible takes slightly longer.

[Lost User]

First thought is to start removing dll's and see if the messages change / appear. Look at build dates.

"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I

[Richard Andrew x64]

Thanks Gerry, I finally figured it out!

The difficult we do right away... ...the impossible takes slightly longer.

[Member_16377535]

To diagnose which DLL is unable to be loaded by a subject DLL, especially in a .NET context, you can utilize several tools and methods:

Dependency Walker

• **Tool**: Dependency Walker (depends.exe)
• **Usage**: This tool analyzes the dependencies of a DLL and can help you see which DLLs are missing or failing to load. It provides a detailed tree view of all dependencies, showing the status of each one.
• **Steps**:
  1. Download Dependency Walker from [dependencywalker.com](http://www.dependencywalker.com/).
  2. Open your subject DLL with Dependency Walker.
  3. Check for any missing or red-colored entries in the tree.

Process Monitor (ProcMon)

• **Tool**: Process Monitor (part of Sysinternals Suite)
• **Usage**: ProcMon allows you to capture real-time file system, registry, and process/thread activity. This can help you see which DLLs are being accessed and which ones are failing to load.
• **Steps**:
  1. Download and run Process Monitor from [Microsoft Sysinternals](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon).
  2. Set a filter for your application (use the process name).
  3. Look for "NAME NOT FOUND" or "DLL NOT FOUND" events, which indicate that a specific DLL could not be loaded.

3. **Fusion Log Viewer**

• **Tool**: Fusion Log Viewer (Fuslogvw.exe)
• **Usage**: This tool logs assembly binding failures, which can be particularly useful for .NET applications to determine why a specific assembly (DLL) failed to load.
• **Steps**:
  1. Open the Developer Command Prompt for Visual Studio.
  2. Run `fuslogvw.exe`.
  3. Enable logging and reproduce the issue.
  4. Check the logs for any binding errors or issues related to your subject DLL.

4. **.NET Assembly Binding Logging**

If the subject DLL is a .NET assembly, you can enable assembly binding logging in the registry:

• **Steps**:
  1. Open `regedit`.
  2. Navigate to `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion`.
  3. Create a new DWORD value named `ForceLog` and set it to `1`.
  4. Create a new DWORD value named `LogPath` and set it to a directory where you want the logs saved.
  5. Reproduce the issue, and check the logs in the specified directory.

5. **Debugging with Visual Studio**

• If you have the source code for the .NET application, you can attach the debugger to your application and set breakpoints around the P/Invoke calls.
• Check for exceptions thrown during the load process. The exception messages can often provide insight into what went wrong.

*Using LoadLibraryE