Excel VBA "Automation Error" due to Jan 2016 Office Update, probably caused by MSCOMCTL.OCX (Microsoft Windows Common Controls 6.o (Service Pack 6))

Question

Solution

I have added a Treeview Active X Control to one of our spreadsheet, using Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e. MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\

KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition) (MS16-004), pushed out from Microsoft on 2016-01-15 (or thereabouts), installs a new version of MSCOMCTL.OCX (v6.1.98.46) which was "Created" on 2015-12-09, but "Accessed" (i.e. installed on the computer) at the time of the update.

This made the workbook "lose" reference to MSCOMCTL.OCX (quote marks on "lose", because the reference is still ticked but no longer works; the workbook doesn't compile because of "Compile error: Object library feature not supported" or "Automation error").

It seems that the update modifies the following registry key by adding a SubKey 2.0, but leaves it empty, and doesn't register the new MSCOMCTL.OCX:

HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\

Fixing the problem requires three steps:

1. MSCOMCTL.OCX needs to be unregistered and re-registered from an elevated command prompt, as follows:

   C:\Windows\system32>Regsvr32 /u C:\\Windows\SysWOW64\MSCOMCTL.OCX 
   C:\Windows\system32>Regsvr32 C:\\Windows\SysWOW64\MSCOMCTL.OCX
   

   When registering the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32, a new key is added to the Registry:

   KEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2
   

   If there was a SubKey named 2.1 already existing, it enters a reference that 2.2 is now the Key for use. But it doesn't do anything to the empty 2.0 SubKey !

   If there is a 2.0 (or 2.1 for that matter) SubKey with nothing in it, any object using that OCX should fail to create because it will use the 2.0 (resp 2.1) Version, it can't and didn't check for 2.2 Version.

2. Clean up the registry by deleting the wrong or superseded keys 2.0 and 2.1, leaving only the latest and working key 2.2. This can be done from the Registry Editor by selecting HKEY_CLASSES_ROOT, Edit/Find/MSCOMCTRL.OCX.

   (Note: this step seems optional as I have checked that doing only step 1 and 3 made the workbook work again. But it feels like the right thing to do)

3. In the in the Excel workbook VBA project, Microsoft Windows Common Controls 6.0 (Service Pack 6) needs to be unreferenced and re-referenced. Re-referencing is not just a matter of re-ticking the box, you need to use "Browse", and select MSCOMCTL.OCX in C:\Windows\SysWOW64\

   (Note, in the browser window, you need to change the file type from "dll" to "OCX" (or "all"))

Daniel Alexander Karr (refer post further below) has kindly shared a script he wrote to do steps 1 and 2 automatically (note that needs to be run as an Administrator).

Thanks Daniel and wmelonman for your help in understanding the problem and finding a solution.

Original Post

Similarly to what is described in this 3 year old post (VBA Automation Errors due to Office Service Pack 3.0 caused by Forms), a perfectly working workbook of mine stopped working from one day to the next...

In the list of updates carried out last night the following ones are Office Updates:

• KB3114563 (Definition Update for Microsoft Office 2010 32-Bit Edition)
• KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition)
• KB3114555 (Update for Microsoft Office 2010 32-Bit Edition)
• KB3114553 (Security Update for Microsoft Office 2010 32-Bit Edition)
• KB3114564 (Security Update for Microsoft Excel 2010 32-Bit Edition)

There were other updates, but general Microsoft Windows updates, not specific to Office, and they hopefully are not relevant here.

My understanding is that the "Automation error" is due to the project not compiling because of the presence of 2 "additional" ActiveX controls on one of my forms that I have referenced from Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e., MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\

Unfortunately un-registering and re-registering MSCOMCTL.OCX as explained in the aforementioned post didn't solve the problem.

I also tried deleting all *.exd, but there weren't any on my C: drive.

Additional info that may be relevant:

• The MSCOMCTL.OCX file version is 6.1.98.46, created & last modified 2015-12-09 but accessed at 3.33am yesterday (2016-01-15), i.e. about the same time the updates occurred (3:14am for the latest one).
• Once passed the initial "automation error" message, I would get an additional message, "Compile error: Object library feature not supported", highlighting lines of codes associated with the additional controls.
• I've verified these were "causing" the problem by creating a blank form an trying to add one on. I got the error message "Could not complete the operation due to error 800a0011".
• These additional controls are Microsoft TreeView Control 6.0 (SP6) and Microsoft ImageList Control 6 (SP6).
• I could add the Microsoft TreeView Control, Version 5.0 (SP2) and Microsoft ImageList Control, Version 5.0 (SP2) without raising the error (I didn't try making them work though).

Does anyone know of similar mishap with MSCOMCTL.OCX following yesterday's Microsoft updates? That may confirm it could be the source of my problem.

Does anyone know of a fix?

Does anyone know how to report this to Microsoft (if indeed it is the source of the problem)?

And finally, for those interested, there is a way to avoid Microsoft Updates messing up ActiveX controls...not using them! This is what JPK has done for his TreeView.

Answer 1

our Business-ERP-Software Faktura-XP got the same problem since yesterday, we investigated the Problem and created a Patch for it, maybe it will help someone:

http://www.faktura-xp.de/faktura-xp-download/update-und-patch-oeffentlich.html#toggle-id-4

In our Case, the TreeViewControl stopped working, but it will be the same Problem with Automatition. Microsoft updated the MSCOMCTL.OCX to Version 2.2, if the Key {831FDD16-0C5C-11D2-A9FC-000F8754DA1} has an empty 2.1 or 2.0 Entry the Common Control will stop working. Solution: Delete Key 2.0 and 2.1, leave 2.2, unregister the mscomctl.ocx and reregister it.

Our Patch will do exactly this, nothing more, nothing less, but as simple as possible for our customers, just click Next and Close.

Edited for more information:

HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2

is freshly created when register the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32

When there is a SubKey named 2.1 it enters a reference that 2.2 is now the Key for use.

If there is a 2.1 SubKey with nothing in it, your Object will fail to create because it will use the 2.1 Version, can't and didn't check for 2.2 Version.

Delete this Key if neccessary and youre good to go.

Further Testings shows that 2.0 SubKey is obsolete and could cause Problems.

Mostly Systems with Microsoft Windows 7 had this Problem. For our Software, no-one with Windows 8.1 or Windows 10 called a Problem after the current Update.