none
APPCRASH VBE7.DLL 2010 Edition

    Question

  • Anyone experience this problem ? Appears to occur with fairly large workbooks with a diverse set of modules, classes, forms, etc. 4500 lines of VBA code.

    At some point, after several editing sessions, the workbook cannot be saved....you lose your latest changes.

    Is this related to the VBA7 bug seen in Access 2010 I wonder ? In that product, there is a /decompile command line option. In Excel, we can only "Open and Repair"....which I believe cannot be done from the command line. Also, this only provides some limited time of relief. It appears as though all VBA code and forms must be exported, deleted, and re-imported.....I'm still testing this theory.

    VBE7.DLL version 7.0.16.25 ; related kb article:

    http://support.microsoft.com/kb/2596585

     

     

     


    • Edited by Syswizard Tuesday, December 27, 2011 1:24 AM
    Tuesday, December 27, 2011 1:13 AM

Answers

  • A quick check in the archives finds some recommend checking for missing references, or fully qualifying object references, eg MSforms.checkbox rather than allowing ambiguity with some libraries.

    4500 lines of VBA code is not too much if it's divided over  modules. But anything over, say, 1200 lines in one module and you're probably hitting the 64K / module limit.

    It is known that editing VBA code a lot can cause it to become unstable eg "Excel has stopped working" and the frosted app when I've been editing for too long without code cleaning. Every hour or so to create a backup I use Rob Bovey's Code Cleaner which in a few seconds does the export/import you describe.   

    http://www.appspro.com/Utilities/CodeCleaner.htm

    I also export the code to .BAS files and check that no file is going above 64K as that is almost guaranteed to cause problems. 

    Let us know if you find a solution, or the problem goes away.

     

    • Marked as answer by Syswizard Wednesday, December 28, 2011 12:09 PM
    Wednesday, December 28, 2011 9:41 AM

