.NET Tips and Tricks

Blog archive

Debug Load Errors with the Assembly Binding Log Viewer

One of the most frustrating error messages that you can get when debugging your application is "File not found" when loading an assembly (or just instantiating a new class). This message means that, for some reason, .NET couldn't find the DLL with the class you needed. If the reason for the problem isn't obvious from the information provided (and it usually isn't) there is a tool that will give you some more insight: the Assembly Binding Log Viewer (fuslogvw.exe).

As its name implies, the fuslogvw gives you access to a log file of binding activities. That logging is turned off by default so you must first enable it. The easiest way to do that is to run fuslogvw, click on the Settings button and select the level of logging you want before closing the viewer. You're probably only interested in those cases where loading an assembly is failing so, to have just those errors logged, select the "Log bind failures to disk" option.

You can then run your program and click on fuslogvw's refresh button to review the log entries. The viewer shows the information in three columns: Application, Description, and Date/Time. The description won't tell you much more than you got from running your application but if you double click on the log entry you'll get a ton more data to help you figure out what went wrong.

You'll see, for instance, all the paths that .NET looked through trying to find the assembly. You'll also see whether the loading process was affected by entries in your application's configuration file or whether all the parameters were set from the machine configuration file. The log viewer may not hand you the answer to your load failure but it will probably tell you something about what's going wrong that you didn't know before.

You may not be able to start fuslogvw from the Visual Studio command prompt -- the file moves around. On one of my computers, picked at random, I found it in C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin folder... but your mileage may vary. Wherever it is, however, the utility will wait patiently until you need it.

Posted by Peter Vogel on 07/05/2011 at 12:20 PM

comments powered by Disqus


  • Windows Forms Lives On in .NET 6

    Windows Forms would like you to know that the reports of its death are greatly exaggerated.

  • Uno Platform 4.0 Adds Visual Studio Code Plugin

    Uno Platform 4.0 is out, highlighted by a new extension for working in Microsoft's Visual Studio Code editor.

  • .NET 6 Support Leads New GA Features in Azure Functions Fall Update

    Microsoft announced several new features that are now generally available in the fall update of Azure Functions, used for event-driven serverless computing in the cloud.

  • Teams Toolkit 3.0 Boosts Multiple Developer Collaboration

    Microsoft's Teams Toolkit 3.0 has debuted with several new features, including better multiple developer collaboration and improved multi-environment management.

Upcoming Events