We generate a MiniDump when a crash occurs in the program.
We ask users to report their .dmp along their .exe and .pdb.
However, Visual Studio 2017 turns the /debug flag as /debug:fastlink to improve linking times. That pulls data directly from .obj files and makes .pdb smaller.
When we try to investigate a crash with this kind of .pdb we have a harder time because the .pdb references user's local .obj files.
By using /debug:full instead the .pdb file gets bigger (~9MB to ~15MB) and linking time slows down (not very noticeable), but it helps investigation by a lot because Visual Studio would ask for source code path instead of complaining about missing .obj.
We could also keep /debug:fastlink and, upon crashing, ask users to build the full debugging database Build > Build full program database for solution and then make it crash again (remember, a .dmp file is directly tied to its .exe and .pdb files).
This solution, however, makes the reporting process more convoluted and can discourage users from doing it.
We generate a MiniDump when a crash occurs in the program. We ask users to report their
.dmpalong their.exeand.pdb.However, Visual Studio 2017 turns the
/debugflag as/debug:fastlinkto improve linking times. That pulls data directly from.objfiles and makes.pdbsmaller.When we try to investigate a crash with this kind of
.pdbwe have a harder time because the.pdbreferences user's local.objfiles.By using
/debug:fullinstead the.pdbfile gets bigger (~9MB to ~15MB) and linking time slows down (not very noticeable), but it helps investigation by a lot because Visual Studio would ask for source code path instead of complaining about missing.obj.We could also keep
/debug:fastlinkand, upon crashing, ask users to build the full debugging databaseBuild > Build full program database for solutionand then make it crash again (remember, a.dmpfile is directly tied to its.exeand.pdbfiles). This solution, however, makes the reporting process more convoluted and can discourage users from doing it.