All replies

  • Anyone experience this problem ? Appears to occur with fairly large workbooks with a diverse set of modules, classes, forms, etc. 4500 lines of VBA code.

    At some point, after several editing sessions, the workbook cannot be saved....you lose your latest changes.

    Is this related to the VBA7 bug seen in Access 2010 I wonder ? In that product, there is a /decompile command line option. In Excel, we can only "Open and Repair"....which I believe cannot be done from the command line. Also, this only provides some limited time of relief. It appears as though all VBA code and forms must be exported, deleted, and re-imported.....I'm still testing this theory.

    VBE7.DLL version 7.0.16.25 ; related kb article:

    http://support.microsoft.com/kb/2596585

    Hi,

    I'm try to reproduce the issue as you said, but no luck, maybe I lost some important steps which you missed to tell me. So would you like to more specific about this issue? How does the Excel program actually behavior when you save a large workbook, and how to reproduce the issue steps by steps?

    I look forward to hearing of you.


    Calvin Gao[MSFT]
    MSDN Community Support | Feedback to us
    Wednesday, December 28, 2011 7:22 AM
  • A quick check in the archives finds some recommend checking for missing references, or fully qualifying object references, eg MSforms.checkbox rather than allowing ambiguity with some libraries.

    4500 lines of VBA code is not too much if it's divided over  modules. But anything over, say, 1200 lines in one module and you're probably hitting the 64K / module limit.

    It is known that editing VBA code a lot can cause it to become unstable eg "Excel has stopped working" and the frosted app when I've been editing for too long without code cleaning. Every hour or so to create a backup I use Rob Bovey's Code Cleaner which in a few seconds does the export/import you describe.   

    http://www.appspro.com/Utilities/CodeCleaner.htm

    I also export the code to .BAS files and check that no file is going above 64K as that is almost guaranteed to cause problems. 

    Let us know if you find a solution, or the problem goes away.

     

    • Marked as answer by Syswizard Wednesday, December 28, 2011 12:09 PM
    Wednesday, December 28, 2011 9:41 AM
  • Thanks Patrick. Indeed, after running my own routine of export, delete, and import....all is well...SO FAR.

    I am anxious to see if the problem surfaces again in the near future.

    What's interesting of course is that after doing the above, many of the references needed to be checked back on and refreshed....so a references issue could also be the culprit. As this is inherited code, I am sure the objects are not being fully qualified, so I will check that. There are a LOT of referenced libraries in this project as well as a proprietary add-in.

    Calvin: this code was inherited from a 2003 project, converted from XLS to XLSM. Then compiled and modified under 2007....and it began to crash there. So I moved to 2010 with similar results.

     

     

    Wednesday, December 28, 2011 12:15 PM
  • Unfortunately, the Appspro cleaner did not work when used in Clean Only mode.

    Once again, the only way to fix it was to reopen in "Open and Repair" mode.

    Obviously, there are other structural problems with this workbook.

    My next attempt is Export VBA using the tool, Save/Close the workbook, Open And Repair, re-Import the VBA, Fix the references, re-compile, save, and then once again, Open And Repair.

    Are we having fun yet ?

     

    Wednesday, December 28, 2011 4:37 PM
  • " fix it was to reopen in "Open and Repair" mode."

    So, what problems were reported in the repair log?

    Suggested change to sequence:

    Export VBA using the tool, Save/Close the workbook,

    Open And Repair, Save/Close the workbook,

    Open and Fix the references, re-Import the VBA, re-compile, save, close,

    and then once again, Open And we should not need to Repair (fingers crossed)

     

    Wednesday, December 28, 2011 5:12 PM
  • No messages that made any sense (always a BAD sign !).

    Thanks for that....will give it a try.

    It's been running fine all afternoon. Another side effect I noticed:
    It will SAVE and then Excel hangs. "Look for online solution and restart" of course works, but with no message.

     

    Wednesday, December 28, 2011 9:02 PM
  • Now things are being saved, but now I get "Excel Has Stopped Working"....same DLL, same error.

    Excel must be closed once again.

    Even CodeCleaner is blowing up: "Method '~' of Object '~' Failed (Main)" error is thrown when importing code.

     

    Friday, December 30, 2011 8:07 PM
  • OK, some more things...

    1) Of the .BAS files you have exported, what is the largest size?

    2) When it crashes, can you alt-tab around and see if there is some vba msgbox hidden behind other windows?

    3) Can you get a sense of where it crashes? Put statusbar chatter in there, watch it, and see if it is reproducible. It may be some object losing its reference. If desperate, sprinkle some DoEvents magic dust to see if that gives Excel a chance to breathe.

    4) Check carefully for byref/byval usage. Sometimes passing byref (implicitly) causes a crash if the -parameter gets changed in the called proc, so make that byval. This can be important in API calls, if any.

    5) Could it be an infinite loop that runs out of resources? Forgetting to increment an index is a common way for this to happen.

    6) I have seen use of INDIRECT with invalid references to cause Excel to crash on recalc. Can you turn off Recalc before Save (put it back when you have it working!) and see if the crash after Save goes away?

    7) Put in CreateBackup:=True in the Save or SaveAs line so at least you always have a backup, and also set that option in the workbook properties under Save.

    8) About the Method ~ fail, see http://stackoverflow.com/questions/1302026/what-does-method-of-object-failed-mean

    Are you running multiple versions of Excel or does the app rely on proprietary DLLs?

    also see the ADO problem at http://support.microsoft.com/kb/255986

    It does compile, right? 

    If you find the cause, post it to help others - thanks!

     

    Saturday, December 31, 2011 6:04 PM
  • Largest BAS file is 191k, the next is 85k.
    I don't get it about the 65k limit....that's like going back to the days of DOS ! It's puny...the size.

    Compiles fine. Runs fine.

    Tonite:

    operation 1: CodeClean, Save and Close, Reopen and Repair.
    Result: workbook cannot be saved. Just hangs and hangs upon save.

    operation 2: CodeClean, Save and Close, Open normally.
    Result: saves fine, compiles fine, no problems.
    However, upon exiting Excel, Excel crashes "Excel has stopped working"
    APPCRASH, VBE7.DLL
    Workbook is saved however.

    Very strange indeed.

    Wait - could Repair be causing some VBA problems ? Since the crash is totally VBE related, I don't think it's a front-end calc problem....so turning off AutomaticCalc is not likely to do anything.

    My sense now is that CodeCleaner as written is not a good workaround. Somehow, the P-Code corruption is not being removed.
    The best one appears to be: export VBA, Delete all VBA-related modules, Save and Close, Reopen, Import VBA, recompile. This mimics a "/decompile" directive in Access.

    This is now apparent: I need to modify CodeCleaner to have an option to delete the VBE modules....that's the best solution for now. It's really interesting to see how the XLSM file size goes from 1804kb to 2029kb. The former is after Code Cleaner and repair (which does not work !).

    Here is the whole error message when Excel crashes after closing:
    Problem signature:
      Problem Event Name:    APPCRASH
      Application Name:    EXCEL.EXE
      Application Version:    14.0.6112.5000
      Application Timestamp:    4e9b2bb3
      Fault Module Name:    VBE7.DLL
      Fault Module Version:    7.0.16.25
      Fault Module Timestamp:    4e49ae34
      Exception Code:    c0000005
      Exception Offset:    00168f80
      OS Version:    6.1.7601.2.1.0.256.1
      Locale ID:    1033

    Additional information about the problem:
      LCID:    1033
      skulcid:    1033

    Read our privacy statement online:
      http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

    If the online privacy statement is not available, please read our privacy statement offline:
      C:\Windows\system32\en-US\erofflps.txt


    • Edited by Syswizard Sunday, January 01, 2012 12:15 AM
    Sunday, January 01, 2012 12:09 AM
  • "Largest BAS file is 191k, the next is 85k."

    There's the problem right there. I don't know why the limit is 64K or why it relates to source code size rather than pCode size, or what, but that's my experience. Don't try to figure out why, just do it. If anyone at MS cares to give us the real story, please do.

    I recommend you break every module into 1000 lines or less, that should give you 50K module sizes, enough to allow room for expansion when editing. If the code used module variables or private subs you might need to choose location carefully, but I don't get the impression the original coder would have known that.

    That still leaves possibilities 2-8 of my list above but definitely do #1 first and report back when done.

     

     

    Sunday, January 01, 2012 6:40 PM
  • "Largest BAS file is 191k, the next is 85k."

    There's the problem right there


    Definitely not that. Had the same module during an Excel 2007 development.....never had a problem with VBE....hundreds of editing sessions. Never even touched CodeCleaner either.

     

    Monday, January 02, 2012 12:56 AM
  • See page 43 of "Professional Excel Development" Bovey et al, or google for "VBA has an undocumented soft limit on the maximum size of any single standard code module."

    A single standard code module should not exceed 64KB as measured by its text file size when exported from the project.[...] consistently exceeding this limit will almost invariably lead to an unstable application.

    http://dmcritchie.mvps.org/excel/slowresp.htm#vbe

     

     

    Monday, January 02, 2012 10:12 AM
  • Thanks for that.....but the thread is dated back to 2003....almost 9 years ago !

    Largest module is 6500 lines of code.
    However, since my last export, delete, import, and re-reference using VBA and a fixed set of External file locations, things have stablized.

    It's a possibility I had some bad references....as strangely there were several "VBA For Applications" versions installed on my 2010 machine. I am now picking up the correct one in the Common Files folder.

    Will keep posting if further corruption problems surface.

    Monday, January 02, 2012 3:58 PM
  • Got burnt today on this one....lost all front-end changes to formulas after 2 hours of work.

    Please, please....SP2 is badly needed.

    Thursday, February 23, 2012 2:11 AM
  • Excel 2010 workbook (XLSM) went from 4MB to 3MB after an "open and repair" was performed.

    Why ? What happened to the 1 MB of "stuff" in there ?

    Friday, February 24, 2012 3:17 PM
  • AN UPDATE :

    There apparently was a 2/14/2012 KB update for Office 2010.
    This appears to have resolved the VBA crashing and corruption issues.

    However, I am quite upset there was no minor version change for this fix.
    The current release is STILL 14.0.6112.5000

    Tuesday, February 28, 2012 6:18 PM
  • Spoke too early. Now it's happening DAILY....what a hassle !!!

    Please, oh please can we have Office 2010 Service Pack 2.....

    Tuesday, March 27, 2012 6:25 PM
  • Is there any update? I have the same problems... :(

    I think that this problem is very important and should be solved very quickly!

    Monday, July 16, 2012 8:17 AM
  • Well, I have another tip:

    Don't define event methods outside the Worksheet classes.

    That solved a few "Excel stopped running" errors for me.

    Tuesday, October 02, 2012 7:23 AM
  • What on earth are you talking about ?

    Event Handlers are BUILT INTO the worksheet classes.

    Tuesday, October 02, 2012 1:01 PM
  • Sorry!

    I meant something like this:

    Dim WithEvents WS As Worksheet

    Thursday, October 04, 2012 8:30 AM
  • I am just curious - does the 64Kb limit also apply to forms?

    I have a similar problem to the OP - Excel is very unstable and sporadically crashes when loading forms in VBA. My largest BAS file is 36Kb but my largest FRX is 141Kb - is this likely to be contributing to the instability? I'm loathe to split the form, although it would be possible I guess...

    MS really need to sort this problem. The longer it has been affecting me, the more i've seen evidence of others in the same situation.

    Thursday, October 11, 2012 10:48 PM
  • Another one with the error checking in....

    Whilst it's unlikely we're all talking about the same problem, a lot of what is said here sounds familiar.

    I have a pretty large (larger than perhaps ideal, though at this stage I need Excel's power on a few tabs with 500k+rows of data).

    On each 'save' of this working file, I have written a macro such that it saves a copy of each file for version control ( so i can trace each incremental file movement, and usually trap any error). 

    Though the error as described transcends this 'usual' error trapping method. A workbook can get 'bork'ed that the will 'bork' every proceeding workbook - not dissimilar in operation to a kind of virus, though of course the problem is not viral. I then proceed to take the now all too regular remedial action - Open>Open and Repair>Extract Data>As formulas>

    Unhide and Copy all sheets manually to new workbook

    Copy all macros and Sheet/Workbook macros manual via Vba editor>

    Spend the next 20 minutes lamenting this new error whilst you resize all the columns, hide the sheets etc>

    Live in fear of the random Freeze of Death until the day happens (can be hours, can be weeks)....And so on)

    One thing that's been referenced elsewhere, is that the recovered workbooks (once the Workbook Data is recovered) Have duplicated ThisWorkbook and Sheet Objects in the VBAProject explorer window. I'd be quite sure this has something do with the problem (though I am no expert, and this could just be mere notification to a dev).

    To be direct, $250 is nothing (to my company) if I could be confident this could be fixed (it has lost me days of lost productivity this past month). It doesn't feel entirely professional that such a service should exist though.

    For the record, also, here is the error text:

    Problem signature:
      Problem Event Name: APPCRASH
      Application Name: EXCEL.EXE
      Application Version: 14.0.6126.5003
      Application Timestamp: 505b0843
      Fault Module Name: VBE7.DLL
      Fault Module Version: 7.0.16.27
      Fault Module Timestamp: 4f863856
      Exception Code: c0000005
      Exception Offset: 00000000000ca81b
      OS Version: 6.1.7601.2.1.0.256.48
      Locale ID: 2057

    Additional information about the problem:
      LCID: 1033
      skulcid: 1033

    Read our privacy statement online:
      http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

    If the online privacy statement is not available, please read our privacy statement offline:
      C:\Windows\system32\en-US\erofflps.txt

    Wednesday, December 12, 2012 12:40 PM
  • Quite a hassle for sure. Have you tried moving to the XLSB format (vs. XLSM) ?

    Also re: "copy all macros...": get the CodeCleaner addin (free) to automate that step.

    http://www.appspro.com/Utilities/CodeCleaner.htm

    Wednesday, December 12, 2012 1:52 PM
  • All my workbooks are XLSB (always have/will be)...Tried to install that code cleaner though not sure if it's a non 64/XL2010 bit add in (as I run 64bit/2010 XL) as it won't install via the trust centre (even with all the restrictions removed) ...."Is not a valid Office Add-in"
    Wednesday, December 12, 2012 3:47 PM
  • All my workbooks are XLSB (always have/will be)...Tried to install that code cleaner though not sure if it's a non 64/XL2010 bit add in (as I run 64bit/2010 XL) as it won't install via the trust centre (even with all the restrictions removed) ...."Is not a valid Office Add-in"

    I don't believe they created a 64 bit version. Using VB6, I don't think they could have done it; a port to VB.NET would have been required.
    Wednesday, December 12, 2012 3:59 PM
  • Anyone with an update or proposed soluttion? It's getting tiring repairing etc a workbook every day!
    Wednesday, December 19, 2012 6:35 PM
  • Anyone with an update or proposed soluttion? It's getting tiring repairing etc a workbook every day!

    Call Steve Balmer.

    I've been waiting for Office 2010 SP2 .....for months now. Appears it ain't happening due to the roll-out of Excel 2013.

    BTW: Have you determined the size of each of your VBA code Modules ? I've heard that splitting up the code into multiple, smaller modules is a potential solution. Something about a ridiculous 65k code size limit or something...which is crazy in this day and age. 65 Megs would be more like it as a limit.

    Thursday, December 20, 2012 4:18 PM
  • Anyone with an update or proposed solution? It's getting tiring repairing etc a workbook every day!

    Basically, unless you want to reconstruct that workbook from scratch, import all of the VBA, reconstruct all of the range names, etc. , you must OPEN AND REPAIR each time you want to use this workbook.

    Once it becomes instable to the point where you get "Document Not Saved", you are finished. It will stay corrupted...forever. One solution is to move it to an XLSB format. But then: no Ribbon changes are possible.

    Bottomline: It appears one of the XML parts inside the XLSM/XLAM is prone to corruption when a lot of VBA code is stored.

    Friday, December 21, 2012 3:04 PM
  • Hi,

    I fixed it simply by replacing the VBE7.dll with a new updated VBE7.dll.

    C:\Program Files\Common Files\Microsoft Shared\VBA\VBA7

    Regards,

    Syed Mujtaba Ahmed Razvi

    Wednesday, August 21, 2013 9:24 AM