As Windows software developers, we all extensively use Visual Studio and/or WinDbg to step into our code, set breakpoints, watch variables, and perform many other useful tasks related to the debugging of applications. We somehow know that an internal mechanism exists in order to enable debuggers to map source code to binary and step into many of the available runtime libraries. For this purpose, debuggers use Program Database (PDB) files for managed as well as unmanaged code. PDB for managed code contains less debug information since these are located in the metadata section of the PE sections.
A native C++ PDB file contains a lot of information:
public
,private
, andstatic
function addresses- Global variable names and addresses
- Parameter and local variable names and offsets where to find them on the stack
- Source file names and their lines, etc...
A .NET PDB file only contains two pieces of information:
- The source file names
- Their lines and the local variable names
All the other information is already in the .NET metadata so there is no need to duplicate the same information in a PDB file.
The most important thing all developers need to know: PDB files are as important as source code! Without the matching PDB files you just made your debugging challenge nearly impossible. Briefly, a Symbol Server stores the PDBs and binaries for all your public builds. That way no matter what build someone reports a crash or problem, you have the exact matching PDB file for that public build the debugger can access. Both Visual Studio and WinDBG know how to access Symbol Servers and if the binary is from a public build, the debugger will get the matching PDB file automatically.
http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P