Planning Tools crashing after MS Office update

Task

To assist the IT department to find the root of the issue; why some workstations were able to use the templates and others could not. 

Since the IT department was not familiar with the template files, our macros or the Essbase API it was complicated for them to address the situation, given their department scope is restricted to hardware and not software.  

Action

I took the initiative of comparing good and bad workstation. I found that a Microsoft Office Update was being pushed at the time of the issue and it was most likely the reason why the planning reports were rendered unusable. Working computers didn’t have the update, broken computers had it.

After identifying the Windows registry key that was updated, I reproduced the issue on my own workstation after applying the update, and discovered that it was related to a common control used in the macro, specifically the tree view dropdown, (the offending file was MSCOMTCL.ocx, a Microsoft common control file included in Visual Basic 6).

A value in the registry key was updated to an incorrect value, and after manually changing it back to the existing value before the update, the issue was resolved on my machine.

After verifying how to fix the issue by testing the solution on other broken computers, my manager and I contacted IT, and provided them with a batch file (found below) to update the registry remotely without any further delays. 

Results

The disruption was addressed in a quick way and planners were able to go back to work and deliver their plans within their deadlines. The the quick turnaround resulted in a WOW Award for me and my team.

Technical Data

Description of the issue: https://www.fmsinc.com/MicrosoftAccess/Controls/mscomctl/

After installing the update, the Windows Common Control Library stopped working. The issue was pinpointed to a defective installation or registration of the OCX file includesd in the update. 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.

Solution

Microsoft's recommended steps, to unregister and register the control file MSCOMCLT.OCX, didn't work.The reason why is because the provided solution doesn't overwrite the legacy control's registry on the machine. The offending registry that needed to be deleted was:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 

A batch file was created to delete the registry automatically and remotely by the IT team:

reg delete hkcr\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 /f
if exist %systemroot%\SysWOW64\cscript.exe goto 64
%systemroot%\system32\regsvr32 /u mscomctl.ocx /s
%systemroot%\system32\regsvr32 mscomctl.ocx /s
exit

:64
%systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx /s
%systemroot%\sysWOW64\regsvr32 mscomctl.ocx /s
exit