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-20T11:04:30+00:00

    Any fixes here, please post ASAP! thanks! (unregistering and registering does not fix my issues).

    Was this answer helpful?

    0 comments
  2. Anonymous
    2012-08-20T09:56:57+00:00

    I have the exact same issues. Any help greatly appreciated! A manual fix for 500 machines, in different office not that easy...

    Was this answer helpful?

    0 comments
  3. Anonymous
    2012-08-20T09:08:02+00:00

    Thanks. Haven't had to go to that extreme yet but held in reserve in case. 

    The unregister/register method has worked so far, but the command prompt does need to be launched in "Run as administrator" mode, even if the user is a local administrator.

    So do MS appear to have been beaten by their own security?

    Was this answer helpful?

    0 comments
  4. Anonymous
    2012-08-20T08:52:07+00:00

    I agree with Darren.  This is effectively the same approach we posted earlier in the thread. 

    Of all the computers we have tried so far we have never managed to resolve the issue by simply unregistering and then registering the file.  Sometimes it works if youunregister the file, log off (a reboot is not necessary), log on and then register the file.  However, the one method that always works is that described by Darren.

    I would recommend this approach (complicated as it appears) to anyone for whom the simple re-register doesn't work.

    We send a batch file and an old version of mscomctl.ocx to the affected users and get them to run the bach file (it may need to be run as an administrator).  The batch file we us is:

    if exist %systemroot%\SysWOW64\cscript.exe goto 64

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

    rename %systemroot%\system32\MSCOMCTL.OCX MSCOMCTL.SAFE

    copy .\MSCOMCTL.OCX %systemroot%\system32\MSCOMCTL.OCX

    %systemroot%\system32\regsvr32 mscomctl.ocx

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

    del %systemroot%\system32\MSCOMCTL.OCX

    rename %systemroot%\system32\MSCOMCTL.SAFE MSCOMCTL.OCX

    %systemroot%\system32\regsvr32 mscomctl.ocx

    exit

    :64

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

    rename %systemroot%\sysWOW64\MSCOMCTL.OCX MSCOMCTL.SAFE

    copy .\MSCOMCTL.OCX %systemroot%\sysWOW64\MSCOMCTL.OCX

    %systemroot%\sysWOW64\regsvr32 mscomctl.ocx

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

    del %systemroot%\sysWOW64\MSCOMCTL.OCX

    rename %systemroot%\sysWOW64\MSCOMCTL.SAFE MSCOMCTL.OCX

    %systemroot%\sysWOW64\regsvr32 mscomctl.ocx

    exit

    Was this answer helpful?

    0 comments