The Case of the IMNControlObj Element Not Found Error on SharePoint 2007 in IE9

In testing IE9 for production deployment I came across an issue where some SharePoint menus with ‘mouseOver’ events were not firing. One of the most interesting things about this error in my case:

• Does not occur on all machines
• On machines it does occur
  • Does not occur in No-Add Ons mode (iexplorer.exe –extoff)
  • If you manually disable all add-ons the problem still occurs if you launch IE normally
  • Does not occur in 64-bit IE
  • Not affected by compatibility view settings
  • Did not occur in IE8

There was no error message, as the default setting in IE9 seems to be not to display script errors.  So the first thing I did was enable script debugging –> This is available by clicking in top right corner of IE window, then selecting Internet Options. In Internet Options select the advanced tab and clear Disable script debugging (Internet Explorer)

This gave me the following error when viewing the page:

Copying the details from the error we get the following information:

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2;

.NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.3; MS-RTC LM 8;

.NET4.0C; .NET4.0E; Zune 4.7)
Timestamp: Tue, 22 Mar 2011 00:40:47 UTC

Message: Element not found.

Line: 1945
Char: 4
Code: 0
URI: http://infoworld/_layouts/1033/init.js?rev=qX%2BG3yl4pldKy9KbPLXf9w%3D%3D

 

Now the developer toolbar in IE9 is pretty awesome (actually it is insanely brilliant –> awesome set of tools here) and clicking ‘Yes’ to the error brought it up:

 

Doing a search on IMNControlObj we find it instantiates an ActiveX control:

 

 

Looking up Name.NameCtrl.1 ActiveX control (ref: http://msdn.microsoft.com/en-us/library/ms455335.aspx) we find it is contained in NAME.dll at %ProgramFiles%\Microsoft Office\Office14\ directory on the client computer during Microsoft Office Setup. It is described by Microsoft as an ActiveX control that enables a webpage to display presence information for people, and lets the user take various actions with respect to those people through an on-object user interface (UI) in Microsoft SharePoint Foundation.

I found this registration in the Registry by searching for Name.NameCtrl.1 under HKCR, then searching for the GUID I found there.

I found it pointed to D: partition, although my main office installation is on C:. However I had installed SharePoint Designer 2007 to this location…

Using ProcMon found that Internet Explorer seemed to be trying to access both versions of name.dll:

 

So I set ProcMon filter to include anything where detail contained D:\Program Files (x86)\Microsoft Office\Office12\Name.dll

This let me find out what reg keys where pointing to the D: version

So I changed all results found here to reference the C: Office 2010 version of name.dll, but the DLL from D: was still getting loaded. This time I cleared my ProcMon filter while I had selected the reference to a D:\ name.dll. I then moved backwards through the ProcMon log and found the reason – some references used the old school file name convention:

Changed this final reference back to the Office 2010 version of name.dll and presto problem solved. No more script errors.

So –extoff worked because ActiveX controls aren’t loaded in this mode. 64-bit worked because 64-bit IE can’t load the 32-bit ActiveX control. More interesting – can anyone explain why this issue didn’t ever occur on IE8 for me. I am guessing the old name.dll has IE9 compatibility issue, so it while it worked fine in IE8 on IE9 upgrade it wasn’t happy. That’s just a guess though.