Understanding and Setting Up Access to Symbols

Symbols are vital to the overall debugging effort.  Most of the time we take them for granted since they are auto-generated for our applications but we hit a brick wall when we try to work with something where debug symbols aren’t available.  I thought it would be a good idea to remind folks where they can find information on what symbols are and how you can set up access to symbols on a symbol server.  You can find our great guide for setting up symbols here:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff558823(v=vs.85).aspx

Here is an excerpt from the Introduction to Symbols section:

===

When applications, libraries, drivers, or operating systems are linked, the linker that creates the .exe and .dll files also creates a number of additional files known as symbol files.

Symbol files hold a variety of data which are not actually needed when running the binaries, but which could be very useful in the debugging process.

Typically, symbol files might contain:

• Global variables

• Local variables

• Function names and the addresses of their entry points

• Frame pointer omission (FPO) records

• Source-line numbers

Each of these items is called, individually, a symbol. For example, a single symbol file Myprogram.pdb might contain several hundred symbols, including global variables and function names and hundreds of local variables. Often, software companies release two versions of each symbol file: a full symbol file containing both public symbols and private symbols, and a reduced (stripped) file containing only public symbols. For details, see Public and Private Symbols.

When debugging, you must make sure that the debugger can access the symbol files that are associated with the target you are debugging. Both live debugging and debugging crash dump files require symbols. You must obtain the proper symbols for the code that you wish to debug, and load these symbols into the debugger.

===