Diagnosing DBGHELP symbol loading

I’ve had a love/hate relationship with DBGHELP.DLL for a long time, as reader of my MSDN column well knew. I love what DBGHELP does, but I hate when my calls to it fail and I have no clue why.

One of the cool things about working at Microsoft is the ability to pick up the phone and call the guy who owns DBGHELP. However, I try to reserve this for cases where I’ve been banging my head against ye’old wall for several hours. I don’t want to abuse my privileges too much.

In the course of nailing down a nasty symbol loading issue today, the owner of DBGHELP pointed out two environment variables that, while technically documented, are pretty obscure.

The MSDN page describes the two environment variables that can be set before calling SymInitialize:

DBGHELP_DBGOUT=<whatever. 1, 42, your SSN, or whatever else suits your fancy>



The first (DBGHELP_DBGOUT) dumps its output via OutputDebugString, so your debugger (or programs like DbgView) will see all the symbol searching that DbgHelp does when loading symbols for a module. The second causes DBGHELP to write to the filename you specified.

If you’re using the Visual Studio 2005 (“Whidbey”) IDE and debugging C++, it’s trivial to set these environment variables (or any environment variable for that matter) via the project’s Property Pages dialog.

Under “Configuration Properties”, select “Debugging”, and add your variable (e.g., DBGHELP_DBGOUT=1) to the “Environment” cell. Don’t forget to ensure that “Merge Environment” is set to “Yes”.

Comments (1)

  1. This same information can be displayed in PEBrowse Interactive by checking the item, "Display DbgHelp debug messages?", on the debug tabsheet in the configure options. Also, PEBrowse Professional displays the log information after you have loaded an executable under the menu item, File/View DbgHelp Log…