Application crash without error

[surfdabbler]

I have a problem where my application just occasionally disappears with no error. One minute it's running fine, next minute, the app just disppears. Of course, it doesn't happen in my development environment, only on the occasional production machine. It's also not repeatable - you can restart the app, and do the same thing, and it will be fine. 5 minutes later, doing something else, it will vanish again.

I'm familiar enough with memory access errors, where you get an OS error about invalid access, but what can cause the app to just vanish?

Is something like boundschecker likely to find this sort of error, even if it doesn't crash like this in the dev environment? If it does find it, it's worth buying it, for sure!

My app is a Visual C++ 2005 MFC app, with lots of OpenGL graphics code. My distribution includes mfc80.dll and msvcr80.dll, as well as the associated manifest files. If DLL mixup is a potential issue, are there any other DLLs that might be relevant?

[Lindley]

Well, IMO valgrind is the holy grail of runtime-behavior verification, but that's not much help on Windows. I've heard BoundsChecker is all right; you definitely want something along those lines, anyway.

When bugs aren't repeatable, it's often either due to use of random numbers, or multithreading errors.

[najet]

May be you can use try catch at top level, and log the type of exception in catch (may be in some kind of log file.)
I have used it at times, its helpful.

[surfdabbler]

Multi-threading errors is certainly a possibility. My app doesn't make use of a lot of this, but there are certainly timers and graphics code that have given muti-threaded errors in the past, relating to synchronising the real-time display with the background calculations. I have used critical sections in a lot of my code, but I wonder if some of the graphics code on the graphics card, such as vertex arrays/VBOs, might be independent of this, and possibly still having issues there?

[surfdabbler]

May be you can use try catch at top level, and log the type of exception in catch (may be in some kind of log file.)
I have used it at times, its helpful.

Where would this be done in a windows app? It is all MFC message driven, so the 'top level' is outside my application code, right?

[UnderDog]

As a first step you should try capturing a crash dump for such 'random app crashes in production'. Dr Watson can help you get a crash dump. If you can get the crash dump, then you can at least point out where and why the program crashed.

If that is not possible, then I would look at log files, if I have sufficient logs, to see what the software was doing just before the crash. That helps narrow down the piece of code where the crash is happening and possibly by reading through the code one can find the source of the error.

If that fails, then I would try to repro it in my dev machine, where hopefully my dev tools (debugger) would catch the location of error when the crash happens.

Finding the location of the crash is one thing; with many such crashes the root cause of the error is somewhere else. e.g. a NULL pointer may not cause a crash at the point where the pointer is made null, but may be somewhere else. So then it is a bit of detective work to find the root cause. If you can catch it in debugger, then at times the call stack trace would give you sufficient information.

[Paul McKenzie]

I'm familiar enough with memory access errors, where you get an OS error about invalid access, but what can cause the app to just vanish?

Unhandled exception.

Why not compile a release version, and under the debugger, just let it run? If the production machine has a way to communicate to with via TCP/IP, you can even debug it remotely from your development machine.

Regards,

Paul McKenzie

[surfdabbler]

Unhandled exception..

Hi Paul, OK, I thought the OS would display some sort of catch-all message for any system exceptions, but evidently not. Is there a way to add a catch-all message to an MFC application, or would I have to add this to every message handler in my application?

Why not compile a release version, and under the debugger, just let it run? If the production machine has a way to communicate to with via TCP/IP, you can even debug it remotely from your development machine.

Your "release build under the debugger" suggestion is good, and I've done this, but the error just doesn't happen. These errors only happen on a release build, and only happen when not running the debugger, and they only happen on a small subset of customer machines.

As for trace logging on production machines, I'm afraid it's not possible, due to performance issues, and it's mostly running on laptops. Think of my program as a simulation game. It's not a game, but it's reasonably similar in how it's written and what it does. Once again, tracing will simply stop the problem from happening.

My code is Osama Bug-Laden. I know the bug is there, but as soon as I do anything to look for it, it disappears.

I'm currently going through and adding critical section protection to a lot more places in the code - I am thinking this is likely the issue.

[JohnCz]

Have you ever considered scanning culprit machine with some virus detection tool?
I had a problem that sounds like yours and it was a virus that caused this behavior.
If it turns it is not a virus, you will know that something weird is going on and is caused by a code. Then consider using SetUnhandledExceptionFilter API.

[Paul McKenzie]

Your "release build under the debugger" suggestion is good, and I've done this, but the error just doesn't happen. These errors only happen on a release build, and only happen when not running the debugger, and they only happen on a small subset of customer machines.

Run your program normally, and then attach to it with the debugger ("Attach to Process"). Have you tried that?

This way, you're starting the program normally (not under the debugger), and then you're attaching to it while it's running.

Regards,

Paul McKenzie

[Tivoilos]

To do the log file just use fstream and save the file like

log.txt and everytime you want to log a funciton or a thing that is going on in your program it would be something like

log << "Programing Doing something"

then when or if your program crashes you look at your log and if one of your logs is missing thats where the program is crashing at(most of the time, do not quote me programs can do some odd things sometimes)

but that is how I do it anyway.