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 the 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 for unmanaged code. PDB for managed code contains less debug information since these are located in the metadata section of the PE sections.
This article has several goals:
A native C++ PDB file contains a lot of information:
Public, private, and static function addresses A .NET PDB only contains two pieces of information:
All the other information is already in the .NET metadata so there is no need to duplicate the same information in a PDB file.
For those of you not familiar with the Windows Debug Interface Access, Program Database (PDB) and the basic ideas presented here, a few essential links:
When compiled with debugging information, an executable file contains two references to the associated PDB file:
When a program to be debugged is launched, the debugger goes into the executable file and tries to locate the correct PDB file to proceed to the debugging session. The links above explain these along with how to setup a Symbols server.
The PDB project presented here consists of three parts:
PdbParser: C++ project - implements the PdbParser.dll which is a wrapper to the DIA interface. PdbInspectorConsole: C++ Win32 console project - consumes the PdbParser and shows the modules referenced in a PDB file. PdbInspector: C++ MFC project - consumes the PdbParser and shows the modules referenced in a PDB file and a few of the available details related to the modules. The project has been developed and tested on Windows Vista Ultimate 32bit only.
As mentioned earlier, the Microsoft DIA SDK is a COM-based interface to handle PDB files. The problem with this SDK is that it consists of a tremendous collections of interfaces and functions. The PdbParser presented here abstracts these details and offers a simple task oriented set of interfaces. In this version, the PdbPaser concentrates on the collection of modules. The PdbParser is organized into a set of abstract layers. Opening a PDB file is made in two steps:
PdbParser using the IPdbParserFactory::Create() function:
IPdbParser* pIPdbParser = IPdbParserFactory::Create();
IPdbParser::Open() function
IPdbParser* pIPdbParser = IPdbParserFactory::Create();
IPdbFile* pIPdbfile = pIPdbParser->OpenFile(L"test.pdb");
In order to retrieve details about a specific module referenced in a PDB file, one has to go through three additional steps:
IPdbFile::GetModules() function. IPdbModule::GetModuleDetails() function. IPdbModuleDetails functions available.
//Traverse the Modules
vector
In order to retrieve the source file names of a specific module, one has to go through three steps:
IPdbFile::GetModules() function. IPdbModule::GetSourceFiles() function. IPdbSourceFile::GetFileName()function.
//Traverse the Source file Names collection.
std::vector
When appropriated, the resources allocated by the PdbParser are freed using one last step.
IPdbParserFactory::Destroy() function.
IPdbParserFactory::Destroy();
The image below shows the accessors-based hierarchy:
IsStripped() method. | You must Sign In to use this message board. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
