Recently I had been to couple of places on behalf of Microsoft DPE (Developer & Platform Evangelism) group as part of their new initiative Innovation Day to talk about The developer's toolkit for .NET. It was an exciting experience and it was little surprising to know how much this territory is unexplored. So I decided to put the details (with few extensions) on this blog as well in order to broaden the audiences. I will write a series of blog posts covering the important tools/utilities from the .NET toolset.
Here we are going to talk about the Tools/infrastructure provided by the .NET framework itself to enable the developers to troubleshoot the issue in their .NET applications. I would like to Stress out the fact here that all these utilities are provided by the .NET framework itself. In my experience these tools are sufficient enough to root out most of the issues in the .NET applications.
Tools we are going to discuss:
4. ILAsm, ILDAsm
To make it more interesting and focused, I will give sample scenarios and we will see how we can use these utilities to troubleshoot those scenarios.
Scenario: “Our application ran successfully on the Development machine but it is failing with FileNotFoundException when we deploy it in production”
This scenario gets much more complex in real life because of the indirect and third party dependencies.
.NET tools/Utilities we will use: Assembly Binding Log Viewer.
How to troubleshoot:
1. .NET uses algorithm named Fusion to locate .NET assemblies. Hence in order to troubleshoot the loader issues we need to enable fusion logging.
i. Open Registry Editor, and go to ‘HKEY_LOCAL_MACHINE\Software\Microsoft\Fusion’
ii. Create a ‘string’ value named ‘LogPath’ and give name of existing directory where you want the logs to be generated.
iii. Create a ‘DWord’ value named ‘ForceLog’ and set it to ‘1’.
2. Run the faulting application and let it crash with the ‘FileNotFoundException’.
3. Go to the location you specified in ‘LogPath’ above, and open the ‘default’ directory. This directory will have an .htm file created for each ‘binding’ attempt. One of them will be for the failure.
4. Open the log file and it will enlist all the places the loader probed for the particular assembly and at the end it will tell you that it couldn’t locate the assembly. The following sample log entry shows detailed information about a failed assembly bind:
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\WINDOWS.0\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Dependency, Version=126.96.36.199, Culture=neutral, PublicKeyToken=12a0ae92d0a8861a
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///E:/Innovation Day/Scenarios/FileNotFound/ConsoleApplication1/bin/Release/Dependency.DLL.
LOG: Attempting download of new URL file:///E:/Innovation Day/Scenarios/FileNotFound/ConsoleApplication1/bin/Release/Dependency/Dependency.DLL.
LOG: Attempting download of new URL file:///E:/Innovation Day/Scenarios/FileNotFound/ConsoleApplication1/bin/Release/Dependency.EXE.
LOG: Attempting download of new URL file:///E:/Innovation Day/Scenarios/FileNotFound/ConsoleApplication1/bin/Release/Dependency/Dependency.EXE.
LOG: All probing URLs attempted and failed.
Alternatively one can use fuslogvw.exe which gets installed with .NET framework SDK. This small application provides the UI to do all these settings.
In the next post we will talk about .NET application load time performance and how we can improve it using .NET Native Image Generator i.e. NGEN.
- Chandrashekhar Chaudhari
Microsoft Developer Support VC++ and C#