Home/ Questions/Q 9187179
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T19:42:20+00:00

I am working with a web application that uses a .NET Windows Forms user

  • 0

I am working with a web application that uses a .NET Windows Forms user control hosted in Internet Explorer via an “object” tag — e.g. <object id="myObj" height="100%" width="100%" classid="/MyVirtualDir/MyAssembly.dll#MyAssembly.MyControl" name="myObj">

The web application requires that it be added to the “Trusted Sites” zone and there is an installer to adjust CAS permissions. If we have problems, we also go through numerous checklists to make sure permissions are set correctly for the Trusted Sites zone (and Advanced Options) to allow the .NET control to download and run.

We have been able to get this working for thousands of clients using IE6, IE7, and IE8, and for over 95% of clients using IE9.

However, nearly every week we run into some client that has been upgraded to IE9 (either as a new PC, or an update to the existing PC) where the .NET Control displays as a white box with a Red X in the upper left corner.

We’ve done numerous things to try and troubleshoot this:

  • We’ve rechecked all of the “Trusted Sites” permissions to make sure they are set correctly.
  • We’ve verified that the Advanced Internet options all match machines that work.
  • We check for Internet Explorer add-ons, and generally disable all of them while troubleshooting (especially anti-virus add-ons which are known to prevent .NET controls from running)
  • We’ve checked the Temporary Internet Files on several of the clients; the referenced control DLL does not appear there
  • We then installed Fiddler2 to monitor the requests; Fiddler2 showed that IE9 was not making a request to load the control DLL

So it seems like IE9 is failing to process the “object” tag at all. This is the kind of behavior I would expect from a page loaded in the “Internet Zone”, but I can’t figure out why this is happening with the Trusted Zone settings.

I searched for other questions like this from other people — the most similar question I found was posted here (http://www.pcreview.co.uk/forums/embedded-usercontrol-sometimes-displays-red-x-internet-explor-t3608356.html) but it is from 2008 (pre IE9) and no one ever replied.

The strange thing about our problem is that the only solution we have found is to uninstall IE9 and revert back to IE8 — this has worked basically every time! So it does not seem like there could be a Group Policy setting or anything else on these clients that is preventing IE from even attempting to load the .NET control, since we can get it to work in IE8; it just doesn’t work in IE9.

Does anyone have any idea what could be going on here? Is there some extra setting in IE9 (or a Windows setting that only IE9 pays attention to) that would prevent it from running .NET Controls on a Trusted Site?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    After many forum posts and lots of guessing, I’ve found this registry key:
    HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility{00000000-0000-0000-000000000000}\

    Compatibility Flags = 0x400 (1024)

    From what I understand, this is the ActiveX “Killbits” flag, being applied to the Null GUID; and from what I can tell, IE9 looks for this key in relation to .NET Controls, and IE8 does not – hence why it works in IE 8 with all the same settings on the same machine.

    I had another post in the MSDN forums here if you want more details.

    • 0