10

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.

robyaw
  • 2,274
  • 2
  • 22
  • 29
Thomas Basset
  • 101
  • 1
  • 1
  • 6
  • I've reached out to Microsoft about this. – teylyn Jan 15 '16 at 03:35
  • It could be coincidence but somebody posted today about this type of problem happening for them every few months. Perhaps you could confirm with them that last night's updates affected them: http://stackoverflow.com/q/34802398/293078 – Doug Glancy Jan 15 '16 at 04:09
  • It seems *very* unlikely that there wouldn't be any .exd files on the computer. Did you include hidden folders in your search? – Rory Jan 15 '16 at 07:35
  • You are right Rory. I must have involuntarily stopped the search before it was completed. I have found several .exd today, including MSComctLib. I was unsure if I should delete all of them, and after having read more info on what a .exd fil is [here](https://support.microsoft.com/en-us/kb/290537) I decided to delete them all. My workbook still suffers from the "Compile error: Object library feature not supported". – Thomas Basset Jan 18 '16 at 01:56
  • @teylyn Did you get any feedback from Microsoft about this ? Has there been any other queries raised ? Daniel Alexander Karr & I can't be the 2 only one using TreeView Control 6.0 in our workbooks ??? – Thomas Basset Jan 19 '16 at 09:50

4 Answers4

3

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.

Andre
  • 26,751
  • 7
  • 36
  • 80
Daniel Alexander Karr
  • 325
  • 1
  • 4
  • 16
  • Hi Daniel, this seemed promising, but unfortunately didn't seem to work. – Thomas Basset Jan 18 '16 at 02:19
  • But thanks for sharing your patch by the way. I am not a professional developer. Could you please explain further: -where the version (2.0,2.1,2.2) is referenced (right clicking on the file to get its property gives me 6.1.98.46). -what is the Key {831FDD16-0C5C-11D2-A9FC-000F8754DA1} ? I need to understand your post sufficiently in order to explain to my IT service what is it I'm trying to do, as they may not be happy with me sending your patch to all of my colleagues using this workbook. Thanks. – Thomas Basset Jan 18 '16 at 02:33
  • The Key is found in the Registry, when investigating the Tree HKEY_CLASSES_ROOT\TypeLib and search for "MSCOMCTL.OCX" you will find this Key, its the Key that will be created when registering the OCX via REGSVR32, when you use the Microsoft Common Controls in your Project and inside this Tree there are more than Version 2.2 but empty e.g: 2.2 -> fresh created but 2.1/2.0 -> is empty, your Control will fail to use without any great error message. If so, delete 2.1 and/or 2.0 and it works, we've tested with a complete 2.1 tree-entry, it seems that the 2.2 OCX adds reference to it in 2.1 not 2.0 – Daniel Alexander Karr Jan 18 '16 at 08:52
  • Thanks Daniel. I have verified the registry, and, as I had run your patch, found only the 2.2 key, with the following hierarchy: 2.2/0/win32 and the following data: 2.2=Microsoft Windows Common Control 6.0 (SP6), 0=(value not set), win32=C:\windows\SysWow64\mscomctl.ocx. I have verified on a workmate computer that he had a 2.0 key and a 2.2 key prior to running your patch, and only the 2.2 key left after running your patch, with the above structure. The workbook doesn't work on that computer either. – Thomas Basset Jan 19 '16 at 02:10
  • On both computers we find reference to MSCOMCTL.ocx in numerous places in the registry (how did you know it was this particular entry {831FDD16-0C5C-11D2-A9FC-000F8754DA1} that was relevant ?) – Thomas Basset Jan 19 '16 at 02:16
  • Incredibly enough, I have checked a 3rd computer, which also had the faulty 2.0 key...but the workbook runs on this one ! I am running out of time to investigate today how the set-up differs between this 3rd computer and the 2 previously tested computers. I will try tomorrow. I would appreciate any advice as to where to look for differences (MSCOMCTL.OCX was in SysWOW64 on all 3 machines, and our Office install is in Program files (x86) on all 3 machines. – Thomas Basset Jan 19 '16 at 02:27
  • {831FDD16-0C5C-11D2-A9FC-000F8754DA1} is the main Key for the Common-Controls, mostly used for the treeview-Control. When any other Controls where used, registry has other Entries from mscomctl in it. If your Program uses treeview Control it will work as aspected, if the Project using mscomctl and a "extended control" which is located in {831FDD16-0C5C-11D2-A9FC-000F8754DA1} AND another, you have to delete both of them faulty entries. – Daniel Alexander Karr Feb 05 '16 at 12:24
  • Another Note: you need to delete every 2.0 / 2.1 entry from the controls in HKCR for mscomctl when using 2.2 because your VBA Application will take the first it finds, if its faulty (nothing inside) it will break, if there is a "reference note for higher version" VBA can't handle it and didn't refer to it. To get the CLSID for your Control, search for "Controltypename typelib HKEY_CLASSES_ROOT" like "treeview control typelib HKEY_CLASSES_ROOT" there most of the CLSIDs will be shown for, another way is to search the registry for "mscomctl.ocx" inside HKCR\TypeLib – Daniel Alexander Karr Feb 05 '16 at 12:29
0

Similiar problem here: Ancient Access 97 app on ancient XP (not for long anymore, sigh of relief) quits saying "Error 91: Object variable or With block variable not set". Examination showed it happens when the progress bar control which resides in Mscomctl.ocx is adressed.

I found that KB2881029 (MS16-004) is the culprit. It installs the new version of MSCOMCTL.OCX. On machines w/o this update the Access app works fine. But it is not suited for removal, at least this is what our WSUS told me when I was going for it. Anyway we wouldn't want to live w/o a security update.

Having read the answer concerning HKCR\TypeLib{831FDD16... I tried deleting the at that time still populated \2.0 subkey prior to installing the update only to find out that even with a non existing \2.0 subkey the update does create the empty one on installation. Well done, Microsoft...!

wmelonman
  • 21
  • 2
0

Thanks all for your contributions,
I have found that de-referencing and re-referencing the Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project would finally make it work.
!!!...BUT...!!!
Simply un-ticking / re-ticking the tick box would be too simple ! For re-referencing it, 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"))
I have tried simply doing this on a machine where I hadn't run Daniel Alexander's Patch (to un-register and re-register MSCOMCTL.OCX, and remove the old empty 2.0 key from the register), and it didn't work, so I expect the above steps are required. I will try to thoroughly test which steps are necessary and edit this answer to spell out the whole procedure, step by step, but for the time being running Daniel Alexander's patch (AS ADMINISTRATOR !) and re-referencing Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project seem to work.

Thomas Basset
  • 101
  • 1
  • 1
  • 6
0

The problem has been described in detail here:

"Error messages or Access crashes after you install security update MS16-004"
MS: Article ID: 3139567
(Last Review: 02/16/2016 19:15:00 - Revision: 3.0)

https://support.microsoft.com/en-us/kb/3139567

cypizek
  • 327
  • 2
  • 6