I’ve got a crash handler using getStackBacktrace(). On the Mac we are doing well and get a complete backtrace, but on Windows despite Generate Debug Symbols being ticked the backtrace is missing all the calls inside the application.
Anyone know how to make it work?
You need to distribute the .pdb file together (and it has to be the exact one from the exact same build, even recompilation breaks the link).
iirc there’s an options somewhere to include symbols in the target aswell (well, that used to be an option…) meaning you don’t need a separate pdb
Does the pdb need to be on the clients machine? I thought you only need it when loading the stack into the debugger…
The pdb would disclose a lot of details about my code afaik.
But I don’t know, my colleague (at a different company a long time ago in a different galaxy) was responsible for that workflow, so I never did that myself…
I’m not 100% whether it’s the only way, but afaik the API used on the Windows side relies on pulling the symbols from a .pdb file. Alternatively, you can dump the offsets and bases, and make a tool for automatically matching it to symbols on your dev machine (I believe this is not done in the JUCE function although it is possible).
Yes the .pdb may optionally contain some information, but it’s not like that information can’t be reverse-engineered anyway if it’s worth it 
It’s still as illegal (if you state so) to reverse-engineer the .pdb
Okay - will include the PDB during our beta I think. It becomes a real problem if you’re running with some anti-reverse engineering copy protection stuff but for this product we should be good to just include the PDB and get better crash data. Presumably just needs to be in the same folder as the EXE.
(Also - it’d be good if these instructions were added to the getStackBacktrace() documentation. We’d have got this right on day one!)
The same directory as the .exe, yes. If it’s a DLL it may look in the wrong folder (the parent’s .exe directory) so you need to add your DLL directory to the symbol scanner using the SymInitialize() function.
What you usually do (at least on Windows) is somehow collect the minidump file from the client, and then in your office you can load the minidump and the PDB files for that exact build and get the stack trace. You don’t need to release the PDB files.
I think you can register with Microsoft to receive those minidump files via their error reporting, that’s why Windows has “application has stopped working” dialogs.