I'm building a document-level VSTO customization for an Excel 2016 workbook, and I'm encountering this error repeatedly in the development process. Basically, Visual Studio 2015 builds the project, Excel loads the workbook, and immediately Excel displays an "Automation Error / Catastrophic Failure" message. It kicks me into the VBA editor, but there's no code on the screen to edit.
I read in a few places that the error means there is something wrong with the "References" settings in the VBE, but it won't let me open that screen, the option is grayed out. Anything else I try to do just pulls that error up again. The only way out is to stop the process through Visual Studio. If I open the source workbook directly from the project folder, the same problem occurs, and I have to quit Excel via Task Manager.
This problem has been coming and going over the past 24 hours; last night and this morning it wasn't happening for some reason, so I was having no issues running and testing my project, but now the problem is back. If anyone has an idea of what could be causing this problem (bearing in mind it must be something that has not been constant over the past day), I'm all ears. Even just an idea of what to look for would be helpful, as I don't even know what this error means or what kinds of things to look for. This is my first VSTO project and I've been pretty excited by what I was able to accomplish when this error wasn't coming up every time, so I'd like to eliminate the problem permanently.
Edit: I should point out that the reason I included VSTO in the question title is that this workbook was totally fine before I started the VSTO project. But I saw this error when I tried to run the VSTO project for the first time, yesterday.
So, I think I "kinda-sorta" figured out my own problem. I'm still not 100% sure what caused it in the first place, but I'll leave this here for anyone else who runs into the same issue someday:
When you get this error, don't despair like I did because the VBE window has no code highlighted as the problem area. Look through ALL the VBA code in every object/module/sheet; in my case, I eventually found a function highlighted as the cause of the problem. I was able to bypass the error temporarily by turning off automatic calculations, and I commented out the offending function. It broke some things in my workbook to do so, but it gave me the opportunity to debug my VB.net code in Visual Studio, and when I uncommented the "problem" VBA function after doing so, it all worked perfectly fine.
Related
Short Question:
How do you debug a large Global.MPT file?
Currently my script crashes when I try to open it from the toolbar. It appears the usual, not very helpful, error message regarding the automation error. When this happens I start the individual components by pressing F5 in the VBA window and at the latest then I find the erroneous line.
Now my code runs as it should but I can't find the error that the compiler* has.
How do you deal with this problem?
*Is it a compiler error?
Found a Solution here.
I didn't know that you can compile the code manually.
It showed that i missed to remove a call for a deleted Sub.
I have a button click event in an Access form that sometimes opens the VBA editor with the 'On Error...' line highlighted as if it is in debug mode. I can F5 to continue the rest of the procedure and it works fine.
It doesn't happen everytime. It seems random except there seems to be a pattern that it happens on the first click of this button right after the file is opened. Not everytime though.
Any thoughts on this or previous experience with the same thing happening and subsequent solution? What might be causing this? It's a terrible user experience.
Well, before running any code (hold down shift key during startup to prevent any code from running).
Now, ctrl-g (jump to VBA IDE). Now from tools. Choose
debug->Clear all Breakpoints
Like this:
Now, open up any code module - hit enter key to "dirty" the code. Now choose debug->Compile (first menu option). It will say Compile "my app name".
Make sure the code compiles. If it does not, then stray break points can still exist.
Next up, you need to check/change the default behavior for a error.
While STILL in VBA editor/IDE
From menu bar choose tools->options. The default is "Break on Unhandled errors"
If you have break on ALL Errors? Well then code that even assumed to trap or even on-error resume next code it BLOW UP and stop. Often developers will say try for existence in a collection, and we error tap to "mean" the element is not in that list. However, the THIS assumes that the default Error trapping setting was not change.
So, double, and then triple check this setting. You can develop for years, and even have some code ASSUME to error out. But that years of development code assumed the default (break on unhandled Errors. If you have break on all errors, then your are toast, and you find all kinds of breaking of code. (the idea of that option is to LET you debug code with error handling without having to disable errors. And with say on-error resume next, you in effect can't debug parts of code anymore.
Now, if above steps don't fix your issues?
Then the next step is to de-compile your application. This will remove the compiled (binary) part of the application. Once you do this, then you do a full re-compile.
To de-compile, you can't do this from the IDE, and you have to use a FULL qualified path to your existing version of access. Say like this:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE"
"c:\MyCoolApp\Invoice.accDB" /decompile
Now, when you run above, you REALLY must not let any startup forms or code run. (hold down shift key. Now exit access/application. Now re-launch (and again no code to run on startup).
Now, at this point I high recommend a Compact+ Repair (and AGAIN no startup or code to run). So even on the C+R, you have to hold down shift key.
If you during the decomp, start application, then C+R allow ANY code to run, then you have to start over again at the first decompile step.
Ok, now you done the C+R. Now ctrl-g, and now debug-compile.
Apologies if this question is a little vague - but I am struggling to find relevant information on the 'Automation Error - Catastrophic Failure' I am experiencing.
The code I have written is set to run when the workbook is open. The code appears so run as intended, with no errors. I have stepped through the code and checked it and I can't see any obvious problems or anything that is not behaving as it should.
The 'Automation Error - Catastrophic Failure' only occurs when I click the Visual Basic Editor on the excel tool bar.
The section of code is quite long so its not really feasible to paste it here, but I only get the error once when opening the editor, and then it does't appear again.
I'm not even sure where to start in debugging this or what this error exactly means in this instance?
Any input would be greatly appreciated!
I’ve run into an issue with a couple of workbooks where the message “Can’t find library or project.”. However, when I open the VBA window to check the references, it’s non responsive (as in I can click things, but no menus appear, the project window displays the desktop, and Active X controls are non responsive).
I’m in Excel 2013. Is it possible that if the file was created in 2010 and brought over there could be issues? I’m acratching my head as this seems to happen completly at random.
Thanks guys. I managed to open the file in Safe Mode, and tried compiling the code. I believe that there was an error in the Workbook Open code that it may have been corrupting on. I deleted this, and it seems to be all good
I am trying to develop a little macro for PowerPoint using VBA. However, the "Development Environment" is an absolute nightmare!
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there! So I am currently using MsgBox to generate debug messages. :-(
What's also really bad is, that errors in a macro always crash PPT. So one has to wait, until it is gone and then one has to restart it again and get rid of all the Recovery attempts. This always takes ages!
If I set On Error Resume Next it doesn't crash - at least not as often - but then things just silently don't work and I can't see what and why things go wrong (unless I plaster the code with MsgBox calls, but that requires 100'000 clicks during each execution).
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode. So this debugging is driving me nuts!
Is this really the only possibility or environment to develop VBA code in? At least some idea re. debug output, anyone?
M.
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there!
At the risk of sounding insulting (which I don't intend!) do you have the Immediate window open? While in the IDE, press Ctrl+G to see if anything new appears. If so, that's the Immediate window.
What's also really bad is, that errors in a macro always crash PPT.
Not ordinarily, no. It can happen that way, of course; your code might be triggering a bug in PPT. Heaven knows, I ran into enough of that in PPT 2002 and 2007. If you're using reasonable error handling and still running into errors that crash PPT, stepping through the code as it runs should allow you at least to narrow it down to the line or two that cause the crash.
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode.
Again, no. The ActivePresentation refers to whatever presentation has focus in the app, whether it's in slide show or any other view. If your code's in one presentation and its' supposed to be acting on another, that can cause some confusion, but you simply need to switch to normal view, make sure the presentation you want to access is visible (I'd make sure not to have several in view) then Alt+F11 to return to the IDE and run your code.
All of these suggestions apply to any Windows version of PPT, going back to Office 97 (Mac? Thinks different. If you're using a Mac, mention that. There are a few differences but for the most part, everything above applies except for the Alt+F11).
If none of this seems to help on your setup, it may be time to do a repair of Office.