What does "pdb is obsolete" really mean?

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 (18)

  1. Raymond Zhang says:

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

  2. Andy-Pennell says:

    MSF stands for "Microsoft Stream Format" I believe. DS is Dan Spalding, who owned the linker and much of the PDB code for many years before retiring. RS is the other initial in the newer PDB header, Richard Shupak, who also had a substantial hand in this area. Well in many areas at MS in fact. He is in MS Research.

  3. Raymond Zhang says:

    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?

  4. Andy-Pennell says:

    PDB 2.0s are before my time (my first product was VC4). I cannot recall a team member "JG".

  5. Koby Roberts says:

    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!



  6. Andy-Pennell says:

    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…

  7. Jan Gray says:

    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.

  8. Andy-Pennell says:

    Hi Jan! I should have known that JG was you, sorry.

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

  10. Yuhong Bao says:

    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.

  11. Andy-Pennell says:

    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.

  12. Yuhong Bao says:

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

  13. Yuhong Bao says:

    BTW, my real questions is, what about VC7.x?

  14. Andy-Pennell says:

    Non-PDB symbol support was deleted from the codebase, yes, and I think that was VC8. The last time I used a DBG file to debug anything was Win9x, and I am very happy that I haven’t had to do that for many years now.

    I believe VC7.x can still read the crappy old symbol formats (DBG, SYM, COFF etc), but as I don’t have one to hand I can’t be sure.

  15. Yuhong Bao says:

    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.

  16. Yuhong Bao says:

    BTW, this reminds me of a problem I encountered with the VB6 runtime.

    One version of MSVBVM60.DLL had it’s DBG file published on the symbol server. That DBG file contained both COFF symbols and a PDB reference. The problem was that the PDB referenced in the DBG file was missing.  WinDBG could still read COFF symbols but VC8 and later would not be able to read it. Fortunately, MS later fixed this case, but afterwards I encountered several ActiveX controls shipped with VB6 which had the same problem:

    DBGHELP: c:windowssystem32comctl32.ocx is stripped.  Searching for dbg file

    SYMSRV: C:downloadssymbolscomctl32.pdb380242F9comctl32.pdb not found

    SYMSRV: http://msdl.microsoft.com/download/symbols/comctl32.pdb/380242F9/comctl32.pdb not found

    DBGHELP: comctl32 – coff symbols


    [SYMCHK] MODULE64 Info ———————-

    [SYMCHK] Struct size: 1672 bytes

    [SYMCHK] Base: 0x202B0000

    [SYMCHK] Image size: 610304 bytes

    [SYMCHK] Date: 0x3802598b

    [SYMCHK] Checksum: 0x000a0df1

    [SYMCHK] NumSyms: 4786

    [SYMCHK] SymType: SymCoff

    [SYMCHK] ModName: comctl32

    [SYMCHK] ImageName: c:windowssystem32comctl32.ocx

    [SYMCHK] LoadedImage: C:downloadssymbolscomctl32.dbg3802598B95000comctl32.dbg

    [SYMCHK] PDB: ""

    [SYMCHK] CV: NB10

    [SYMCHK] CV DWORD: 0x3031424e

    [SYMCHK] CV Data:  comctl32.pdb

    [SYMCHK] PDB Sig:  0

    [SYMCHK] PDB7 Sig: {00000000-0000-0000-0000-000000000000}

    [SYMCHK] Age: 0

  17. Yuhong Bao says:

    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