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

This article was previously published under Q313892
This article has been archived. It is offered "as is" and will no longer be updated.
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry


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:
260840 SAMPLE: MIMEfilt Demonstrates MIME Filter for Internet Explorer
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:
  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:
Creating security managerMicrosoft.IE.Manager: Microsoft.IE.Manager: unique id lgth = 28Microsoft.IE.SecureFactory: Create SecureFactory() with security informationMicrosoft.IE.Manager: Created secure factoryMicrosoft.IE.SecureFactory: Creating instance of the object in the correct domainMicrosoft.IE.SecureFactory: pUrl = http://servername/DebugIEHost/DebugIEHost/test.htmMicrosoft.IE.SecureFactory: id = 86474707A316B616E65610000000Microsoft.IE.SecureFactory: link = Microsoft.IE.SecureFactory: licenses = Microsoft.IE.Manager: Url = http://servername/DebugIEHost/DebugIEHost/test.htmMicrosoft.IE.Manager: UrlGetPartW returned 0Microsoft.IE.Manager: CodeBase = http://servernameMicrosoft.IE.Manager: Application = DebugIEHost/DebugIEHost					
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:
Microsoft.IE.SecureFactory: System.Reflection.TargetInvocationException:Exception has been thrown by the target of an invocation.---->System.Security.SecurityException: Request for the permission of type System.Security.Permissions.FileIOPermission, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.   at System.Security.CodeAccessSecurityEngine.CheckHelper(PermissionSet grantedSet, PermissionSet deniedSet, CodeAccessPermission demand, PermissionToken permToken)   ...					
For security exceptions, you also receive details about which security permission request failed:
The state of the failed permission was: <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"             version="1"             Read="C:\temp.tmp"             Write="C:\temp.tmp"/>					
back to the top
For more information about debugging with the .NET Framework SDK, visit the following MSDN Web site: back to the top

Article ID: 313892 - Last Review: 12/07/2015 08:17:34 - Revision: 5.1

Microsoft .NET Framework 1.1, Microsoft .NET Framework 1.0, Microsoft Internet Explorer 5.5, Microsoft Internet Explorer (Programming) 6.0

  • kbnosurvey kbarchive kbhowtomaster kbmisctools kbdebug kbctrl KB313892