PDB file: The PDB files that each developer must know

PDB Files:what every Developer must Know
Http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx

PDB files: Every developer must know

What is a PDB file

Most developers should know that PDB files are used to help debug the software. But how exactly does he work, we may not be familiar with it. This article describes the storage and content of PDB files. It also describes how debugger finds the corresponding PDB file for Binay and debugger how to find the source code file that corresponds to the Binay. This article applies to all developers of native and managed.

Before we begin, we define 2 terms: Private build, which represents the Build;public build built on the developer's own machine, representing the build built on the common build machine. The private build is relatively straightforward, because the PDB and Binay are in the same place, and the common problem we encounter is about public build.

The most important thing that all developers need to know is that "PDB files are as important as source code", without PDB files, you can't even debugging. For public builds, the symbol server is required to store all the PDB, and then when the user reports an error, debugger can automatically find the corresponding PDB file for Binay, Visual Studio and WinDbg all know how to access the symbol server. Before you store the PDB and Binay in the symbol server, you also need to source indexing the PDB run, and the source indexing is associated with the PDB and source.

The next section assumes that symbol server and source server indexing have been set up. TFS2010 can easily complete the source indexing and symbol server copying for a new build.

Content of the two PDB files

Formally starting the content of the PDB, the PDB is not a publicly available file format, but Microsoft provides the API to help get data from the PDB.

The Native C + + PDB contains the following information:
* Public,private and static function address;
* The name and address of the global variable;
* The name of the parameter and local variable and the offset on the stack;
* Class,structure and type definition of data;
* Frame Pointer omission data, used to traverse the native stack on the x86;
* Source code file name and number of lines;

The. NET pdb contains only 2 parts of information:
* Source code file name and line number;
* and the name of the local variable;
* All other data are already included in the. NET metadata;

How the three PDB works

When you load a module into the process's address space, debugger uses 2 of the information to find the corresponding PDB file. The first is undoubtedly the name of the file, and if loaded Zzz.dll,debugger looks for the zzz.pdb file. In the case of the same file name, debugger also ensures a true match of the PDB and Binay by embedding the GUID into the PDB and the Binay. So even without any code changes, yesterday's Binay and today's PDB are not matched. You can use Dempbin.exe to view the binary GUID.

The symbol file column of the Modules window in VisualStudio can see the load order of the PDB. The path of the first search is the path of binary, and if it is not in the path of binary, it finds the build directory of the HardCode record in binary, for example, obj\debug\*.pdb, if none of the above two paths find the PDB, according to the symbol The server's settings are found in the local symbol server's cache, and if there is no corresponding PDB in the local symbol server's cache, it is finally found in the remote symbol server. By looking in the order above we can see why the PDB lookup of the public build and private build does not conflict.

For private build sometimes we need to debug on someone else's machine, we need to copy the corresponding PDB with binary, and for the binary of. NET joining the GAC, you need to copy the PDB file to C:\Windows\assembly\ gac_msil\example\1.0.0.0__682bc775ff82796a the same directory as binary. Another workaround is to define the environment variable Devpath, instead of using the command gacutil to put binary into the GAC. After defining the Devpath, you only need to place binary and PDB into the Devpath path, and binary under Devpath is equivalent to under the GAC. With Devpath, you first need to create the directory and write to the current build user, then create the environment variable Devpath and the value is the directory you just created. Then turn on development mode in Web.config,app.config or Machine.config and start using the Devpath
<configuration>
<runtime>
<developmentmode developerinstallation= "true"/>
</runtime>
</configuration>

After you open the development mode, if Devpath does not have a definition or the path does not exist, it causes the program to start with an exception "Invalid Value for Registry". And if the use of Devpath in Machine.config will affect all other programs, use Machine.config with caution.

The last developer needs to know how the source code information is stored in the PDB file. For public builds, after running the source indexing tool, the version control utility stores the code in the code cache that you set. For private builds, only the full path of the PDB file is stored, such as the source file Mycode.cpp under C:\foo, and the path stored in the PDB file is c:\foo\mycode.cpp. For private builds, you can use a virtual disk to increase the PDB's dependence on an absolute path, for example, you can use Subst.exe to mount the source code path as V: and to Mount V when debugging on someone else's machine.

Finish!

PDB file: The PDB files that each developer must know