CODEWITHSUNDEEP
visual-studiosecuritydebuggingwindbgollydbg
peng xu
peng xu

Reputation: 415

Why windbg cannot read symbols from my pdb file?

my pdb file MFCLibrary1.pdb was genereted by virtual studio 2017, I place it in its origin directory G:\MFCLibrary1\Debug\, I set symbol path and windbg can load it normally, however, I cannot read any symbol information with x MFCLibrary1!* command, as the fllowing picture show: enter image description here

enter image description here

enter image description here

Upvotes: 1

Views: 1281

Answers (1)

Sean Cline
Sean Cline

Reputation: 7179

link.exe has historically been pretty slow for big projects and it turns out most of that slowness was from generating the PDB file.

Visual Studio 2017 now defaults to using a new switch, /DEBUG:FASTLINK, which generates a minimal PDB file and leaves the rest of the debugging information inside the .obj files.

The obvious benefit of this option is the 2x to 4x improvement in link time, but it comes with some downsides.

Downside #1 - The PDB file for debug builds no longer contains all of the information required for symbolic debugging.

If you plan to debug your project on a different machine from the one that built it, you'll still need to generate a FULL symbol file.

This can be done in one of two ways:

  1. An existing FASTLINK PDB can be converted to a FULL PDB from Visual Studio's menu by running Build->Build full program database file for solution. Build full program database

  2. It can be permanently changed by setting the Generate Debug Info switch to /DEBUG:FULL on the project's Linker->Debugging property page. Linker property page

Downside #2 - Older tools, especially those using dbghelp.dll like WinDbg, don't understand the new FASTLINK symbol file format.

Some versions refuse to load FASTLINK symbols, others crash or hang. It's best update to the most recent version.

On my machine, FASTLINK symbols work fine with WinDbg version 10.0.15063.137, so updating your debugging tools to that version or higher should work.

If you cannot move to a new version of a debugging tool, for whatever reason, then generating a FULL PDB as described above is the next best option. Unfortunately, doing this, you won't see the improved link times that came with Visual Studio 2017.

Upvotes: 4

Related Questions