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.

Windows Symbols

Microsoft Windows 2000 keeps its symbols in files with the extensions .pdb and .dbg. Windows XP and later versions of Windows use .pdb files exclusively. Windows drivers can follow either model.

The compiler and the linker control the symbol format. The Visual C++ 5.0 Linker creates both .pdb and .dbg symbol files — the .dbg files it creates are essentially pointers to the .pdb files. The Visual C++ 6.0 Linker, as well as the linkers of later versions of Visual Studio, places all symbols into .pdb files.

The Windows operating system is built in two versions. The free build (or retail build) has relatively small binaries, and the checked build (or debug build) has larger binaries, with more debugging symbols in the code itself. Each of these builds has its own symbol files. When debugging a target on Windows, you must use the symbol files that match the build of Windows on the target.

The following table lists several of the directories which exist in a standard Windows symbol tree:

Data Types

All types created by typedefs within your own code will be present, as long as they have actually been used in your program. However, types that are defined in your headers but never actually used will not be stored in the .pdb symbol files and will not be accessible to the debugger. If you wish to make such a type available to the debugger, you should use it as the input of a typedef statement. For example, if the following appears in your code, the structure MY_DATA will be stored in the .pdb symbol file and can be displayed by the debugger:

typedef struct _MY_DATA {
    . . .
    } MY_DATA;
typedef  MY_DATA *PMY_DATA; 

On the other hand, the following code would not suffice, because both MY_DATA and PMY_DATA are defined by the initial typedef, and therefore MY_DATA has not itself been used as the input of any typedef statement:

typedef struct _MY_DATA {
    . . .
    } MY_DATA, *PMY_DATA; 

In any event, type information is included only in a full symbol file, not a symbol file that has been stripped of all private symbol information. For more information, see Public and Private Symbols.