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
.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 databaseBuild > 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.