I would like to distribute and executable file built in C++ with full optimization in release mode. I am generating a core dump in case of unhandled exception and I would like to be able to get a readable call stack out of the minidump.
Online I see solutions that engage the /DEBUG option, but when I enable that option the executable file becomes sensibly bigger. My worries are that:
- maybe visual studio embeds information within the exe so that it would be easier to reverse engineer it
- it is not a fully optimized executable as it was without the /DEBUG option
Otherwise why the file would be bigger?
Isn't there the possibility to just keep aside the debug information in a file (isn't the pdb file meant for that?) such that it would be enough to reconstruct the call stack?
Do I have to enable other options together with /DEBUG maybe so that the exe would not increase in size?
I'm not necessarily interested to exactly which instruction cause the issue, but at least I would need to have a reliable and readable reconstruction of the call stack so I can identify the function responsible of the crash.
You probably need the
/ZIor/Zioptions along with the/DEBUG:FULL.It's pretty standard practice to archive
.pdbfiles for each release internally. Then, when a customer reports a crash, the memory dump can be matched with the correct version's debug info and the debugger gives a decent stack-trace.Archive the debug info for any
.dlls, shipped with your product as well. If the crash happens within.dllcode, the debugger won't be able to create a sensible stack trace without their.pdbs.