Office Update ships ‘wrong’ MSComCTL.ocx (Jan. 2019)

Windows Update[German]Blog reader Sam pointed out an issue with Microsoft's MS Common controls (thanks for that), which is causing trouble. Microsoft ships wrong versions of MS Common Controls (MSComCTL.ocx) via Office update. In January 2019 it probably happened again with an Office 2019 update.


An old case from 2017

I had discussed this case in the 2017 within my German blog post Januar-Update MS16-004 bricht MSComCTL.ocx. The MS16-004 from 2017 update obviously leads to considerable compatibility issues with VB6 and VBA applications. At that time I had received the following information from a blog reader.

Microsoft has once again annoyed developers with the MS16-004 update, as it incremented the version of the typelibs of MsComCtl.ocx. Unfortunately this breaks the compatibility.

The problem is that if the version numbers of the TypeLibs are changed, all Visual Basic and VBA applications that use these TypeLibs will no longer run. In the past, Microsoft has always 'managed' it to use such updates to accidentally kill office add-ins or VB programs.

A new case in 2019?

I guess something like that happened again. Blog reader Sam sent me the following text.

I have noticed that Microsoft delivers another wrong file version of the MS Common Controls (mscomctl.ocx) with the Office January 2019 updates. It affects the following file:

18.01.2019 22:33 1'410'216 MSCOMCTL.OCX

With Office 2019 C2R this is especially stupid, because there is only a new build. A manual deinstallation of the respective update is not possible.

With the other Office versions I found absolutely no hints at Microsoft which patch will deliver the wrong MS Common Controls file version in Dec 2018 or Jan 2019. MS is totally silent here.

Probably because about 2 years ago the same misery has already happended [GB: See my hints above].

Within this Technet thread similar issues with Microsoft Office 365 ProPlus Build 10730.20264 and MSCOMCT.ocx are discussed. Sombody solved it in the following way:

  1. Unregister the OCX by RegSvr32 /u "C:\Windows\SysWOW64\MSCOMCTL.ocx" in C:\Windows\SysWOW64.
  2. Delete the OCX file from C:\Windows\SysWOW64 folder.
  3. Restart the PC.
  4. Place an earlier version of the OCX (6.01.9846) into C:\Windows\SysWOW64.
  5. Register the OCX by RegSvr32  "C:\Windows\SysWOW64\MSCOMCTL.ocx".

After a re-registration of the replaced .OCX file the controls worked again. Anyone else affected?


February 2019 updates causes the same

Sam left me a feedback to my German blog post, indicating, that February 5, 2019 Office updates are shipping also the wrong OCX version. He wrote

Directory C:\Program Files (x86)\Microsoft Office\root\vfs\SystemX86
07.09.2018 18:56 658'432 MSCOMCT2.OCX
05.02.2019 05:52 1'410'216 MSCOMCTL.OCX
2 file(s), 2'068'648 Bytes

Directory  C:\Windows\SysWOW64
07.09.2018 18:56 658'432 MSCOMCT2.OCX
07.09.2018 18:56 1'070'232 MSCOMCTL.OCX
2 file(s), 1'728'664 Bytes

Since I am prepared for this case I simply copy the mscomctl.ocx from the directory "C:\Windows\SysWOW64" into the directory "C:\Program Files (x86)\Microsoft Office\root\vfs\SystemX86" (overwrite) and then the list views will work again (without re-registration via Regsvr32).

In the list of patches (Office Patchday 02/05/2019) this worse patch is of course nowhere to be found. MS simply doesn't talk about it. Really annoying and weak.

Note: Why the two ocx also have to be in the directory "C:\Program Files (x86)\Microsoft Office\root\vfs\SystemX86" I haven't found out yet.

Addendum: Since the beginning of 2019, Microsoft has been delivering these no longer suitable OCX versions with every Office update (2019). There is now a forum entry Office 2019 Pro C2R monthly Update ships wrong MsComCtl.ocx Fileversion in Microsoft Answers. And an Office MVP has deliverd an answer from the developers.

Cookies helps to fund this blog: Cookie settings

This entry was posted in issue, Update and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *