Introduction

FUSLOGVW.EXE, the .NET Assembly Binding Log Viewer, is a powerful tool for troubleshooting assembly binding failures. While it is typically associated with Visual Studio, it can be used independently on any Windows machine where the .NET SDK is installed. This article explains how to locate, set up, and use FUSLOGVW.EXE without Visual Studio, along with practical tips for interpreting the logs it produces.

Understanding Assembly Binding

Before exploring the tool, it helps to understand what assembly binding is. In .NET, assembly binding is the process by which the Common Language Runtime (CLR) locates and loads assemblies at runtime. When the CLR cannot find or load an assembly, it throws a FileNotFoundException or FileLoadException. These errors can be difficult to diagnose because the CLR searches multiple locations (application directory, Global Assembly Cache, probing paths) and the failure reason is not always obvious from the exception message alone.

Common causes of binding failures include:

• Version mismatch: The application expects version 2.0.0.0 of an assembly, but only 1.0.0.0 is available.
• Missing dependency: A required DLL is not present in the expected directory or GAC.
• Strong name mismatch: The assembly's public key token does not match what the application was compiled against.
• Platform mismatch: A 32-bit application tries to load a 64-bit assembly or vice versa.

Locating FUSLOGVW.EXE Without Visual Studio

FUSLOGVW.EXE is included in the Windows SDK, not Visual Studio itself. You can get it by installing the .NET SDK from Microsoft's official download page.

Common File Paths

After installing the SDK, look for the executable in these locations:

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\

The exact path depends on which SDK version you installed. If you cannot find it, search for fuslogvw.exe across your Program Files directories.

Running the Tool

FUSLOGVW.EXE requires administrator privileges to modify registry settings for logging. Open a Command Prompt or PowerShell as Administrator, navigate to the directory, and run:

fuslogvw.exe

Configuring the Viewer

Once the tool opens, you need to configure it before it captures any logs.

Step 1: Enable Logging

Click Settings in the toolbar. You will see these options:

For troubleshooting, start with "Log bind failures to disk." Switch to "Log all binds to disk" only if you need to verify that a specific assembly is being loaded from the correct location.

Step 2: Set the Log Location

By default, logs are stored under C:\Users\<Username>\AppData\Local\Fuslog\. You can change this to a custom directory if needed.

Step 3: Reproduce the Error

After enabling logging, run the application that is experiencing the binding failure. Then return to FUSLOGVW.EXE and click Refresh to see the new log entries.

Interpreting Logs

Each log entry provides detailed information about the binding process:

• Assembly Name and Version: Which assembly the CLR tried to load.
• Calling Assembly: Which assembly requested the load.
• Binding Result: Whether the binding succeeded, failed, or was redirected.
• Probing Paths: Every directory the CLR searched before giving up.
• Error Details: The specific reason for failure (version mismatch, file not found, etc.).

Example: Diagnosing a Version Mismatch

A typical log entry for a version mismatch looks like:

1Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
2LOG: Binding succeeds. Returns assembly from C:\MyApp\bin\Newtonsoft.Json.dll.
3WRN: Comparing the assembly name resulted in the mismatch: Major Version
4ERR: The located assembly's manifest definition does not match the assembly reference.

This tells you that the CLR found the assembly but its version did not match what was expected. The fix is either to update the assembly to the expected version or add a binding redirect in your application's config file:

1<configuration>
2  <runtime>
3    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
4      <dependentAssembly>
5        <assemblyIdentity name="Newtonsoft.Json"
6                          publicKeyToken="30ad4fe6b2a6aeed"
7                          culture="neutral" />
8        <bindingRedirect oldVersion="0.0.0.0-13.0.0.0"
9                         newVersion="13.0.0.0" />
10      </dependentAssembly>
11    </assemblyBinding>
12  </runtime>
13</configuration>

Alternative: Registry-Based Logging

If you prefer not to use the GUI, you can enable fusion logging via the registry:

reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v ForceLog /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v LogPath /t REG_SZ /d "C:\FusionLogs\" /f

To disable logging afterward:

reg delete "HKLM\SOFTWARE\Microsoft\Fusion" /v ForceLog /f
reg delete "HKLM\SOFTWARE\Microsoft\Fusion" /v LogPath /f

Always disable logging when you are done, as fusion logging generates a large volume of files and can impact application startup performance.

Common Pitfalls

• Forgetting to run as Administrator: Without admin rights, the tool cannot enable logging and will silently fail to capture events.
• Leaving logging enabled in production: Fusion logging writes files for every assembly load, which can fill disk space and slow down application startup.
• Not refreshing after reproduction: The log viewer does not auto-update. You must click Refresh after reproducing the error.
• 32-bit vs 64-bit tool: If your application is 32-bit, use the 32-bit version of FUSLOGVW.EXE from the non-x64 tools directory. The 64-bit version may not capture bindings from a 32-bit process.

Summary

FUSLOGVW.EXE is available without Visual Studio as part of the Windows SDK. To use it: install the .NET SDK, locate the executable, run it as Administrator, enable logging in Settings, reproduce your binding failure, and examine the log entries. The tool reveals exactly which assemblies failed to load and why, making it invaluable for diagnosing version mismatches, missing dependencies, and strong name conflicts in .NET applications.