Fusion binding log and fuslogvw.exe


Suzanne blogs again! This time, she is helping you on diagnose MissingMethodException.


Of course, whatever she tries to help you, she can’t live without fusion log.


So what exactly is fusion log?


Remember what fusion’s role is in assembly binding? Fusion is responsible for finding the actual bits, and handing it over to loader. Because the fusion probing rule is vastly different from normal LoadLibrary rule, fusion includes some logging information to help diagnostic assembly binding failures. For every major event, fusion will log a message. Those events include app.config lookup, policy resolution, GAC lookup, every location fusion probes, and more.


By default, the log is kept in memory, and is included in FileNotFoundException (If you read FileNotFoundException’s document, you will find it has a member called “FusionLog“, surprise!). If you ask, fusion will dump the log into an HTML file, and later can be viewed using fuslogvw.exe, assembly binding log viewer shipped as an SDK tool.


As we shipped in 1.0 and 1.1, there are three things affecting how fusion dumps the log. They are all reg keys under HKLM\Software\Microsoft\Fusion.


1. REG_DWORD  LogFailures:
 If LogFailures is set to 1, fusion will dump the log to disk if the assembly binding did not succeed.


2. REG_DWORD ForceLog:
If ForceLog is set to 1, fusion will dump all logs to disk, regardless the assembly binding succeeded or not.


3. REG_SZ LogPath:
By default fusion dumps the logs to your IE cache. But if LogPath is set, fusion will dump the logs to the path specified. The LogPath has to be an existing folder to make it effective.


Fuslogvw.exe is covered by MSDN. I don’t want to copy the document here. But I’ll point out some common pitfall when people use this tool.
1. Fuslogvw reads the log settings once, and never reads the settings again. So if you changed the settings (especially LogPath), you have to close it, and re-run it to pick up the change.
2. There are three radio buttons in fuslogvw.exe. Default coresponds to IE cache. ASP.NET is useless. Custom means the LogPath. If you set LogPath, you have to click the custom button to see the actual logs. If you did not set LogPath, you have to click the default button to see the logs.
3. If you want to see logs for services running under a different credential than yours, you have to set LogPath, run the services, then run fuslogvw.exe, and select the custom button to see their logs. The reason is by default the logs are stored in their IE cache which you can’t see. You have to set the LogPath so everyone will log to the same place.


Fuslogvw.exe gets a little bit improvement in the next version of .Net framework. But then I am not a UI guy. I only spent half a day reading Charles Petzold’s “Programming Windows” before I set improve fuslogvw.exe. When you get change, play around with the new fuslogvw.exe, and send me feedback if possible.

Comments (12)

  1. I have to admit that I was pretty ignorant of fuslogvw.exe until I read your and Suzanne’s posts because I happened to have that problem using NUnit as my debug process. I do have one question that hopefully you can answer that I don’t see documented anyplace. I normally develop and run my applications in non-administrator mode. When I run fuslogvw.exe, the "Log Failures" checkbox is disabled and nothing gets logged. I have to switch and run everything under the Administrator account to get a failure log. Is there any way around this? Am I missing a security setting?

  2. The reason "Log Failures" is disabled, is because you don’t have Admin privilege. The check out merely writes the reg key [HKLMSoftwareMicrosoftFusionLogFailures].

    Only the reg keys require Admin privilege. Once they are set, you can use fuslogvw.exe as a normal user to see the failure logs.

  3. Bob H says:

    I don’t want to sound picky, but I was double-clicking the largest column (Description) in Fusion Log and nothing was happening. It might be nice to set FullRowSelect = true in the ListView. Great tool, though.

  4. You are not picky:)

    Fuslogvw.exe is indeed a very primitive GUI application. I am really a platform kind of guy. Writing good GUI application is really a barrier for me(and other team members). So we have very minimum UI on this tool.

    It does exact the minimum — setting binding flags and viewing the binding log. Nothing more.

  5. Naren's Blog says:

    Overview : If you have used links in work item tracking, you might have wondered if you could add your