Preventing VO program 'quits'

[ic2]

Sometimes a VO based program fully quits without any error or obvious cause. In the past a common reason could be some damaged index or DBF.
I recently found an entry right after such a 'quit' in the Windows Application Event Log with the first line showing my VO exe as Faulty application Name and the 2nd line Faulting module name being the DLL of my PDF Viewer. My program opened a window which can show a preview of a PDF using OLE and apparently something went wrong there (without an obvious reason, it probably worked with the same PDF after a restart like it did with 100's of other previewed PDF's). Of course, the Event log did not show any useful information.It looks like the PDF viewer caused the problem but even that is not sure.

Now my question is: is there any way to prevent such a 'quit crash'? I assume that if I enclose a VO error handler around the postinit of the preview window this won't help?

(otherwise my program wide general error handler would have kicked in instead I'd say)

Dick

[Chris]

Hi Dick,

Best way to be sure about this, is to start another process, so if that crashes, your main app will not. For example, you can create another exe for viewing the pdfs, and call that from your main app.

[ic2]

Hello Chris,

That is probably a good idea (depending how often it happens, fortunately it has been pretty rare).

I've done the same in an X# solution where I implemented a BusyIndicator from Syncfusion (this is C# code). No matter what I tried, Async taks etc, the indicator always started when the task it was supposed to support with a delightful graphical scene was finally finished...

Now I just start it as a separate .exe and that works fine. Although one would expect that the more sophisticated .Net options would actually work.

Dick

[Chris]

Hi Dick,

It should work, but needs the correct way to do it, which is admittedly often not obvious. If you show us some code we might be able to help.

[ArneOrtlinghaus]

In my opinion there is no way to prevent a program from quitting if it want's to quit. There are so many reasons where the error handler is not able to return the program into a stable situation. And this happens often with 3rd party-tools as it is for Crystal Reports in our case. For example pointer operations accessing forbidden areas in the memory result in those hard quits. Fortunately the current operation systems reach to stop the single program without stopping Windows completely.

I would also say that in this case calling a separate program for the PDFViewer can help make the main program stable.

Arne