Introduction to. PDB in. net

PDB: program debug database (program debugging database) File

1. What is a PDB file?
Most developers should know that the PDB file is used to debug the software. But we may not be familiar with how he actually works. This article describes the storage and content of PDB files. It also describes how the debugger finds the corresponding PDB file of binay and how the debugger finds the source code file corresponding to binay. This article applies to all native and managed developers. Before starting, we define two terms: Private build, which indicates the build generated on the developer's own machine; Public build, which indicates the build generated on the public build machine. Private build is relatively simple, because PDB and binay are in the same place. Generally, the problems we encounter are about public build. The most important thing developers need to know is that "the PDB file is as important as the source code". Without the PDB file, you cannot even debugging. For public build, you must store all the PDBs on the symbol server. Then, when the user reports an error, the debugger can automatically find the corresponding PDB file of binay, visual Studio and windbg both know how to access the symbol server. Before storing PDB and binay to the symbol server, you also need to perform source indexing on the PDB operation. The function of source indexing is to associate PDB and source. In the following section, we assume that the symbol server and source server indexing have been set. Tfs2010 can easily complete source indexing and symbol server copying for a new build.
2. Content of the PDB File
The content of PDB is officially started. PDB is not a public file format, but Microsoft provides APIs to help obtain data from PDB. Native C ++ PDB contains the following information: * Public, private, and static function addresses; * global variable names and addresses; * parameter and local variable names and stack offsets; * class, structure, and Data Type Definitions; * frame pointer omission data, used to traverse native stacks on x86; * Name and number of lines of the source code file ;. net PDB only contains two parts of information: * Source Code File Name and number of lines; * and local variable name; * all other data is included. net metadata is in;
3. How does PDB work?
When you load a module to the address space of the Process, debugger uses the information in 2 to find the corresponding PDB file.
The first one is undoubtedly the file name. If zzz. dll and debugger are loaded, query the ZZZ. PDB file.
When the file name is the same, debugger also ensures the true match between PDB and binay by embedding the guid of PDB and binay.
So even if no code is modified, the binay of yesterday cannot match the PDB of today. You can use dempbin.exe to view the binary guid. You can view the load sequence of PDB in the symbol file column of the modules window in Visual Studio.
The first search path is the path where binary is located. If not, find the build directory of the hardcode record in binary,
For example, OBJ \ debug \ *. PDB. If no PDB is found in the preceding two paths,
In the cache of the local symbol server, if no corresponding PDB exists in the cache of the local symbol server,
Then, it is found in the remote symbol server. The above search sequence shows why the PDB search of public build and private build does not conflict. For private build scenarios where we sometimes need to debug on someone else's machine, we need to copy the corresponding PDB and binary together,
For binary files added to GAC. net, copy the PDB file to the directory of binary files similar to C: \ Windows \ Assembly \ gac_msil \ example \ 1.0.0.0 _ 682bc775ff82796a.
Another work und is to define the environment variable devpath, instead of using the command gacutil to put binary into GAC.
After devpath is defined, you only need to put binary and pdb in the devpath path. Binary in devpath is equivalent to GAC.
To use devpath, you must first create a directory and have the write permission on the current build user. Then, create the environment variable devpath and set the value to the directory you just created,
Then in the web. config, app. config or machine. enable the Development Mode in config, start the use of devpath <configuration> <runtime> <developmentmode installation = "true"/> </runtime> </configuration> after you enable the development mode, if devpath is not defined or the path does not exist, it will cause an "invalid value for registry" exception during program startup ".
If you enable devpath in machine. config, all other programs will be affected. Therefore, use machine. config with caution. Finally, developers need 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 tool stores the code in the Code cache you set. For private builds, only the full path of the PDB file is stored,
For example, the source file mycode. cpp under c: \ foo is stored in the path c: \ Foo \ mycode. cpp in the PDB file.
For private builds, you can use virtual disks to add PDB dependencies on absolute paths,
For example, you can use subst.exe to mount the source code path to V:, and mount V: When debugging is performed on another machine :.
The PDB file contains the location information of the compiled program pointing to the source code. It is used to locate the source code during debugging and is mainly used to facilitate debugging. When the program is released in the release mode, we recommend that you delete the PDB file and delete the PDB file during external release, which is conducive to the protection of the program.
Blog reference source:
Http://www.cnblogs.com/itech/archive/2011/08/15/2136522.html