PDB file Overview

ArticleDirectory

•  

Text/Xuan Hun

. PDB file, all called"ProgramDatabase file. We Use It (more specifically, we see it being applied). Most scenarios are debugging applications. At present, we generally know that the. PDB file stores the debugging information of the compiled file, which exists as a symbolic file. So what content does it contain? How does one play a role in the debugging process? Is there any way to operate this file?

1. PDB File Content

The internal format of the. PDB file is not disclosed by Microsoft. It is still a secret, but it provides related APIs for the debugger to obtain information from it.

The PDB file of an unmanaged C ++ program contains the following information:

• L public, private, and static function addresses
• L name and address of the global variable
• L name of parameters and local variables and their offset in the stack
• L type definition, including class, structure, and data definitions
• L FPO (frame pointer omission, frame pointer omitted) data
• L source file name and row number

Note:

FPO is no longer enabled since XP SP2.

For. Net PDB files, only the following two types of information are contained:

• L source file name and row number
• L local variable name

The. net pdb file contains so little information because other information can be obtained from metadata, so there is no need to store it again.

2. PDB file matching

When you talk about how to load a module to the address space of the current process, the debugger searches for a matching PDB file based on the two information. The first information is clear, according to the module name. For example, if the module you load is "test. dll", the debugger will look for the test. PDB file. However, through the name, it is impossible to determine whether the module and the PDB file are completely matched. The debugger uses the second information to determine-a guid value. This guid value exists in both the module file and the PDB file. If the guid value does not match, we cannotSource codeLevel to debug the program.

The GUID value is put into the file by the compiler and the linker. Currently, we cannot change this value, but we can view the guid value in the compiled file. The tool we use here is dumpbin. We can use it to list information about all PE files. If you have installed vs2008 or vs2010, you can directly start the tool from the vs command line, as shown in 1.

Figure 1 start dumpbin

For command line options of the dumpbin tool, you can refer to the relevant documentation. Here we use ITS/headers option to see what results will be output.

Before using dumpbin, we first create a console program. The content is as follows:CodeList 1.

Code List 1 sample program

Using system;

Using system. Collections. Generic;

Using system. LINQ;

Using system. text;

Namespace dumptest

{

Class Program

{

Static void main (string [] ARGs)

{

}

}

}

Compile the code in Listing 1, as shown in file 2 in the OBJ directory.

Figure 2 files in the OBJ directory

File Content 3 in the bin directory.

Figure 3 files in the bin directory

After the preparation is complete, we now switch from the command line to the bin directory and execute the "dumpbin/headers dumptest.exe" command. The result is shown in code list 2.

Code List 2 dump view headers results

E: \ test \ C # \ dumptest \ OBJ \ x86 \ debug> dumpbin/headers dumptest.exe

Microsoft (r) COFF/PE dumper version 10.00.30319.01

Copyright (c) Microsoft Corporation. All rights reserved.

Dump of file dumptest.exe

PE signature found

File Type: executable Image

File header values

14C machine (x86)

3 Number of sections

4e92a178 time date stamp mon Oct 10 15:40:40 2011

0 file pointer to symbol table

0 Number of symbols

E0 size of optional Header

102 Characteristics

Executable

32 bit word Machine

Optional header values

10b magic # (pe32)

8.00 linker version

800 size of code

800 size of initialized data

0 size of uninitialized data

272e entry point (0040272e)

2000 base of code

4000 base of data

400000 Image Base (00400000 to 00407fff)

2000 section alignment

200 file alignment

4.00 operating system version

0.00 image version

4.00 subsystem version

0 Win32 version

8000 size of Image

200 size of headers

0 checksum

3 subsystem (Windows Cui)

8540 DLL Characteristics

Dynamic Base

NX compatible

No structured exception handler

Terminal Server aware

100000 size of stack reserve

1000 size of stack commit

100000 size of heap reserve

1000 size of heap commit

0 loader flags

10 number of directories

0 [0] RVA [size] of export directory

26d4 [57] RVA [size] of import directory

4000 [588] RVA [size] of Resource Directory

0 [0] RVA [size] of exception directory

0 [0] RVA [size] of certificates directory

6000 [c] RVA [size] of base relocation directory

2668 [1C] RVA [size] of DEBUG directory

0 [0] RVA [size] of architecture directory

0 [0] RVA [size] of global pointer directory

0 [0] RVA [size] of thread storage directory

0 [0] RVA [size] of load configuration directory

0 [0] RVA [size] of bound import directory

2000 [8] RVA [size] of import Address Table directory

0 [0] RVA [size] of delay import directory

2008 [48] RVA [size] of COM descriptor directory

0 [0] RVA [size] of reserved directory

Section header #1

. Text name

734 virtual size

2000 virtual address (00402000 to 00402733)

800 size of raw data

200 file pointer to raw data (00000200 to 000009ff)

0 file pointer to relocation table

0 file pointer to line numbers

0 Number of relocations

0 Number of line numbers

60000020 flags

Code

Execute read

Debug Directories

Time type size RVA pointer

--------------------------------------

4e92a178 CV 50 00002684 884 format: RSDs, {99f34c5e-5bc3-4043-ae11-d85f7990af00}, 1, E: \ test \ C # \ dumptest \ OBJ \ x86 \ debug \ dumptest. PDB

Section header #2

. Rsrc name

588 virtual size

4000 virtual address (00404000 to 00404587)

600 size of raw data

A00 file pointer to raw data (00000a00 to 00000fff)

0 file pointer to relocation table

0 file pointer to line numbers

0 Number of relocations

