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 image 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


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

About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in Internet Explorer, SharePoint and tagged . Bookmark the permalink.

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

  1. Felix says:

    It happens on the IE8 also -many thanks a very informative post. Exactly the issue I have (with IE8). Presumingly it only happens if SP-Designer is installed *after* Office10.

  2. Ahmar says:

    Very good effort that save me countless hours

  3. PFDRINSTR says:

    What is the fix?

  4. Don says:

    very helpful indeed!

  5. Jeffrey says:

    I got the exactly same issue, registry was set to Office12, too. Without your experience sharing, I guess I have to spend hours finding the root cause. Thank You!!!

  6. Rich says:

    Awesome debugging skills! I’m so impressed by your process. You should write a series on what tools you use for what types of problems. You’ve got mad skills!

  7. Rich says:

    BTW, I am using IE8 on a Windows 7 Enterprise SP1 laptop and I am having this error whereas you weren’t. I’m not able to drill into it using the tools you have because I don’t have admin rights on my box. I was able to search the registry and in my case I have 2 references to the same dll:
    C:\Program Files (x86)\Microsoft Office\Office14\NAME.DLL in HKCR
    C:\Program Files (x86)\Microsoft Office\Office14\NAME.DLL in HKLM

    The mystery deepens!

    • Rich says:

      Come to think of it I am on Office 2007. This must have come in when they either installed Visio 2010 or SharePoint Designer 2010. Word, Excel, etc are all 2007 products but there is no reference in the hive to Office 2007.

    • If you don’t have local admin there are some tools you can use (if you are not prevented from launching 3rd party EXE by AppLocker or AppSense &c): – but first install on a machine you have admin, then copy the C:\program files (x86)\Fiddler2 into any folder on your target machine. (This is to capture web traffic) To capture registry calls &c you will have to resort to Rohitab’s API monitor download the “portable version” Note this tool can be a bit fiddly/complex to use, and can make apps crash, although I have several blog entries on using it. For searching registry As for the reg value being in HKLM + HKCR this is normal, HKCR is just a merging of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes

      • Rich says:

        In my environment I am prevented from installing anything…even a browser or a they would come with guns drawn if I tried to use that stuff here…lol. Good stuff to try at home though!

  8. Ricantun says:

    Excellent!! My problem was that I installed Office 2010 and some Office 2007 applications due to company restrictions…. the registry was pointing to Office12/NAME.DLL in your last registry screenshot, I changed it to Office14/NAME.DLL and every works fine now!! thanks a lot.

  9. Robert says:

    Thanks. Nice bit of troubleshooting.
    Another alternative that worked for me was to simply go into the IE “Manage add-ons” menu and disable “NameCtl Class” found in the “Toolbars and Extensions” section. For me that was a much simpler solution since I never need that ActiveX control. Yet, I wouldn’t have thought to do that without your post here. :)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s