Just added something that might be helpful to some of you: I needed some crash dump functionality, so added functions SystemStats::getStackBacktrace() and SystemStats::setApplicationCrashHandler(). Feedback welcome!
I got this in my crash log:
Ctrlr crashed on: 10 Mar 2013 22:20:56
0: Ctrlr-Debug-Win32: juce::SystemStats::getStackBacktrace + 0x7f
1: Ctrlr-Debug-Win32: CtrlrManager::crashHandler + 0x249
2: Ctrlr-Debug-Win32: juce::handleCrash + 0xf
3: UnhandledExceptionFilter + 0x164
4: RtlCreateUserThread + 0xaadc
5: RtlInitializeExceptionChain + 0x58Will setting the:JUCE_CATCH_UNHANDLED_EXCEPTIONS to something help, make the crash dump a bit more informative ?
Also what can we use in the crash handler, i used the FIle() class to write the stack trace to disk, are there any dos and donts?
hmm… I didn’t test the PC version very carefully. Might need to rethink that a bit.
are there any dos and donts?Well, your app’s already crashed, so probably not much point worrying too much about dos and don’ts!
I know that this situation is a bad one as it is. Can i try to show a dialog window, or maybe i should prepare a different EXE (crashreporter.exe) that gets executed on crash ? I really don’t know what happens when a crash occurs that’s why i ask. I assume the memory got corrupted (i do a test crash by using a bad pointer), i know that i shouldn’t do anything and exit as quick as possible. It’s just that i need to inform the user of that fact and write some meaningful information to a CRASH file so that the poor user can send me a report.
Probably best to avoid any UIs, but yes, you could launch another app. In tracktion I think I’ll just make it dump some info to the log file.
I thought about starting my app just with a CLI parameter “-crash pathToExecutableThatCrashed” sort of thing co i don’t over complicate stuff.
Do you think that the stack trace on Windows can be more precise, i mean at some time in the future, i saw that you are getting a MS surface, are you getting the PRO x86 based one or the ARM based with ARM onboard ?
Tricky… There’s nothing wrong with the stack trace function, but it seems that when Windows invokes the exception handler, it does so from a different thread than the one that crashed (doh!), so it’s showing a correct printout of the wrong stack. Not really sure what could be done about that. Suggestions welcome!
Would you mind putting an example of this sort of use into the Juce docs? I guess you’d have to re-open the apps log file and append the data?
Bruce
I think you have to use StackWalk64 from the dbghelp.h in order to get correct backtraces in exception handlers, but it requires the ms debugging tools to be installed
I’ve actually gone down a different path for tracktion - even if it got the stack trace, the lack of debug info makes it fairly useless, so instead I’ve littered the more risky bits of code with some local scoped objects that keep a fake stack of file/line number positions. That works better for this scenario. I’ll leave these methods in place though, since both are still useful in their own way.
Why not ship with debug symbols?
That begs the question. Can i ship my application binary with debug symbols in it ? will it affect performance ? Also on windows won’t it be linked to different debug DLLs that are only available if you have VS installed ?
Don’t confuse linking against the Debug C Runtime with producing symbols. You can have an optimized Release build that also has debug symbols and a .pdb file. In fact, you need this for most profilers to work, that’s why I kept bothering Jules to fix IntroJucer so that it could produce Release builds that have debug symbols.
there is a linker option to create a map file, which contains the offsets of the entry positions of methods (at least in VS2008)
i made a script that copies the map file with every release build and counts a version number, which is also shown in the about dialog…
so if i have the buildnumber, i have also the mapfile, i can backtrace anything, with release builds, without build-in symbols…
Hey,
I am fairly new to juce but this topic seems fimiliar to me. I tried to use Stackwalker in the past. Unfortuntely, I never got it working correctly.
Please be gentle, I a newbee in this topic as well.
@chkn: you said you can create a map file for every release an you have a stacktrace. I am not sure how to create this map file. Is /MAP enough?
The worst thing is how to connect the map file with the stacktrace (mini dump file?). I can open up VS2008 with a file FirstTry.dll.dmp. FirstTry.dll
was a full release build with optimizations. In VS2008 I don’t see anything in the dump file, no stack trace. I case I am lucky I see the entry Function Pointer that crashes.
Well I really like to see a full stack trace and in best cases the line number where it crahes 
I hope you can help me. Until now, I am quite lost when my software crashes on the end users side.
Thank you!
Sven
i just open the map file in notepad, and look where i can find the positions from the stack trace between the offsets. You will learn how to count in hexadecimal numbers 
Maybe someone could write a tool for this
are you telling me that VS2008 doesn’t resolve this for me?
Btw, I know how to count in hex 
I found it 
here:
http://dotnetforum.net/topic/67250-crash-dump-no-symbols-are-loaded-for-any-call-stack-frame-the-source-code-cannot-be-displayed/
when I am doing this:
1) C/C++/General; Set Debug Info Format to Program Database (/Zi)
2) Linker/Debugging; Set Generate Debug Info to Yes (/DEBUG)
3) Linker/Optimizations; Set References to Eliminate Unref Data (/OPT:REF)
4) Linker/Enable COMDAT Folding; Set to Remove Redundant COMDATs (/OPT:ICF)
It works like a charme! I can crash my software in release mode and dumping a mini dump. After that I use VS2008 to load up the dmp attach the symbols and I can see the crash point in source code. No hex counting
Thanks svenT