none
Macro-enabled Excel spreadsheet crashes after Tuesday (1/8/2013) updates

    Question

  • To start we have Windows Server Update Services running that pushed updates out last night for all our computers.

    The Tuesday security updates were installed by automatic updates and we are now experiencing issues with one of our Excel spreadsheets not working anymore.  The issue is that when opening up the spreadsheet it crashes on Windows Vista (x86) and Windows XP (x86).  On Windows 7 (x86) we now get a "Compile error:  Automation error" that pops up for the VBA code:

    Private Sub Workbook_WindowDeactivate(ByVal Wn As Window)

    Everything was working fine yesterday and there haven't been any changes to the spreadsheet.  Because the issue is happening on a multitude of systems I am leaning more towards the possibility of it being something with the updates.

    We have checked all these computers to see what all had been changed and as it is now there hasn't been anything found other than the new updates that rolled out from Microsoft.

    Some of the controls this spreadsheet uses are:

    *mscomctl.ocx, mscomct2.ocx, fm20.dll, msado28.tlb, stdole.tlb, vbe6.dll, mso.dll, refedit.dll

    Has anyone else been having the same kind of issue?  Any ideas on possible causes and what else to check to get this resolved?

    Thank you!


    Wednesday, January 09, 2013 7:18 PM

Answers

  • Register mscomctl.ocx and mscomct2.ocx using regsvr32 with admin rights is necessary.


    Oskar Shon, Office System MVP

    Press if Helpful; Answer when a problem solved

    • Marked as answer by JGasp Thursday, January 10, 2013 3:43 PM
    Wednesday, January 09, 2013 10:57 PM
  • Hello

    Yes, the suggestion works and I've used it also after windows update on Augost 14, 2012. I can suggest a code for a batch file fixing the problem in the end of this message.

    Nevertheless, is there a way to applay to Microsoft in order to stop this problem? It's the second time in 5 monthes. I distribut a Word Add In to 2000 customers, and it's a big problem updating all the customers and explaining them what to do every time. It is Microsoft's interest not to harm it's own tools. 

    This is the code:

    if exist %systemroot%\SysWOW64\cscript.exe goto 64
    %systemroot%\system32\regsvr32 /u mscomctl.ocx
    %systemroot%\system32\regsvr32 mscomctl.ocx
    exit
    :64
    %systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx
    %systemroot%\sysWOW64\regsvr32 mscomctl.ocx
    exit

    Avi

    • Marked as answer by JGasp Thursday, January 10, 2013 4:00 PM
    Thursday, January 10, 2013 7:54 AM

All replies

  • Register mscomctl.ocx and mscomct2.ocx using regsvr32 with admin rights is necessary.


    Oskar Shon, Office System MVP

    Press if Helpful; Answer when a problem solved

    • Marked as answer by JGasp Thursday, January 10, 2013 3:43 PM
    Wednesday, January 09, 2013 10:57 PM
  • Hello

    Yes, the suggestion works and I've used it also after windows update on Augost 14, 2012. I can suggest a code for a batch file fixing the problem in the end of this message.

    Nevertheless, is there a way to applay to Microsoft in order to stop this problem? It's the second time in 5 monthes. I distribut a Word Add In to 2000 customers, and it's a big problem updating all the customers and explaining them what to do every time. It is Microsoft's interest not to harm it's own tools. 

    This is the code:

    if exist %systemroot%\SysWOW64\cscript.exe goto 64
    %systemroot%\system32\regsvr32 /u mscomctl.ocx
    %systemroot%\system32\regsvr32 mscomctl.ocx
    exit
    :64
    %systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx
    %systemroot%\sysWOW64\regsvr32 mscomctl.ocx
    exit

    Avi

    • Marked as answer by JGasp Thursday, January 10, 2013 4:00 PM
    Thursday, January 10, 2013 7:54 AM
  • Unregistered and re-registered these and everything works fine now on all systems.

    Any idea why this occurs after the updates get applied?

    Thank you!

    Thursday, January 10, 2013 3:45 PM
  • Used the batch code provided and it works like a charm.

    It would in fact be nice if this was resolved.  Looking back we had an issue similar to this a little over a year ago and it is quite frustrating for both admins and end users the time spent trying to fix it.

    Thank you for the code!

    Thursday, January 10, 2013 4:00 PM
  • Thanks to all of you to share the helpful information to us! This will help the others who meet the same issue.


    Jaynet Zhang
    TechNet Community Support

    Friday, January 11, 2013 5:07 PM
    Moderator
  • If the above re-registration procedure doesn't work ( it didn't work for me ), there is another option ( which did work for me ):

    This solution copied from post #5 at http://www.ozgrid.com/forum/showthread.php?t=179860 :

    Solution: 

    1. Go to the Developer Tab and click “Macro Security”.
    2. Click the dot entitled “Disable all macros with notification”
    3. Go to Trusted Locations (on the left) and temporarily click “Disable all Trusted Locations”
    4. Go to Trusted Documents and temporarily click “Disable all Trusted Documents”
    5. Click Ok and now open “Allocations” or whatever file was not working
    6. Do not click “Enable Macros”…instead go to the Developer Tab and open Visual Basic
    7. On Visual Basic, click save and then click Debug > Compile VBAProject
    8. Save in VB and Save in the Excel spreadsheet & then close the file
    9. Open it and Enable Macros. Should work now.


    Thursday, December 19, 2013 8:58 PM
  • Strangely it really works.

    Thank you a lot, ABWC!


    Monday, April 14, 2014 10:58 PM