My app uses MSComCtl.ocx to display a tree control. After the Windows Security Update, customers who open my app get errors such as: “Error: TheOpenForm action was cancelled.”
The cause is an update to the MSCOMCTL.OCX file (located in \Windows\System32\ on 32-bit machines or \Windows\SysWow64\ on 64-bit machines) has been made by the Microsoft Security update described in this bulletin: http://technet.microsoft.com/en-us/security/bulletin/ms12-060
The issue is this KB if you’re running Office 2010:
http://support.microsoft.com/kb/2597986
The issue is this KB if you’re running Office 2007:
http://support.microsoft.com/kb/2687441
The issue is this KB if you’re running Office 2003:
http://support.microsoft.com/kb/2687323
If this update is installed on a development computer, a new application created using it will exhibit the same error when delivered to a computer that DOES NOT contain the update.
Rolling back the update / doing a system restore seems to solve the problem, but according to this Microsoft person’s blog entry, the problem is supposed to be fixable by just re-registering the .ocx:
The proposed solution is to create a .bat file containing something like the following (below is my version of it that uses a better method to detect the bit-ness of the computer):
|
|
When you do run that .bat file, don’t forget that you have to run it with elevated privileges (i.e. as Administrator or you’ll get a failure type of message such as: The module "mscomctl.ocx" was loaded but the call to DllRegisterServer failed with error code 0x8002801c).
So this solution sounds great and simple, only problem is that for my customers it hasn’t actually been working.
A system restore, followed by blocking the update does work, but for many of my customers, the system restores have been failing with an error:
System Restore failed to replace the file ____ with its original copy from the restore point.
For those customers we’ve then resorted to removing “Every” security update that is Microsoft Office related, regardless of version of Office, by going to the control panel add/remove programs / programs and features. Note: Some of the updates don’t have a remove option however apparently due to a dependency of some sort. Removing all the ones that do let you remove them, followed by a reboot, seems to allow you to remove the remaining ones.
The last step is to simply block the security updates from being applied by searching for updates, then right-clicking on these and choosing hide. Presumably Microsoft will eventually ship a non-breaking version of these security updates that you can install later.
UPDATE: After many hours on the phone with many customers, I’ve found that the following procedure now works 100% of the time WITHOUT requiring a system restore and WITHOUT having to rollback the update:
After working with many customers on solving this issue, we now have a new procedure to follow that will allow you to fix the issue without the need for a system restore nor the need to un-install the update.
The new procedure involves un-registering the file, replacing it with a different version, registering that file, un-registering it, then putting back the original file and re-registering it.
Here are the steps:
Step 1: Make sure you’re an admin and UAC is turned off:
Pre-Requisite: The user making the changes described below must be logged in as an administrator, and if you are on a Windows Vista or Windows 7 computer, UAC must be temporarily disabled.
To disable UAC on a Windows Vista or Windows 7 click start, then in the search box type: uac
Click on the Change User Account Control settings
Make sure the slider is set to Never Notify, and click OK. A reboot may be required.
The reason for this is that when UAC is enabled, the system will “virtualize” updates to system files that you make as an end user. If the updates you make are virtualized, they will NOT work.
Step 1: Make sure you open the command prompt as administrator
UPDATE (2012-08-27): You can avoid the UAC step above if you make sure you open the command prompt as an administrator. Click Start, then type cmd in the search box, then right-click the command prompt and choose the Run as administrator option:
Note: if you forget this step then the changes below will not work as they will be virtualized.
Step 2: Un-Register the existing file:
Open an administrative command prompt by clicking start, then type cmd and press enter.
If on Windows XP this is already an administrative command prompt. If on Windows 7 and UAC is disabled, this should be an administrative command prompt—you can tell because the title of the window will start with “Administrator:”
In the command window type these commands:
If running a 32-bit operating system:
cd \Windows\System32
If running a 64-bit operating system:
cd \Windows\SysWow64
regsvr32 /u mscomctl.ocx
Click OK.
Step 3: Rename the file
Rename the file from mscomctl.ocx to something else such as mscomctl-2012-06-06.ocx
Step 4: Place an older/different copy of mscomctl.ocx in the system32/syswow64 folder:
Get a copy of MSCOMCTL.OCX that is some other version (any other version, from any other computer it doesn’t matter – just not the 2012-06-06 version)
Extract that file to the \Windows\System32 folder (for 32-bit) or to \Windows\syswow64 folder (for 64-bit). Or extract it then copy it there:
Step 5: Register the file you downloaded:
Go back to the command prompt, then type:
Regsvr32 mscomctl.ocx
Click OK
Step 6: Immediately un-register the file:
Go back to the command prompt, then type:
Regsvr32 /u mscomctl.ocx
Click OK
Step 7: Replace the original file:
a) Rename the mscomctl.ocx file (this is the older version you downloaded) to something else such as: mscomctl-2012-02-14.ocx
b) Rename the original file from mscomctl-2012-06-06.ocx to the original name: mscomctl.ocx
Step 8: Register that file:
Go back to the command prompt, then type:
Regsvr32 mscomctl.ocx
Click OK
Step 9: Run your application
At this point, you should be done the procedure, and the application should load without error.
NOTE: as mentioned previously, this procedure DOES NOT WORK if you have UAC enabled and the registry is virtualized. (I spent 2 hours trying to figure out why it wasn’t working – don’t repeat that mistake!)
UPDATE: 2012-08-30: Possible registry-only fix:
The reason that my steps above have you swap out the new file, replace it with an older file, then put back the new file is that following these steps has the effect of deleting out registry keys that aren’t cleared out by simply un-registering the current version of the file.
In another thread on this same topic, some users have reported success by ONLY deleting this registry key:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\.
I have not personally had an opportunity to try this but for those who have, they say that deleting that key solves the problem without having to un-register/re-register anything.
Great job. It will save us a ton of hours to solve this dll hell issue. However, I want to know if this procedure will defeat the purpose of this Windows update concerning security? Thanks advance for your prompt response.
Alvin, using this procedure the security update actually remains in place.
Note: Some people in other threads have reported that simply unregistering and re-registering the file in place, also works on some machines, so I’d recommend trying that first since it’s even quicker than swapping out and replacing the file. But if that doesn’t work, then my procedure above always works.
Unfortunately doesn’t work for my own app (incase this fact is useful for others stumbling across this great blog in search of a solution).
Thank you for your hints, Darren! I saved a lot of time and many brain cells tanks to you. Great job!
Darren, you are my hero today! Thanks! Spent already 1 h with registering and deregistering several mscomctl’s versions. But your steps did the trick only. Thanks again!
Hi Darren,
Nice work.
I have noticed in my app that after following these steps, the app will now compile but as at yesterday if are using a list view or tree control, no code would fire events when clicking on a node.
As of this morning, when I tried to open forms with these controls, from the access database forms window, numerous compile errors would arise.
BUT, if you opened the forms in design mode, then in form mode, the errors disappeared. You can then open the form by any method and all seems to be working ok.
I am wondering if MS pushed something out last night because this was not the case yesterday as the continuing errors were somthing like “invalid action on mouseover” etc.
Will recompile the MDE and report if all is stlil working
thanks for the tips,
Simon
have tried everything and still doesn’t work in some computers
Thanks! Worked for me. What a pain to have this happen to a busy app on a production server.
Hi Darren,
Excellent advice!
I use MSCOMCTL in Visual FoxPro to provide Listviews, Treeviews and Statusbars.
I haven’t yet had issues reported in my live applications but I noticed a problem in the VFP IDE last week, wherein the drop down boxes were empty in the properties UI for any COMCTL control that I used.
The solution above worked a treat and is about to be batched for processing on client PCs that show any symptoms.
Regards,
Ben
One more note: I’ve simplified the procedure even further to this:
If the file is already the June 6th, 2012 version, then just:
1. Put any “non-June 6th” version of the file on the system in any folder with any name and register that file.
2. Re-register the June 6th file.
That seems to be the fastest-possible approach.
I tried above steps and the error persisted.
Although I have Win7 32 and Office 32 bit as well, in my MSAccess the reference for MSCOMCTL.OCX was pointing to Win64 folder: c:\WINDOWS\SysWOW64\. I could not change it in any way.
So I fixed the issue by creating the folder manually c:\WINDOWS\SysWOW64 and copied there the MSCOMCTL.OCX from its original location.
Restarted MSAccess, no reboot was required.
Enjoy!