On August 14, 2012, Microsoft released a security update that included an update to the Windows Common Control MSCOMCTL.OCX:
|File name||File version||File size||Date||Time|
Notice the control's date is from June but it was in the August security update.
This affects the following versions of Windows:
After installing the update, the Windows Common Control Library does not work. The issue seems to stem around a defective installation or registration of the OCX file. This update causes problems with existing Microsoft Access, VB6 and other applications using common controls such as the Treeview and Listbox controls.
The symptoms are rather odd. It's not as if the control is completely missing or not registered. The control exists but does not behave correctly as events are not firing correctly. For instance, the Treeview control don't issue NodeClick events, so any code that expects the expansion of a node to display or load more data fails. It took us a while to discover that a change in this control caused this problem.
In other cases, users are reporting that Microsoft Access locks up and crashes. People are also reporting problems with this in Visual Basic 6 (VB6) applications. Here are additional reports of issues associated with this patch.
This impacts our Total Access Analyzer product which displays the results of your Microsoft Access database documentation with the Treeview control. This error appears:
Error 459 - Object or class does not support the set of events, Procedure clsFrmExplorer_TAA.InitForm
If your PC received the security update and you're using the Microsoft Access 2010, 2007, 2003, 2002, or 2000 version of Total Access Analyzer, the Treeview control in our Database Explorer view no longer functions properly.
Microsoft has acknowledged problems with their security update that is causing these problems. The issue is caused by a registration of the updated MSCOMCTL.OCX file. Microsoft has released a Knowledgebase article 2687441 addressing this problem entitled: MS12-060: Description of the security update for 2007 Office system: August 14, 2012.
In that article, they mention the known issues with the security update:
Windows Common Control-based embedded ActiveX controls may fail to load within pre-existing office documents, within third-party applications, and when you insert new controls in developer mode. For example, depending on your operating system, you can type the either of the following commands at an elevated command prompt, and then press Enter:
The article goes into details about unregistering the control and re-registering it using a batch file calling REGEDIT.EXE.
In our internal testing, we've discovered that the recommended steps don't work in most cases. Just unregistering and re-registering the control doesn't solve the problem. We tried adding a reboot between steps, but that didn't help either. The steps below work consistently. An technical explanation why is given at the end.
While there seems to be nothing physically wrong with the new OCX, we need to register another version to reset it. Here are the steps we discovered to manually repair this issue reliably and consistently:
You need Administrator rights to make registry changes. Depending on your operating system and Windows login rights, you may not be allowed to do this.
From your Windows Start button under, All Programs, Accessories, launch the Command Prompt by right clicking on it and choosing "Run as administrator".
You can then copy the Regsvr32.exe command lines described below into the dialog.
The 64-bit steps are identical to the 32 bit version except the folder is SYSWOW64 rather than SYSTEM32:
The reason why Microsoft's recommendation to un-register and re-register the new MSCOMCTL.OCX Common Control fails is because it doesn't overwrite the legacy control's registry on the machine. Industry colleague, Andrew Rohm provides this nice explanation:
The problem is that the update leaves some old 2.0 Version entries in the Registry. The previous MSCOMCTL.OCX carried the version number 2.0 (the *File* Version is 6.something but in the registry it's known as Version 2.0).
The new file version is 18.104.22.168 but Version 2.1 in the registry. Here we are talking about registry entry:
The patch installs the new version but leaves a part of the old registry settings.
By installing and uninstalling the legacy control, it cleans up the 2.0 registry so the new version is installed properly. The offending registry that needs to be deleted is:
Thank you Andrew for sharing your insight! Microsoft has since provided an update to their page.