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:

The issue is this KB if you’re running Office 2010:

The issue is this KB if you’re running Office 2007:

The issue is this KB if you’re running Office 2003:

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

@Echo Off

Echo Re-Registering the MSCOMCTL.OCX file

if "%PROCESSOR_ARCHITECTURE%" == "AMD64" goto x64

%systemroot%\system32\regsvr32 /u mscomctl.ocx /s

%systemroot%\system32\regsvr32 mscomctl.ocx /s



%systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx /s

%systemroot%\sysWOW64\regsvr32 mscomctl.ocx /s


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:


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.