hello,

when a program like Firefox or Sketchup crashes we get a nice dialog saying what has happened. Some programs also give the option to send data from the crash to the developers.
How would I implement something like that for my own C++ app (on Windows)? Unfortunately I can not rely on exceptions because some of the libraries I use (eg Qt) don't use Exceptions.

Currently I have a program CrashHandler, which calls my main app in a new process. If my main app crashes, CrashHandler can detect it and inform the user.
However, when my main app crashes it brings up the standard Windows crash dialog alongside my own, which is confusing to the user. Is there a way around this? Or a better approach?

More importantly, how can I extract useful information from the crash to send to developers? On Linux I would use the GNU backtrace() method but I haven't found the equivalent on Windows.

cheers,
Richard

Why not simply write your programs so that they don't crash?

MxB

unfortunately even the best software teams release software with bugs. If you think you can, then either you haven't worked on a non-trivial project, or you are arrogant!

Read here:
http://www.codinghorror.com/blog/archives/001118.html


Anyone got any ideas?

However, you can check all return values. And if later you realize that exception handling is useful, you can still wrap wherever the library calls are made with try-catch blocks & handle the errors appropriately.

If you think that you "can't," you never will. Every winner is "arrogant," especially in the eyes of losers. If you never let failure become an acceptable option, you leave yourself no choice but to succeed. You may call that arrogant, I call it it determination. "There is no try, only do." Yoda.

I don't know why you think that a software team is "best" for releasing bugs, but you are welcomed to your opinion. However, if you keep telling yourself that "even the best software teams release software with bugs," someday you're going to believe it. The best software teams do not release bugs. Everybody else has done as much as they possibly can to promote the notion that they're still the best when they release buggy software. Maybe they did the best that they could given the situation and business case for the project, but that doesn't make them the best at anything.

Some software projects are not allowed to be released with bugs in them. Others are allowed by the businesses that release them. Some projects can't afford failures of any kind. Others believe that crashing a user's system is an acceptable risk and that minimizing that risk is useful for the business case when the cost of reducing that risk is acceptable to the business. Still other projects consider any crash of any kind to be unacceptable. I don't see how you get "best" from business cases that promote poor software quality.

The entire thinking that somehow exceptions (in C++) are some kind of programming elegance is foolhardy. They are very little more than interestingly applied goto statements. "That's not flying! That's falling with style." Woody.

I don't know which version of Qt you're using but:


...exceptions are enabled by default on my 4.5 commercial variety.

However, since you're asking for "ideas," I offer that you wrap your qapp.exec call in a C++ try block inside of your "main" code...even if exceptions are not enabled in your version of Qt. Then in your catch block, have your app that informs the user without alerting Windows of the crash.

BTW...I didn't follow your link. I've already seen enough "coding horrors" from teams who thought they were "the best." Don't get me wrong, I don't think that I'm the best either...but you won't find me "justifying" my failures by comparing them to the mistakes of others.

You never did answer my question:

Why not simply write your programs so that they don't crash?



MxB

I know you have a Windows-specific issue, but the approach may be the same...
When building on Linux you have to option to insert debug symbols so runtime evaluation by a debugger (gdb, for example) is more useful. Using those symbols and gdb command mode you can run an application through gdb and gather a backtrace if it fails (all of this hands-off).
If you can not do that, there is another approach using strace wherein you can spawn a process and register to receive all interrupts to system calls handled by your app, this includes some signal handling as well.

I point these out as I imagine that Windows has similar functionality and these may be a start for your search. In either case, though, there requires some 'under the hood' work to be done to understand these tools to their full capacity.

__________________
My personal site: Utilities for text processing, debugging, testing and plotting

"If builders built buildings the way programmers wrote programs, the first woodpecker to come along could destroy civilization"

__________________

During the election they said Obama could only be elected when pigs fly. Well, we currently have an epidemic of Swine Flu. Coincidence?

Checking return values is helpful, but we are interfacing with a lot of hardware (accelerometer, GPS, camera, etc) and some of these interfaces simply abort under bad conditions.

Even if we could write bug free code, we are relying on libraries from third party vendors, which are excellent but buggy. For example look at the bug list from the last minor release for Qt: http://www.qtsoftware.com/developer/...changes-4.5.1/


I'd be extremely interested if you could point me to a non trivial project that was released with no bugs.
I'm sure the engineers at Google, Nokia, etc would also be interested, because they also can't help releasing buggy software!

I found the following windows function that may provide the debugging information:
http://msdn.microsoft.com/en-us/library/ms680360.aspx

And to stop the windows crash dialog we now intercept abort signals and then exit manually.

Together this should help us diagnose problems if our program crashes remotely.