Security Update for mscomctl.ocx (KB2597986 MS12-060) August 2012 Updates: Listbox double-click no longer works

Anonymous
2012-08-15T12:25:26+00:00

After installing the August 2012 round of patches (MS12-060: Vulnerability in Windows common controls could allow remote code execution), an Access 2010 application using the Windows common controls Listbox no longer responds to a double-click.

The update installs MSCOMCTL.OCX 6.1.98.34 dated 6 Jun 2012.

Reverting to the previous version of the file (version 6.1.98.33, variously dated 7 or 14 Feb 2012 solves the problem.

I think this probably applies to Win XP as well.

Anyone else come across this? Any other issues with this update?

Windows for home | Previous Windows versions | Apps

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments
Answer accepted by question author
Anonymous
2012-08-15T16:40:53+00:00

We had the problem and the way round it is to unregister mscomctl.ocx, log off, log back on and then register mscomctl.ocx.  The log off stage is important.  Without doing this unregistering and registering doesn't work.

This 'fix' has worked for us on PCs running Office 2003, 2007 and 2010 (Windows 7 64bit, Vista and XP)

Was this answer helpful?

7 people found this answer helpful.
0 comments

104 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2012-08-15T18:04:34+00:00

    We had the problem and the way round it is to unregister mscomctl.ocx, log off, log back on and then register mscomctl.ocx.  The log off stage is important.  Without doing this unregistering and registering doesn't work.

     

    This 'fix' has worked for us on PCs running Office 2003, 2007 and 2010 (Windows 7 64bit, Vista and XP)

    I've followed this procedure for Office 2003, 2010 with Win 7 (32 & 64 bit) and XP. Not sure whether logoff and logon is strictly necessary, but hey, it works!

    regsvr32 needs to be run under an administrator command prompt for Win 7

    Was this answer helpful?

    0 comments
  2. Anonymous
    2012-08-15T17:50:18+00:00

    A couple of those issues I was having were red herrings.

    Looks like unregistering and then registering the new file is doing the trick. But it HAS to be done with either UAC turned off, or with elevated permissions.

    So I just wrote a quick batch file:

    c:\windows\sysWOW64\regsvr32 -u mscomctl.ocx

    c:\windows\sysWOW64\regsvr32 mscomctl.ocx

    (For my 64-bit users)

    I put that in a RAR file, then created a self extracting EXE that extracts the BAT file to c:\temp, then fires it off, requested ADMINISTRATIVE RIGHTS.

    No logging off needed so far. Whew.

    Again...

    THANKS MICROSOFT FOR PUSHING OUT A PATCH THAT YOU DIDN'T PROPERLY VET!!!

    You need to unregister your old system file references when you update a SYSTEM FILE!!!!!

    Was this answer helpful?

    0 comments
  3. Anonymous
    2012-08-15T17:44:21+00:00

    one thought, not sure if it will help, but we needed to have both kb2597986 and KB2958243 installed to make it work. That would be the MSComctl.ocx and the VBE7.dll from 7/10/2012.  On one of our attempts we only had the ocx hotfix installed and our application (MS Access based) crashed.

    Was this answer helpful?

    0 comments
  4. Anonymous
    2012-08-15T16:10:22+00:00

    I have fixed enough computers now by unregistering and registering the mscomctl.ocx component that I've gone ahead and issued a general fix to all my customers.  I will report back to this thread if any report that it doesn't work and what their symptoms and installed updates might be.

    Was this answer helpful?

    0 comments