Udostępnij za pośrednictwem

What does "pdb is obsolete" really mean?

  • Artykuł

If your Visual Studio debugger says this to you, it either means

  1. Your PDB really is obsolete
  2. Your debugger is obsolete

1. It gets expensive in terms of testing and (sometimes) development to read every single old PDB format, so with each release the C++ team determine what is the oldest PDB they can read is. 8.0 will read PDBs created with 5.0, but I don't believe it can read a 4.0 PDB any more.

2. A common case for this is a PDB created with 8.0, then read with Visual Studio 7.1 or earlier. There was a lack of forethought on error codes, so there was one error that mean basically "huh? can't read this".

How do you tell the version of a PDB you may ask? Believe it or not you TYPE the pdb itself: if it says

Microsoft C/C++ MSF 7.00

then it is 7.0 or newer. If it says something else, then it is older than that. Unfortunately I am not aware of any public tools that will tell you the version with greater granularity.

Comments

  • Anonymous
    April 23, 2007
    Andy, could you advise what does MSF mean in the signature. As I know, the signaure is followed by DS.

  • Anonymous
    April 24, 2007
    The comment has been removed

  • Anonymous
    April 24, 2007
    Andy, thanks for you answer and I have great respect to the heroes. BTW, in PDB 2.0, the signature is JG? Does that indicate another hero?

  • Anonymous
    April 25, 2007
    PDB 2.0s are before my time (my first product was VC4). I cannot recall a team member "JG".

  • Anonymous
    August 28, 2007
    The comment has been removed

  • Anonymous
    November 10, 2007
    Any way of changing the mismatched info on a PDB if a simple rebuild of a dll or exe was does and enough of the signature changed so that VS 2005 won't load the pdb, but WinDbg will with a force reload?  I have a dll that made it to a customer and the dll got automatically rebuilt before we could iron out our build process.  Oops! Thanks! Koby

  • Anonymous
    November 12, 2007
    No, VS deliberately will never load a PDB that doesn't match the binary. Your best hope is to use windbg, or to try patching the debug header in the PE file to match the PDB that you do have. Also, demote the release manager for that product...

  • Anonymous
    June 09, 2008
    JG is Jan Gray. I designed and implemented the PDB file format and the incrementally, transactionally updated store of symbols and types that reside therein. MSF stands for multi-stream file.  The PDB is like a simple transactionally updated filesystem in a single file.  There is a metadata stream, some name table streams, a stream for global types, one for each module's symbols, etc.  These streams are updated during compile and incremental linking. The file is transactional so that it is effectively impossible to logically corrupt it even if the program is interrupted between any two arbitrary writes to the file.

  • Anonymous
    June 10, 2008
    Hi Jan! I should have known that JG was you, sorry.

  • Anonymous
    October 08, 2008
    Hi Andy:     how are you, can you tell how to use pdb for debug? can i use it and related exe for debug without code detailed. and use windbg?     thank you

  • Anonymous
    January 29, 2009
    Also not supported in 8.0 and later, BTW, are CodeView (non-PDB) and COFF symbols, which means that if you compile your code in VC6 or earlier and want the symbols generated to be readable by VC8 or later, you must not use /PDB:NONE as this will cause VC6 to generate CV symbols which as I said earlier are not readable by VC8 and later, and instead must specify a PDB filename like /PDB:filename. This will cause VC6 to generate PDB symbols which is readable by VC8 and later.

  • Anonymous
    January 31, 2009
    Yuhong: on the subject of obsolete developer tools, I believe support for VC4 PDBs was deleted in 8.0 as well. I think VC5 and VC6 formats were the same, and are still supported. However: get with the program: quit using VC6 for things. Is your PC eleven years old also? I seriously doubt it.

  • Anonymous
    February 23, 2009
    "I think VC5 and VC6 formats were the same, and are still supported." I know, but what I am saying was that these compilers also had the option to generate non-PDB CodeView symbols (using the /PDB:NONE switch to the linker) as well as COFF symbols, and none of these are supported by VC8. Instead you must generate a PDB using /PDB:filename. Of all the symbol formats that VC5 and VC6 can generate, this is the only one that can be read by VC8 and later. Also consider the fact that if you move to VC7 or later, you have to move away from COFF or CodeView to the PDB format anyway. "However: get with the program: quit using VC6 for things. Is your PC eleven years old also? I seriously doubt it." VS6 lasted a long time, it was not until 4 years later that VS.NET was released. But you are right that nowadays only if I develop on Win9x or NT4 that I'd be using VC6 and none of these OSes are supported anymore anyway. But Wireshark 1.0.x still was compiled with VC6. Not only that, it was compiled with CodeView symbols embedded in the binary itself using /PDB:NONE, and that can't be read by VC8 and later. Luckily Wireshark 1.1.x and later is compiled with VC9 SP1. Firefox 2.0.x and earlier was still compiled with VC6 as well, luckily they chose to generate a PDB during build, which are readable by VC8 and later, and Firefox 3.0 and later upgrades the compiler to VC8 and it's PDBs also have source server support.

  • Anonymous
    February 23, 2009
    BTW, my real questions is, what about VC7.x?

  • Anonymous
    February 26, 2009
    The comment has been removed

  • Anonymous
    February 27, 2009
    Actually, DBG is not a symbol format, it is a container for another symbol format, such as CV, COFF, or a PDB reference. In fact, Win2K uses a DBG file for the symbols, but the only thing it contains is a PDB reference. WinXP eliminated this redundent DBG file by moving the PDB reference to inside the EXE or DLL file itself. Unfortuately, even though the format of both the PDB reference and the file itself were initially still compatible with VC6, VC6 did not work very well with how it was arranged, requiring a manual registry workaround.

  • Anonymous
    February 27, 2009
    The comment has been removed

  • Anonymous
    March 02, 2009
    It looks like my comments I posted recently about COFF/PDB symbols and MSVBVM60.DLL have gone missing, which is bad, because I just found another versions of MSVBVM60.DLL that have the problem I pointed out in them: SYMSRV:  c:downloadssymbolsMSVBVM60.pdb392F49DAMSVBVM60.pdb not found SYMSRV:  http://msdl.microsoft.com/download/symbols/MSVBVM60.pdb/392F49DA/MSVBVM60.pdb not found DBGHELP: msvbvm60 - coff symbols         c:downloadssymbolsMSVBVM60.dbg392F6DC3153000MSVBVM60.dbg