Keeping Specific PDB Files from Loading in the Debugger

6 Comments May 29, 2009


As I've discussed, PDB files are wondrous bundles of binary joy. However, loading missing PDB files can quickly become an angst-ridden teenager as you wait what seems like forever on a network timeout for missing symbols. This is especially apparent in Tom's question:

For nearly two years I've been searching the Internet for an answer to this question: is it possible to get the DBGHELP.DLL to /not/ load a PDB for a specific DLL? I have applications that have lots of third-party DLLs for which I have no PDB files (read: "drivers for a database company that shall remain nameless") and I'd like to tell the DBGHELP.DLL to avoid attempting to search for those PDBs. In fact, I have been investigating the possibility of making stub PDBs with no information and stuffing them in a private symbol server just to make symbol loading faster.

Any thoughts?

Oh, I have many thoughts, and like Tom, some of them are not wholesome when wrestling with that "database company that shall remain nameless" because they won't release symbols for their native compiled drivers. For those of working on native binaries that third parties plug into, it's trivial with the linker /PDBSTRIPPED switch to generate the same kind of PDB files Microsoft makes available on its public symbol server. You're not giving up any secrets with stripped symbols!

The good news for all of us needed to skip loading a few PDB files is that the debugger folks at Microsoft know your pain and have a decent solution. Unfortunately, most people haven't seen it because the trick is in the SymProxy discussion, which is how you host your own HTTP symbol download. Mentioned in passing is "This feature exists in the client debugger..." There is one small bug is how they tell you to do the exclusion is incorrect, but easily fixable.

The first way to exclude particular PDB files is to create a file called SYMSRV.INI and put the Exclusions section in like the following:

[exclusions]
dbghelp.pdb
symsrv.*
mso*

I love the wildcard support! The documentation doesn't tell you where to place that file, but it needs to be in the same directory as SYMSRV.DLL. That's why I don't care for this approach because that means you need to put this file in every place where you have a debugger as they all use SYMSRV.DLL to do their symbol loading.

A better approach is to put the exclusions in the registry so every debugger automatically picks them up. The documentation says to put them in HKEY_LOCAL_MACHINE, but the real place is HKEY_CURRENT_USER. First, create a key HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\Exclusions. In that key, create REG_SZ values for the PDB files, including wildcards, for the PDB files you want to skip. Here's an example .REG file for skipping NOTEPAD.EXE and for Tom, the wildcard for what I'm guessing he'd like to skip <grin>:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\Exclusions]
"notepad.pdb"=""
"ora*.*"=""

In the value field, you can put anything you want, like a comment as to why you need to skip loading these PDB files. Alternatively, you could fill the void with pithy quotes to provide a moment of Zen for anyone reading your registry.

Using the above .REG file, I debugged NOTEPAD.EXE with Visual Studio and here's the proof that no download from the Microsoft symbol server took place.

There are a couple of more questions in my queue, but if you have more, please don't hesitate to ask if there's something you wanted to know about PDB files. Please let me live my dream of educating everyone about PDB files!


6 Comments

  • Gravatar Image
    Bill Menees May 29, 2009 9:55 AM

    I'm so happy right now, I'm sending you one BILLION karmic points to spend at your leisure. Enjoy them! I'm definitely going to enjoy this tip.

  • Gravatar Image
    Twitted by rguerreiro May 29, 2009 10:01 AM

    PingBack from http://real-url.org/twitted.php?id=1959861819

  • Gravatar Image
    Gerard June 11, 2009 9:35 PM

    We found that everyone using their own symsrv.dll was problematic so every machine has _NT_SYMBOL_PATH that specifies the dll to use e.g.,

    symsrv*\\\symbols\symsrv.dll*\\\symbols\;symsrv*\\\symbols\symsrv.dll*\\\symbols\microsoft*http://msdl.microsoft.com/download/symbols

  • Gravatar Image
    Richard Sim June 27, 2009 2:06 PM

    Awesome! Thank you very, very much for this!

    I've been long-plagued by the issue of timing out due to trying to load symbols when attempting to attach for remote debugging to a (very large) third party app that we have written a plugin for - this will help a TON.

    Thanks again, you rock. :)

  • Gravatar Image
    John Robbins' Blog October 19, 2009 12:24 PM

    I love all things diagnostics. After installing VS 2010 Beta 2, the first thing I had to look at my favorite

  • Gravatar Image
    John Robbins' Blog June 2, 2010 8:58 PM

    Symbol Servers are one of the best things that have ever happened in Windows debugging. Having a central

Have a Comment?

Archives

Blogs