Debugging Options when Excel Crashes

[Isaac]

Wondering if anyone who has had experience in this area can provide any guidance or insights on their experience or recommendations.

When Excel is running VBA code, (in this case the problem would have occurred either in a short Sub, or else in the userform's Activate event, both of which have error handlers with message boxes, etc), and it generates a "total crash" screen (pictured below), up to now I have zero experience in attempting to go past this point - debugging, etc.

Is it really possible? What tools are recommended or required? Any ideas?

 

[arnelgp]

i am experiencing same on access when editing the Query.
maybe it is caused by my recent Update of mso.

but it doesn't bother me.

 

[smtazulislam]

Check This link : its can help you :

Solved: Excel 2000 will not close after Visual Studio 2012 install | Experts Exchange

Find answers to Excel 2000 will not close after Visual Studio 2012 install from the expert community at Experts Exchange

www.experts-exchange.com

OR

Configuring Automatic Debugging - Win32 apps

Users can configure automatic debugging to help them determine why their system or an application has stopped responding.

docs.microsoft.com

 

[Isaac]

Thanks gentlemen. I will give it a try!

 

[AccessBlaster]

Hate this site, been lured here many times.

 

[Isaac]

I realized I actually HAD forgot to include an error handler in a particular routine. Strange, because while I know Access runtime apps will crash and burn on unhandled errors, I hadn't seen that in Excel

Adding the error handling, end-user was able to successfully generate an "Out of Memory" error, instead. Which prompted me to accuse an array size as the likely culprit, without really finding a definitive reason why it ought to be so. (He is on Excel 2010, nothing super old).

My end-user's Excel stopped erring or crashing when I reduced the sizing of an array (which I confess I had arbitrarily sized 'larger than I'd need', rather than taking the time to re-size it intelligently), from 10000 to 5000. He uses 2010, I use 365.

Might study up more on application debugging if "total crashes" happen more, but right now it's only been a handful of times in many years, so I will kick the can down the road for now.

 

[Guus2005]

Always good to put an error handler in *all* your events.
Because they are the starting point and endpoint of *all* the code you run in you application.
When there is an unhandled error it always bubbles up to the event which results in a runtime error or crash if the error is not taken care of.

So you are developing in Office 365. Perhaps you have a solution to the problem i just posted?

 

[Isaac]

Always good to put an error handler in *all* your events.
Because they are the starting point and endpoint of *all* the code you run in you application.

For sure - agreed. In this case it was forgetfulness on my part.