Fusion Log Viewer [Fuslogvw] for Assembly Binding Issues

This is the best advice you can give to an engineer.

"Remember, the better you know about your tools and components the better engineer you are."

It is the best advice I can give to anyone. One of the habit of highly acclaimed writing of Stephen Covey "7 Habits of Highly Effective People", he also includes one of the habit as "Sharpen your Saw". We get so much involved with our day-to-day activities at work that we don't realize that our saw is being rusted. If we don't keep it sharpened than it wouldn't be of any use after some time. After sometime, we might also cry "Who stole my cheese?". Actually nobody did... It's us who kept eating our cheese, lived our life in the comfortable zone and now the cheese is finished. We should have been on new adventures of exploration of new avenues of cheese building. There is no benefit crying over spilled milk.

Have you ever got this message when you try to launch an application? Clearly, it can't find one of the libraries is missing which is required for the application to start up. It can't find ClassLibrary1. Well, It definitely is a weird name for your library but still can't find it. But why? Where is it trying to load this assembly from? Why does it even need this? What other libraries it is using. There are several other questions you want to ask but can't answer. In order to better get the root cause of the problem and better troubleshooting, there are several tools to help. One such tools is Fusion Log Viewer [Fuslogvw].

Fusion Log Viewer provides details about assembly binding in a .net application. It works as an .net app assembly binding monitor. It can shows details about every assembly loaded in a .net application.

Installing Fusion Log Viewer
Fusion Log Viewer is not a separate install. It is rather a .net framwework tool which is installed with Visual Studio and Widnows SDK.

Launching the Viewer:
There are various options to launch the tool. First of all, we can launch it using Visual Studio Command Prompt installed with Visual Studio. Doing that, you wouldn't have to navigate to the folder containing the tool. Just type the name of the viewer and hit enter. It should be loaded for you. You can find Visual Studio Command Prompt from Windows Start up menu.

As you see above, it is important that we run the tool as administrator. If you don't like to hold your mouse like most developers then you don't have to right click the shortcut and select "run as administrator". Just type the name of application in Start menu and select it using the navigation UP / DOWN keys like you always do. Now instead of right clicking just hit CTRL + SHIFT + ENTER instead of just ENTER. You should see the following view of Visual Studio Command prompt.

Otherwise, It would launch successfully but it wouldn't allow us to see the binding details. It greets the user with greyed out options and gives no freaking idea about the cause of this hurtful behavior.

Running as administrator, it enables the options as follows:

Using The Viewer
After launching the viewer, the tool's setting would determine what kind of log do you want to see for assembly binding. You have the following options:

1. Log Disabled: No logging for assembly binding.
2. Login exception text: Logs minimum binding information to the disk.
3. Log assembly binding failures: Generally used options. Logs in only those libraries which have binding issues.
4. Log all binds to disk: Even those assemblies which don't have any binding failures.

Let's select to log only those bindings which have failures. Now we run an application which have some library binding issues. This should be logged as follows:

The number of entries in the list for an application would depend upon the number of assemblies which can not be loaded. If we had selected the option to log all bindings then an entry would represent an assembly loaded in an application.

Where are these logs created?
By default, these logs are created in Temporary Internet folders. It is also the recommended way because you wouldn't have to worry about cleaning this up. Alternatively, we can change the location in Settings view as follows:

Example Log

LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\shujaat\Documents\Visual Studio 2010\Projects\WpfTestProjcect\WpfTestProjcect\bin\Debug\WpfTestProjcect.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Users/shujaat/Documents/Visual Studio 2010/Projects/WpfTestProjcect/WpfTestProjcect/bin/Debug/ClassLibrary1.DLL.
LOG: Attempting download of new URL file:///C:/Users/shujaat/Documents/Visual Studio 2010/Projects/WpfTestProjcect/WpfTestProjcect/bin/Debug/ClassLibrary1/ClassLibrary1.DLL.
LOG: Attempting download of new URL file:///C:/Users/shujaat/Documents/Visual Studio 2010/Projects/WpfTestProjcect/WpfTestProjcect/bin/Debug/ClassLibrary1.EXE.
LOG: Attempting download of new URL file:///C:/Users/shujaat/Documents/Visual Studio 2010/Projects/WpfTestProjcect/WpfTestProjcect/bin/Debug/ClassLibrary1/ClassLibrary1.EXE.
LOG: All probing URLs attempted and failed.

So the run-time probes for the assembly and you have the above details.

Note: It is not just fusion log viewer which can give you details about the assemblies being loaded as part of an application. There are also other tools. Let's look at them briefly.

Visual Studio Modules Debug Window
When you are developing an application and want to know the details about the loaded assembly. Just go to the Debug Windows menu and select "Modules". It gives the details of all the loaded assemblies. So if you can't find an assembly which you think should have been loaded already then you have an issue. We can also load symbols of these assemblies to take debugging to the next level.

If you don't see an assembly which you think should have been loaded then there is definitely a problem.

Process Explorer
This is another tool which can help you in this regard. It is a Sysinternals tool which can give details about various details about a running process. It includes the details about the assemblies being used by the process.

If you are running the Process Explorer with Admin Privileges then you could see the associated assemblies used with the process.

Process Explorer is an important tool in the developer toolbox. This can be downloaded from sysinternals [http://technet.microsoft.com/en-us/sysinternals/bb896653]

List DLLs
This is another sysinternals tool specialized for listing the dlls in a process. It is also needed to be launched as administrator. We can use "runas" for this purpose.

Obviously you need to have Secondary Logon Service running for this to work.

If you are already running something with credentials of other account than in that case Secondary Logon Service cannot be stopped. So don't get frustrated if you see the "Stop" option as disabled in Services.msc. Just close the other application and then the option would be available to stop the service.