In my previous post, I give one sample on how to use Powershell to filter and categorize information from thousands of IIS7 FREB log files.
Here is another sample to quickly find out useful information from .NET fusion log with PowerShell. Here we go:
Customer’s web application reported this “Exception has been thrown by the target of an invocation” error message when the application is loading at the first time:
Exception has been thrown by the target of an invocation. (C:\inetpub\wwwroot\wss\VirtualDirectories\somesitename\web.config line 100)
Look at the web.config file, the line indicates it is an “Add Provider” child element under Sitemap section, such as:
<siteMap defaultProvider="CurrentNavSiteMapProvider" enabled="true">
<add name="CustomizedProvider" type="My application.portal.namespace, Myapplication.Portal, Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bc3234211e9429c" />
The issue doesn’t happen to other Dev machines. We double confirmed that the provider assembly has been registered in GAC correctly and the configuration is no problem.
This means the problem happened during .NET fusion (Fusion means .NET Framework sub-system is locating and loading assemblies). We enabled Fusion log to find out what happens when the .net 2.0 web application starts running:
c. Create the C:\temp folder.
While reproducing the same error, there are many fusion logs generated in c:\temp.
In fusion log, it has one line in content to indicate error or not, for example:
Bind result: hr = 0x0. The operation completed successfully.
Bind result: hr = 0x80070002. The system cannot find the file specified.
But we cannot see this information from file title directly:
In this situation, I run this command in PowerShell:
select-string "Bind result: hr = 0x8" *.HTM |format-table filename -groupby line
The command can help us to filter out all failed Fusion log files grouping by different Bing error code.
By comparing the scenario on good machine, we quickly identified that missing System.XML.Linq is the root cause.
After applying .NET 3.5 SP1 (which contains System.XML.Linq), problem was resolved.