This week’s Microsoft Security update includes a breaking change to MSComCtl.ocx located on most computers in C:\Windows\SysWow6432\mscomctl.ocx. The update has a different title / KB # depending on the version of Microsoft Office you have installed. The ones that I have encountered so far include:
Security Update for Microsoft Office 2010 (KB2881029) 32-Bit Edition: Link:
https://support.microsoft.com/en-us/kb/2881029Security Update for Microsoft Office 2013 (KB3039794) 32-Bit Edition: Link: https://support.microsoft.com/en-us/kb/3039794
Security Update for Microsoft Office 2016 (KB2920727) 32-Bit Edition: Link: https://support.microsoft.com/en-us/kb/2920727
In all cases, the update replaces mscomctl.ocx with a new version 6.01.9846.
Microsoft had previously “broken” this control before, however last time it happened, the issue was with the registry. A simple work around of registering an old version and re-registering the current version typically worked to fix the issue.
This time, that work around does not appear to work.
Users of Blue Link Elite that are affected will see an “Object doesn’t support this property or method” error message when they launch the software: “The OpenForm action was canceled” followed by:
As of this writing, the temporary work around is to un-install this update. Blue Link is working on a permanent fix that will allow the application to work with the new version of the control in place. Until then, the approach to remove the update is different depending on the version of the operating system that you have installed.
How to Remove and Block the KB on different Windows Versions
Windows 10 / Office 2016 32-bit example
To remove the already installed update type “View installed updates” into your search bar and open the View installed updates applet:
Select the Security Update for Microsoft Office _____ (KB_______) that matches your version of Office and the KB# that updates mscomctl.ocx, then click the Uninstall button at the top of the screen.
Note: Depending on your windows update settings, it may almost immediately attempt to RE-INSTALL the update, so it is important that when this step is complete that you do not unnecessarily delay before performing the next step of blocking the update.
To Block the update on Windows 10 you now have to download a special tool since Microsoft removed the built-into-the-os version of the feature.
If running Windows 10, you’ll have to download the wushowhide.diagcab file from here:
https://support.microsoft.com/en-us/kb/3073930
Click Next, To Block the update if already un-installed, choose the hide option and then you’ll be presented with a list of updates that have NOT YET BEEN APPLIED to your machine. If the KB is in this list, you may selected it and then click through the wizard. This will prevent it from being auto-reapplied:
The procedure on Windows 8.1, and Windows 7 is different. This blog will be updated on a regular basis as new information is made available.
Note: If you can figure out a way to restore functionality without removing the update please post a comment below.
UPDATE: 2016-02-09: Orphaned Registry Keys are the issue
What we have been able to determine is that as Microsoft patches the mscomctl.ocx file new GUIDs get created. The old GUIDs then become pointers to the new GUIDs, but on some cases, those old GUIDs are still pointing to other GUIDs which now no longer exist. To fix that problem, those old invalid pointer GUIDs need to be deleted, but Microsoft’s installer for the KB does NOT detect and delete the bogus pointers successfully resulting in the controls not working.
One of our developers has created a utility that will crawl through the mscomctl related registry keys, deleting most. When that utility is done running he has instructed us to then copy/paste some additional registry deletion commands to an admin command prompt.
Since I don’t expect readers of this blog to simply trust running a .net executable I’ve asked the developer to give me the files and the source code so that we can post it here.
UPDATE: 2016-04-20: I wasn’t able to get the source code, but I am making a version available for download here.
It should go without saying that you should of course BACKUP your registry before you run any kind of registry script as a best practice. I cannot assume any responsibility for your actions running deletion scripts against the Windows registry. That said, our techs are now able to follow these steps and have this issue fixed 99% of the time using the latest security fix version of mscomctl.ocx:
Step 1: unregister the current file: From an Administrator command prompt:
- change to the folder containing the mscomctl.ocx file (C:\WIndows\System32\ if 32-bit or C:\Windows\SysWow64 on a 64-bit machine).
- regsvr32 /u mscomctl.ocx
Step 2: Run the BLRegClean_Net.exe utility (Source code coming soon).
Step 3: BACKUP YOUR REGISTRY (if this is the first time you’re trying this for example)
From an administrator command prompt run the following additional deletion statements.
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{DD9DA666-8594-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{2C247F23-8591-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{F91CAF91-225B-43A7-BB9E-472F991FC402}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{BDD1F04B-858B-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{996BF5E0-8044-4650-ADEB-0B013914E99C}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{979127D3-7D01-4FDE-AF65-A698091468AF}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{35053A22-8589-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{F08DF954-8592-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{8E3867A3-8586-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{627C8B79-918A-4C5C-9E19-20F66BF30B86}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{1EFB6596-857C-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{24B224E0-9545-4A2F-ABD5-86AA8A849385}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{66833FE6-8583-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{7DC6F291-BF55-4E50-B619-EF672D9DCC58}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{C74190B6-8589-11D1-B16A-00C0F0283628}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{9181DC5F-E07D-418A-ACA6-8EEA1ECB8E9E}" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{95F0B3BE-E8AC-4995-9DCA-419849E06410}" /f
Step 4: Re-Register the mscomctl.ocx file
- change to the folder containing the mscomctl.ocx file (C:\WIndows\System32\ if 32-bit or C:\Windows\SysWow64 on a 64-bit machine).
- regsvr32 /u mscomctl.ocx
In most cases these steps alone are sufficient to solve the problem.
In the cases where this has not worked, the technique of register an older version of mscomctl.ocx and then re-register the current version has worked after performing the steps above.
Darren Myher's Blog 
Removal of this patch on Windows 7 systems is prevented by Microsoft (rollback not supported unless request initiated by a WSUS server). Have you had any luck getting around this?
Same here. I am unable to uninstall this patch. I developed an Access application that uses a Treeview. User who don’t have the new OCX are now unable to open the MDE files that I publish. As a solution I tried to manually roll back by unregistering 6.01.98.46, deleting the file, copying in MSCOMCTL.OCX 6.01.98.39, registering it and rebooting. Unfortunately my manual method was incomplete because now I can’t open the Access application, even old versions that were created before the bad Microsoft update. To recover from this I ran the Microsoft Office repair and my computer reverted back to .46.
I can’t ask all of my users (clients) to install the update so my thought is if I can roll back my computer to .39, anything I publish will work for people with .39 or .46. I’m hoping that this is a viable solution until all of my users have installed the update.
I was hoping that “System Restore” could bail me out but no restore points exist prior to this update that my computer received on 1/20/216.
If anyone has more advice on solving this issue on my computer, so that I don’t have to repair all of my users computers, please post to this thread. I am using Windows 7 64-bit and Office 2010 32-bit. My customers are using Windows 7 64-bit and Office 2010 32-bit or Office 2013 32-bit.
We have determined that deleting certain registry keys then re-registering fixes the issue in many if not all cases. Will post the keys tomorrow.
Thanks for the heads-up. I’m looking forward to your post on Monday. Please clarify in your post if this fix has to be run for every user, or if I can use it as a way to roll back my development machine so my users who don’t have .46 can continue using my published files. I’m looking for the latter of the two.
Just delete this empty key:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0
The new version is
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.2
but MS somehow manages to create the old, dysfunctional 2.0 key.
Still have problem here, tried everything on this post, still no luck. Can’t uninstall this update on Windows 7 whatsoever, tried with msiexec, still not possible. We have more than 100 users who cannot work, great Microsoft!
We’ve had some success placing a working version of mscomctl.ocx in a different (non-Windows) folder and registering it there. But results are not consistent.
Roman suggests re-compiling the application with the “security fix” version of the control however in our early tests that didn’t work. We are going to try that again soon in a controlled test environment.
If you have an Access-Application, the supplier hast to Re-Compile the Application with the Patches installed and create a new setup. After installation of the new setup, the application wil run as before.
Regards, Roman
KB2726929 is also one that updates the MSComctl.ocx file.
1. Step 4 corrected: Step 4: Re-Register the mscomctl.ocx file
KO: regsvr32 /u mscomctl.ocx
OK: regsvr32 mscomctl.ocx
2. Quick and dirty: Place the ‘old’ mscomctl.ocx in MSAccess.exe-Path.
Hi Darren, seems I have some machines that will not fix with the steps suggested above. Other machines I have fixed easily with just a simple re-register. For the problem ones, I have tried deleting those registry entries you suggested (step2) but I could not find the link to your BLRegClean_Net.exe file download. So wasn’t sure if that was also needed for this suggested fix.
Much appreciated for your work and guidance on this!!
Something crazy but it works…
1) Create backup of you MSCOMCTL.OCX file
2) Open any Office application, for example Excel
3) Go to Macros (Alt+F11)
4) Tools -> References
5) Browse
6) Switch to OCX files and navigate to SYSWOW64 folder
Now the crazy point in window called Add Reference just find file MSCOMCTL.OCX and see date of change or right click and goes to properties, check the file version.
Find the same file using windows explorer, or commander or any other browsing software and check file change date and version. In our cases we saw different file version in windows browser (the new one) and in “Add Reference” window (old one).
7) In window “Add Reference” just delete the MSCOMCTL.OCX file with incorrect date.
8) Now it works
If not copy you backup file into window “Add Reference” (you do not need to add reference) because file should be registered).
What I do not understand is how it is posible to see two different versions of same file, in same location at same system :-/.
If some discover way how to do this at multiple PCs not manually, then it would be great 🙂
M@
Is there still a plan to provide the BLRegClean_Net.exe and source code?
Great info and has helped me greatly, many thanks Darren.
Worked at first but then had issues again in an Access 2010 App.
Forms with TreeCtrl from latest MSComCtl.ocx (Dec 2015) started playing up with Form Open error and MouseMove event errors.
There were no MouseMove event handlers on the forms so was bemused.
Added dummy (no code) Form level MouseMove events and all issues have magically disappeared, so have to assume MS have tweaked a bit of code in MSComCtl which influences the MouseMove event on Form level TreeCtrl’s ?
Seems to only affect 32bit also, not sure about 64bit but seems fine.
Hope this helps someone.
So..what was the final resolution? I have the same exact issue. I am using some SysInternal tools to try and figure out what the .mde is doing. Looks like the compiled .mde is looking for a 2.1 key at some points, other than that looks like it is using a 2.2 version. Strange.