Minidump creation!


Any of you guys use minidumps? Using them with JUCE is possible.
codeproject has a great article on how to create them in your Windows app.

If you distribute your stuff to the general public I highly recommend it.
I develop windows drivers and sometimes the only way I can tell how my code broke on some machine in Nebraska is to view the minidump.
If you don’t already know, basically a minidump is a snapshot of the current call stack and all the pertinent local variables.
Windows will automatically create one when a driver crashes.
For regular Windows programs (like JUCE apps) you need to explicitely create one.
Fortunately it is pretty easy to do, read the above code project link.
When an applications causes a general exception (like referencing a null ptr) your program can be notified.
Your program can then explicitely create a minidump file that can be viewed at a later time.

I like C++ exceptions but using the default catch (…) messes with my minidump creation.
By handling any runtime exception (like JUCE does), the call stack reported in minidumps (and by my debugger) is not accurate.
I want my ‘divide by zero’ exception (or anything else unplanned for) to float all the way up to where the debugger can catch it.
The JUCE library has enough catch (…) blocks that my general non-juce specific exceptions usually get caught.
There are situations where that is a good thing, but I don’t want that.

Mostly for the sake of minidump creation.
If I am enabling my Windows program to create minidumps
then I want general exceptions to be caught the top level exception handler (in Windows I use SetUnhandledExceptionFilter())
Thus I can get a call stack that points directly to offending exception causing code when I handle the exceptionn and make my minidump.
Otherise if I let it get caught by one of the many “catch (…)” blocks in JUCE, then the stack points to the contents of the catch (…) block.
Its kinda like looking at the placement of two cars a minute after a head on accident, as opposed to seeing the exact moment of impact.

So as an experiment, I went through JUCE and commented out all the catch (…) blocks. This worked for me.
In the case where there is just a try block with just a catch (…) block, I also comment out the try block.
Maybe a #define around these blocks would be in order.
something like:

catch (...)
	JUCEApplication::sendUnhandledException (0);

By default have the general exception handling on.
When someone wants to handle general run time exceptions on there own (like me)
they would just comment out the following #define

I didn’t want to turn off all exception handling, that seemed a bit drastic.

any thoughts on this?
Or am i missing something very obvious…
anyway hopefully this will be of help to other people out there.
Minidumps are truely great.
Microsoft used them extensively to make XP a much better product than previous versions of non NT based Windows.
I can’t imagine going back to a time before using them.

The big reason I’m posting this is that hopefully the JUCE library can incorporate minidump creation!
As opposed to be hacking up the library everytime a new version comes out (bad). Everyone of us should be taking advantage of them anyway.
I mainly do windows programming, so what are the Linux and Mac equivalents?


Sure, I can add an option for that. Good idea.


yeah, in some case when i get exceptions i can’t actually see what’s happening and where, mainly because they are handled in the main juce error handler blocks (and you loose the call stack when u get catched up in that block). keeping the hardcoded try catch blocks off the code in debugging could be helpful.


My year in hell doing driver programming actually had some sort of positive ramification on the world! I never would have paid too much attention to post mortems if I hadn’t needed too.

WinDbg is your friend!



Eegads, you happened to post that right when I needed it, that was a perfect solve for another project of mine. Thanks.