HOW TO: Use the IEHost Log to Debug .NET Object Hosting in Internet Explorer (313892)

SUMMARY

This article describes how to activate extended error logging for IEHost.dll, the managed Common Language Run-time (CLR) host that runs inside Internet Explorer.

The Microsoft .NET Framework SDK documentation describes how to use Fuslogvw.exe to debug problems that may occur when you host a .NET module in Internet Explorer. "Fusion," from which this utility takes its name, is Microsoft's new zero-impact program-installation technology. Therefore, Fuslogvw.exe reports errors only in downloading the assembly or its dependencies.

back to the top

About IEHost.dll

.NET modules are supported in Internet Explorer by using two components. The first is a MIME filter, which is defined in Mscoree.dll, that monitors all incoming data streams with the application/octet-stream MIME type when Internet Explorer makes a call to the IMoniker BindToObject method. The filter examines the data stream for the bits in the Portable Executable (PE) header to determine whether or not it is a managed module. If it is not, the filter simply returns, and allows Internet Explorer to process the stream typically.

If the stream is a .NET module, the filter loads the IEHost managed assembly and calls into its factory object to create an instance of the requested object. This factory object, in turn, calls IEManager, a security manager that configures the Application Domains (AppDomains) for Internet Explorer and uses evidence about the assembly (particularly, the URL and zone membership) to determine the permissions with which the assembly should be loaded.

Errors in assembly loading, security permissions, or object initialization are not recorded in the Fusion log. As with ActiveX controls, a .NET object that is not initialized typically fails silently, leaving a small, grooved box where the control should be. To see such errors, you need to active the IEHost debug log.

For additional information about MIME filters, click the article number below to view the article in the Microsoft Knowledge Base: back to the top

Activating the IEHost Debug Log File

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and click the following registry key:

   HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework

3. Add a DWORD value named DebugIEHost to this key; assign it any non-zero value.
4. Add a string value named IEHostLogFile. Assign it the full path (including the file name) of the file in which you want to record the debug trace (for example, C:\Temp\IEDebug.log).

back to the top

Information Contained in the Debug Log File

The log file that is created by IEHost contains entries that are written by two different .NET classes: Microsoft.IE.Manager and Microsoft.IE.SecureFactory. For example: This information identifies the URL that is used for security purposes, the name of the application that is being started, the code base that is used for downloading dependencies, and the licenses that apply to this object (among other useful information).

The most useful information is a stack trace, which is recorded in the log file if an error occurs during object creation. For example, assume that you tried to write to a folder in your class constructor:

public DebugIEHost() {
    // This call is required by the Windows.Forms Form Designer.
    InitializeComponent();

    // TODO: Add any initialization after the InitForm call
    FileStream fs = File.Open(@"C:\temp.tmp",System.IO.FileMode.CreateNew);
    StreamWriter sw = new System.IO.StreamWriter(fs);
    sw.WriteLine("Hello, world");
}
				

This operation does not succeed, but because the object has not been fully sited in Internet Explorer yet, it fails silently. However, a verbose stack trace is written to your log file. You typically see two stack traces: an inner exception (which is thrown by your control), and a server exception (the error that is thrown by the run-time in response to your control's failure). For example: For security exceptions, you also receive details about which security permission request failed: back to the top