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

Article translations Article translations
Article ID: 313892 - View products that this article applies to.
This article was previously published under Q313892
Expand all | Collapse all

On This Page

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.

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

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).

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 manager

Microsoft.IE.Manager: Microsoft.IE.Manager: unique id lgth = 28
Microsoft.IE.SecureFactory: Create SecureFactory() with security 
information
Microsoft.IE.Manager: Created secure factory
Microsoft.IE.SecureFactory: Creating instance of the object in the correct 
domain
Microsoft.IE.SecureFactory: pUrl = http://servername/DebugIEHost/DebugIEHost/test.htm
Microsoft.IE.SecureFactory: id = 86474707A316B616E65610000000
Microsoft.IE.SecureFactory: link = 
Microsoft.IE.SecureFactory: licenses = 
Microsoft.IE.Manager: Url = 
http://servername/DebugIEHost/DebugIEHost/test.htm
Microsoft.IE.Manager: UrlGetPartW returned 0
Microsoft.IE.Manager: CodeBase = http://servername
Microsoft.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"/>
					

REFERENCES

For more information about debugging with the .NET Framework SDK, visit the following MSDN Web site:
Debugging with the Microsoft .NET Framework SDK

Properties

Article ID: 313892 - Last Review: January 24, 2004 - Revision: 5.1
APPLIES TO
  • Microsoft .NET Framework 1.1
  • Microsoft .NET Framework 1.0
  • Microsoft Internet Explorer 5.5
  • Microsoft Internet Explorer (Programming) 6.0
Keywords: 
kbhowtomaster kbmisctools kbdebug kbctrl KB313892

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com