I'm running MS Office 2010 on Windows 7 Professional.
I’ve been experiencing this problem periodically for the last month or so, not all the time, but probably once or twice a week.
I’m working on the VBA portion of a fairly complex workbook. I start the day by making a copy of the previous day’s workbook, and make any subsequent code changes on the copy. When I’m finished I’ll run VBA Code Cleaner, do a Debug, Save then exit Excel. I also save a backup copy. I’ll then reopen & close both of these workbooks a number of times just to satisfy myself that everything is still working.
The next day I’ll wake the computer and try to open these files, and as soon as the VBA code starts to run I’ll get the “Microsoft Excel has stopped working” message. This can happen to either the main file or the backup file, and sometimes both.
If I open the bad file with the shift key down, I can get into the VBE area OK, but when I do a Debug or try to run VBA Code Cleaner I get the same message.
The only way I’ve found to recover from this is to:
Manually export the code
Save the file as an xlsx file, thus expunging all the code.
Save the xlsx file as a new xlsm/xlsb file, and then import the exported code.
I just today found another way to recover is to save the file as “xls”, then re-save as xlsb/xlsm, that somehow seems to “clean” something.
After the recovery everything is fine again, at least for a few days.
What I’ve tried so far:
Searched the internet, including StackOverflow, for possible solution.
Run various virus checkers (MS Essentials, Malwarebytes, SuperAntiSpyware)
Repaired MS Office 2010.
Uninstalled and re-installed MS Office 2010
Removed all add-ins
Uninstalled Dropbox
Started using a new user profile.
I came across several articles that suggested xlsb files were prone to corruption, so I started saving as xlsm files. Everything went well for about a week, and I thought I’d resolved the problem. However, it’s now started happening with the xlsm files too, so I’m back to square one.
I’m running out of ideas - the next thing I might try would be re-installing Windows 7, but I really hope to avoid doing that! I would really appreciate any suggestions. Thanks.
Well, I believe I may have found my problem. I noticed that one of my class objects wasn't always terminating correctly, due to it being referenced in a different class. I fixed that, and now it's been 11 days without any problem (touch wood). So I'm reasonably confident that this was the root cause. But I must admit I'm still not quite sure why this occasionally corrupted the workbook.
In my company I'm using Excel 2013 64bit and many xlsm files with some macros that use basic build in libraries. Occasionally I encounter a random "microsoft excel has stopped working" (- mostly on opening a file but last week it happened while I was just staring at the screen). 95% of the times making a copy of the file, so that excel would not see it as trusted, going to vba editor and compiling vba project manually and saving it would fix the problem, however it recently got simply annoing as frequency of those crashes went from 1/week to several per day. I think I waste like 30 minutes daily just on fixing crashed files. So generally I know what to do when excel crash happens but I would like to know if there's something that can be done to prevent them from happening in the first place.
Also the crashed files work flawlessly on a machine with excel 2010 on it. Saving the file with E2010 also fixes the problem for E2013
64 bit Office has a lot of problems with VB code. These seem to be related to the pcode that get's generated when the code is compiled and so recompiling seems to fix them. There's a registry fix to force recompile, you need to set these two values:
HKEY_CURRENT_USER\Software\Microsoft\VBA\7.0\Common
Type: DWORD
Name: CompileOnDemand
Value: 0
and:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Options\
Type: DWORD
Name: ForceVBALoadFromSource
Value: 1
These two fixed it for me.
I have several Excel 2007 VBA solutions which have been running fine for years. In mid-December 2018 I got a new computer and installed Office 2007 and all was fine until about three days ago, when as soon as I tried to run a solution or enter the VBA or macro section under the developer tab, I get a message "Unable to load VBE6EXT.OLB", and then a message saying "Out of memory", but the Excel (non-VBA) part continues to function. I have tried every "solution" I found on the web, including uninstalling and reinstalling Office, checking the register for entries said be necessary (they were there - no problem), copying said file from its location in Program Files (x86) to same location in Program Files, checking that Office executables are all running under Windows 7 compatibility, and maybe more that I can't remember. Has anyone encountered this issue? I can't think of anything else to try!
I'm having an issue with tool I developed in excel for one of our offices. It is a big enough file with couple of macros in it, but it works smooth day to day.
However every few days file will through error 'Can't find project or library' and file will crash. I know the standard guides are that when this error appears, it is to go to vba>tools>referneces and uncheck the missing library, however this is not the case in here. Simply when this happens file crashes and restarts and if it will happen once, every other attempt to open back the file will result in same error in crash. I mean file can be absolutely fine, you will save it, go back to it and error happens. So I always have to recover the file which absolutely destroys it, however I can at least recover from it information uploaded there by the users and copy it into the template.
So 2 questions I have is what is causing this to happen? Both myself and the other office are using the same version of excel so compatibility should not be an issue.
2 questions is is there anything that can be done to prevent this error from happening.
I have exactly this problem. As stated, once the error occurs, it it results in a permanent "unfixable" loop. I use powerquery and linked data and this appears to randomly "damage" the file as described - most frequently when excel crashes for some reason.
I have found either of the following to work:
- Open the file on a different computer that is not on the LAN. This
appears to be a key requirement.
- Open the file with "Excel Online"
In each case, simply open the file and save it with a new name. Move the new file back to the work PC and it will once more open perfectly.
On rare occasions (if powerquery is in use), it is necessary to "refresh all" data connections before saving the new file.
As a bonus, the new file is often smaller than the original.
This worked for me:
In VB go to Tools » References
1) Uncheck the library "Crystal Analysis Common Controls 1.0". Or any library.
Just leave these 5 references:
1) Visual Basic For Applications (This is the library that defines the VBA language.)
2) Microsoft Excel Object Library (This defines all of the elements of Excel.)
3) OLE Automation (This specifies the types for linking and embedding documents and for automation of other applications and the "plumbing" of the COM system that Excel uses to communicate with the outside world.)
4) Microsoft Office (This defines things that are common to all Office programs such as Command Bars and Command Bar controls.)
5) Microsoft Forms 2.0 This is required if you are using a User Form. This library defines things like the user form and the controls that you can place on a form.
Then Save.
I've had similar nasty issues.
First thing to do is use the CodeCleaner a free utility from AppsPro
This will export your modules and then re-import them, because internally they get a lot of binary "lint" which can cause problem.
Second thing to suggest is start breaking up your code base. So start removing modules to see which module is the offender. Horrible I know but how can you tell otherwise where the problem is.
Third suggestion is to always fully qualify your functions. So instead of Len(sMyString) write VBA.Len(sMyString) that helps prevent false negative compile errors.
From what I can see on the web, this is a fairly common complaint, but answers seem to be rarer. The problem is this:
We have a number of Excel VBA apps which work perfectly on a number of users' machines. However on one machine they stop on certain lines of code. It is always the same lines, but those lines seem to have nothing in common with one another.
If you press F5 (run) after the halt, the app continues, so it's almost like a break point has been added. We've tried selecting 'remove all breaks' from the menu and even adding a break and removing it again.
We've had this issue with single apps before and we've 'bodged' it by cutting code out of modules, compiling and then pasting it back in etc.
The problem now seems to relate to Excel itself rather than a single .xls, so we're a little unsure how to manage this.
Any help would be gratefully received :)
Thanks,
Philip Whittington
I have found a 2nd solution.
Press "Debug" button in the popup.
Press Ctrl+Pause|Break twice.
Hit the play button to continue.
Save the file after completion.
One solution is here:
The solution for this problem is to add the line of code
“Application.EnableCancelKey = xlDisabled” in the first line of your
macro.. This will fix the problem and you will be able to execute the macro
successfully without getting the error message “Code execution has been interrupted”.
But, after I inserted this line of code, I was not able to use Ctrl+Break any more. So it works but not greatly.
This problem comes from a strange quirk within Office/Windows.
After developing the same piece of VBA code and running it hundreds of times (literally) over the last couple days I ran into this problem just now. The only thing that has been different is that just prior to experiencing this perplexing problem I accidentally ended the execution of the VBA code with an unorthodox method.
I cleaned out all temp files, rebooted, etc... When I ran the code again after all of this I still got the issue - before I entered the first loop. It makes sense that "press "Debug" button in the popup, then press twice [Ctrl+Break] and after this can continue without stops" because something in the combination of Office/Windows has not released the execution. It is stuck.
The redundant Ctrl+Break action probably resolves the lingering execution.
I found hitting ctrl+break while the macro wasn't running fixed the problem.
I would try the usual remedial things:
- Run Rob Bovey's VBA Code Cleaner on your VBA Code
- remove all addins on the users PC, particularly COM and .NET addins
- Delete all the users .EXD files (MSoft Update incompatibilities)
- Run Excel Detect & Repair on the users system
- check the size of the user's .xlb file (should be 20-30K)
- Reboot then delete all the users Temp files
I have came across this issue few times during the development of one complex Excel VBA app. Sometimes Excel started to break VBA object quite randomly. And the only remedy was to reboot machine. After reboot, Excel usually started to act normally.
Soon I have found out that possible solution to this issue is to hit CTRL+Break once when macro is NOT running. Maybe this can help to you too.
Thanks to everyone for their input. This problem got solved by choosing REPAIR in Control Panel. I guess this explicitly re-registers some of Office's native COM components and does stuff that REINSTALL doesn't. I expect the latter just goes through a checklist and sometimes accepts what's there if it's already installed, maybe. I then had a separate issue with registering my own .NET dll for COM interop on the user's machine (despite this also working on other machines) though I think this was my error rather than Microsoft. Thanks again, I really appreciate it.
I have had this problem also using excel 2007 with a foobar.xlsm (macro enabled ) workbook which would get the "Code execution has been interrupted" by simply trying to close the workbook on the red X in the right corner with no macros running at all, or any "initialize" form, workbook, or workheet macros either. The options I got were "End" or "Continue", Debug was always greyed out. I did as a previous poster suggested Control Panel->Programs and Features-> right click "Microsoft Office Proffesional 2007" (in my case) ->change->repair.
This resolved the problem for me.
I might add this happened soon after a MS update and I also found an addin in Excel called "Team Foundation" from Microsoft which I certainly didnt install voluntarily
I would like to add more details to Stan's answer #2 for below reasons:
I faced this issue myself more than dozen times and depending on project conditions, I chose between stan's voodoo magic answer #1 or #2. When I kept on facing it again, I become more inquistive that why it happens in first place.
I'd like to add answer for Mac users too.
There are limitations with both these possible answers:
if the code is protected (and you don't know password) then answer #1 won't help.
if the code is unprotected then answer #2 won't let you debug the code.
It may happen due to any of the below reasons:
Operating system not allocating system resources to the Excel process. (Solution: One needs to just start the operating system - success rate is very low but has known to work many times)
P-code is the intermediate code that was used in Visual Basic (before .NET) and hence it is still used in the VBA. It enabled a more compact executable at the expense of slower execution. Why I am talking about p-code? Because it gets corrupted sometimes between multiple executions and large files or just due to installation of the software (Excel) went corrupt somewhere. When p-code corrupts. the code execution keeps getting interrupted. Solution: In these cases, it is assumed that your code has started to corrupt and chances in future are that your Excel workbook also get corrupt giving you messages like "excel file corrupted and cannot be opened". Hence, as a quick solution, you can rely on answer #1 or answer #2 as per your requirements. However, never ignore the signs of corruption. It's better to copy your code modules in notepad, delete the modules, save & close the workbook, close the excel. Now, re-open the workbook and start creating new modules with the code copied earlier to notepad.
Mac users, try any of the below option and of them will definitely work depending on your system architecture i.e. OS and Office version
Ctrl + Pause
Ctrl + ScrLk
Esc + Esc (Press twice consecutively)
You will be put into break mode using the above key combinations as the macro suspends execution immediately finishing the current task. This is replacement of Step 2.
Solution: To overcome the limitation of using answer #1 and answer #2, I use xlErrorHandler along with Resume statement in the Error Handler if the error code is 18. Then, the interrupt is sent to the running procedure as an error, trappable by an error handler set up with an On Error GoTo statement. The trappable error code is 18. The current procedure is interrupted, and the user can debug or end the procedure. Microsoft gives caution that do not use this if your error handler has resume statement else your error handler always returns to the same statement. That's exactly we want in unwanted meaningless interruptions of code execution.
My current reputation does not yet allow to post this as a comment.
Stans solution to enter the debug mode, press twice Ctrl+Break, play on, save did solve my problem, but I have two unexpected twists:
My project struture is password protected, so in order to get into the Debug Mode I had to first enter Developer mode, click on the project structure and enter the password.
My project is a template file (.xmtl). I opened the file via double click which opens it as .xml with a "1" at the end of the previous file name. I fixed the bug as by Stans instruction and saved it as that ...1.xml file. When I then opened the template again, this time as template, and wanted to apply the same bug fix to that file, the bug was gone! I did not change this file and still no bug at executing the Macro. This means to me that the bug is not actually in the file, but in a (hidden) setting in Excel.
If it's a phantom breakpoint:
1 Delete the offending line of code
2 Run the code again
3 Repaste the line
I found this laughably simple solution after spending a couple days wading through all the answers here and elsewhere. I figured, if I link it to my original question it might help some other poor chap, since the question it's on is VBA break execution when there's no break key on keyboard and this is more applicable.
Link to original answer
I faced the same issue today. Resolved it with these steps.
Create a new module
Move the procedure that is causing the issue to this new module.
Save project
Run macro again.
This time, the code execution will run till completion without any intermediate stops.