0 Number of line numbers

40000040 flags

Initialized data

Read Only

Section header #3

. Reloc name

C virtual size

6000 virtual address (00406000 to 0040600b)

200 size of raw data

1000 file pointer to raw data (00001000 to 000011ff)

0 file pointer to relocation table

0 file pointer to line numbers

0 Number of relocations

0 Number of line numbers

42000040 flags

Initialized data

Discardable

Read Only

Summary

2000. reloc

2000. rsrc

2000. Text

Now we will focus on the italic bold part in code list 2. Here we can find the debugging path information, a guid value (99f34c5e-5bc3-4043-ae11-d85f7990af00) and a path (E: \ test \ C # \ dumptest \ OBJ \ x86 \ debug \ dumptest. PDB ). Now we know how the debugger judges whether the PDB file matches. Let's look at how the debugger looks for the PDB file.

3. PDB file path finding

If we observe vs's process of starting debugging and Loading modules and symbol files, we will find that it usually loads symbol files from the same directory of executable files or DLL files. This is the first choice for the debugger to find the PDB file.

What happens if a matched PDB file cannot be found in the same directory of the module file? As mentioned above, the compiler hardcoded a path in the PE file (for example, E: \ test \ C # \ dumptest \ OBJ \ x86 \ debug \ dumptest. PDB), this path is the second choice of the debugger. For applications released externally, the PDB file may not be found in both paths. In this case, the debugger searches for the PDB file in the cache path of the local symbol server. If the cache path of the local symbol server still cannot be found, it searches for the symbol file in the symbol server configured by the debugger. Figure 4 shows the UI for configuring the symbol server and local symbol cache path in vs2010.

Figure 4 configure symbol storage in vs2010

4. PDB and GAC

The method used by the debugger to search for PDB files in most cases works well. When we encounter a GAC file that must be explained after the preparation, the situation becomes interesting. When we compile and debug the Assembly locally, the debugger can still find the PDB file in the compilation directory even if the assembly is installed in GAC, however, if we have deployed the private build application on another machine, we also want to debug the Assembly installed on the deployed machine to GAC, it will be very troublesome. We have two solutions to solve this problem.

Note:

Differences between private build and public build

Private build: indicates the build generated on the developer's own machine; Public build indicates the build generated on the public build machine. 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.

The first solution is to find the installed assembly in the GAC directory and copy the PDB file to the directory. Generally, program Assembly installed in GAC exists in a path similar to C: Windows \ Assembly \ gac_msil \ example \ 1.0.0.0 _ 682bc775ff82796a, in the example directory, "example" indicates the Assembly name, "1.0.0.0" indicates the version number, and "682bc775ff82796a" indicates the public token of the Assembly. When you find the exact directory and put the PDB file under the directory, the debugger can load the symbol file.

A better solution is to set a system environment variable named "devpath. This environment variable sets a disk directory as its value. This directory will exist as the auxiliary directory of GAC, And the directory will also be searched when you find the Assembly in GAC. However, in such a directory, the Assembly does not execute version check, which is worth attention.

To use devpath, we first need to select a directory, and then ensure that the application has read and write permissions on it. Then, create the devpath system environment variable. Of course, this is only preparation. We also need to inform the. NET runtime that the application enables devpath as the GAC extension directory. So next we will add the following configuration in the configuration file (App. config, Web. config, Machine. config:

<Configuration>
<Runtime>
<Developmentmode implements installation = "true"/>
</Runtime>
</Configuration>

After you enable the development mode, if the devpath is not defined or the path does not exist, it will cause an exception "invalid value for registry" during program startup ". If you enable devpath in machine. config, all other programs will be affected. Therefore, use machine. config with caution.

5. PDB and source files

Now let's discuss another question that developers often ask: how is the source file stored in the PDB file? For public build, the PDB File Stores commands for getting source code from the code cache using the version control tool. For private build, it is clear that the symbolic file stores the complete path of the source code.

Ideally, for public build, the operations of caching source code indexes and symbols to the symbol server are automatically executed. We do not need to consider where the source code and symbol files are stored. In fact, many development teams do not have a common symbolic server or source code Indexing Service. For a small project, each developer has enough disk space to store source code and symbol files. This issue may not be considered too much. However, there may be a scenario where 30 mb of source code needs to be placed on the C drive for transferring a private build project to another machine. But at this time, the C drive only has 20 mb of space. What should I do? Can we modify the source code path in the PDB file?

We mentioned earlier that there is no way to modify the PDB file, but here is a clever way to try. The so-called mountain does not come to me, and I am walking to the mountain. Here, a tool can be deployed on the application site, which is a command line tool provided by windows and can be started from the CMD window.

Note:

SUBST is used for path replacement. If the path is associated with the drive letter, a directory is regarded as a disk drive, but cannot be formatted. With some tips, The SUBST command can also hide the drive, install special software, and run the simulated disc automatically.

Format

1. SUBST [drive letter] [path] replaces the specified path with the drive letter, which will be used as the drive

Ii. Replacement of SUBST/d

3. Enter SUBST without adding any parameters to display the current Virtual Drive list.

[Example]

C: \ dos> SUBST a: C: \ Temp virtualizes c: \ Temp into disk

C: \> SUBST a:/D? Release substitution

 

Have you thought of a solution to the above problem? We only need to virtualize the path of the local source code into a disk, such as M. After you deploy the code on any machine, you only need to virtualize the deployed path to M, there will be no mismatch between the symbol file and the target code.

The PDB files are still rare on the Internet. I am here to discuss them with you.