Windows debugging tool entry-2 Settings

This article describes the basic settings and basic operation methods of the Windows debugging tool. Here we will use a test program to explain step by step how to start debugging with windbg. Create a console project named testdebug1 with VC and generate it.
1. Configure symbols, source code, and executable image paths 
Before you start debugging with windbg, the most important thing is to configure various environments. This allows the debugger to correctly identify various variables and functions in the debugging target, so that we can perform symbolic debugging or source code debugging, rather than turning around a bunch of assembly code.
First, let's take a look at what it looks like before the environment is set. Use the testdebug1 project just mentioned. To make the comparison clearer, use release for compilation. Select generate map file and debug information in the Link options, as shown below:

 
On the C/C ++ tab, set the following:

 
The program code is as follows:
# Include "stdafx. H"
# Include <stdio. h>
Int main (INT argc, char * argv [])
{
Printf ("testdebug1.cpp ");
Return 0;
}
After compilation, cut testdebug1.pdb under the release directory to another directory (if this is not done, because the compiled program contains the symbolic file path, the debugger can use the information in EXE to find the PDB file without setting the path ). The following content is displayed in the map file:
0001:00000000 _ main 00401000 F testdebug1.obj
Note that the main function is located at the 401000 address.
Open testdebug1.exe In the File> open executeablemenu of windbg. You can see the following content in the debugger command window:

 
As you can see, the position where the debugger is automatically interrupted is not the entry point of the program, which is caused by windbg implementation.
As you can see in the logging command window, we haven't set any symbols, so windbgcannot find any symbol files in testdebug1.exe. If you want to break down the main function, you cannot use symbols, but you can only use the main address directly.
Run the command BP 00401000 to set a breakpoint in the main function, and then the F5 execution will be interrupted to the main entrance. Breakpoint settings and basic operations will be described later. You can see the following content in the Disassembly window:

 
Since no symbols are loaded, we see a bunch of disassembly code and addresses. As mentioned in the previous article, windbg does not have powerful disassembly and analysis capabilities like those of ollydbg debuggers. Therefore, it is difficult to perform debugging simply by relying on the seemingly messy disassembly code.
L symbol path settings
To view the symbols in the program in windbg, you must set the symbol path through the command or windbg menu. If Microsoft public symbol storage is also set, we can not only see the symbols in our program, but also the symbols in the Windows platform code, which is helpful for debugging.
The symbolic path is the directory where the symbolic file containing the program symbolic information is located. The symbol files we usually come into contact with are all suffixed with pdb. If the testdebug1.exe project selects generate debugging information (such as Generate debug info in the Link option set by the Project), you can find its symbolic file testdebug1.pdb In the debug or release directory.
We use the file-> symbol file path… In windbg... Or use the command. sympath to set the symbolic path to the directory where testdebug1.pdb is located. For example, I just moved the generated PDB file to the desktop, so I set it:

 
After that, enter the. Reload command in the Command window. We can see that the content in the Disassembly window has changed:

 
Now we can see the symbols such as functions and variable names in testdebug1.exe. You can also use symbols to operate the debugger using commands such as BP main.
In addition, in the local, watch and other windows, you can also directly use the symbol name to view the variable value, and in the call Stack window, you can see the function name.
L source code path settings
Through the above settings, we can perform symbolic debugging on the program. If you have the program code, you can set the source code path for source code-level debugging.
To continue the above work, we use windbg's file-> source file path... The menu or the. srcpath command sets the path for saving the source code, for example, on my machine:

 
After confirmation, if the current command pointer is within the source file code range, the source file window will automatically pop out. If not, you can use file-> open source file... Manually open the source file. As the breakpoint you just set has not been deleted, you can also see the broken line highlighted in the source code window:

 
After that, you can set breakpoints, view variables, and track code in the source code window. It is much more convenient than only symbols.
L executable image path settings
The executable image path is generally used when debugging dump files. Set this path to the path of executable files such as EXE, DLL, and sys to be debugged. You can use file-> image file path... Set the cmd.exe path command.
L use Microsoft public symbol Storage
In addition to the symbols of your own program, you can also use the symbols of Windows System Code provided by Microsoft for debugging. You need to modify the symbolic path. The most convenient way is to use the. symfix command.
Now let's take a look at the code in kernel32.dll. In the offset column of the Disassembly window, fill in Kernel32! OpenProcess:

 
Note that the call at 764e8ccf can only see the address at a certain offset of the called Kernel32.
Use the command. symfix + D:/symbols. Note that the plus sign must be in the front of the text. D:/symbols is the directory used to save the downloaded symbol file. You can change it to the desired path. In the symbol path window, we can see that the debugger automatically adds some content:

 
You can add these new contents to the source code path to achieve the same effect. For detailed principles, see the section about symbol server settings in the windbg help document.
Next, use the. Reload command again to reload the symbol. the symbol file used for the first time will be automatically downloaded from the internet, so sometimes it will wait for a while. After that, you can see the new symbol content in the Disassembly window:

 
In the command at 764e8cd8, we can see that this is the ntopenprocess function that calls the Kernel32 import.
The Windows symbol provided by Microsoft is an essential tool for us to study the implementation of windows. First, the symbolic name helps the memory during debugging and the identification of various information. Second, the function or variable can often be guessed through the name, which is very convenient for debugging. In various debugging applications, it is strongly recommended to add a reference to the Microsoft public symbol.
L set Environment Variables
All the paths described above can be set through environment variables. Save some commonly used paths in environment variables to avoid the trouble of resetting each time debugging in the new workspace. In addition, Visual Studio 2008 also shares some environment variable settings, so that various symbols can be conveniently viewed during ide debugging. The following are commonly used:

Environment Variable	Function
_ Nt_source_path =Path	Specifies the path of the source code that contains the debugging target.PathCan contain followed by a colon (:. Separate multiple directories with semicolons (;).
_ Nt_symbol_path =Path	Specifies the root directory of the directory tree containing the symbol file.PathCan contain followed by a colon (:. Separate multiple directories with semicolons (;).
_ Nt_executable_image_path =Path	Specifies the path containing the binary executable file.PathCan contain followed by a colon (:. Separate multiple directories with semicolons (;).
_ Nt_debug_log_file_open =Filename	(OnlyCDBAndKD)Specifies the log file that the debugger uses to record the output.
_ Nt_debug_log_file_append =Filename	(OnlyCDBAndKD)Specify the log file that the debugger uses to add output logs. The new content is added to the end of the file each time, instead of overwriting the entire file.

If the environment variable of the symbolic path is set, many symbolic files may be downloaded when many imported programs such as vs 2008 are used to debug MFC in the initial stage, slowing down the debugging startup. However, after a period of time, most of the required symbols will be cached locally and the speed will be faster.
Ii. Configure the log file 
When debugging, the debugger command window may become messy, so you often want to clear it with the. CLs command. However, you will no longer be able to see the results output in the previous debugging process. In addition, you may want to save detailed records of the entire debugging process for "review ". In this case, you need to use the log file. You can automatically record all the content in the debugger command window to the log file.
Create a log file:

( Only CDB And KD)Set the _ nt_debug_log_file_open environment variable before starting the debugger. When you start the debugger, use -LogoCommand line options. For example -Logo D :/Logs/mylogfile.txt use the. logopen command. For example,. logopen/t d:/logs/mylogfile.txt ( Only Windbg)Use the edit-> open/close Log File menu command.

Add logs to the end of an existing file:

( Only CDB And KD)Set the _ nt_debug_log_file_append environment variable before starting the debugger. When you start the debugger, use -LogaCommand line options. For example -Loga D :/Logs/mylogfile.txt use the. logappend command. For example,. logappend/t d:/logs/mylogfile.txt ( Only Windbg)Use the edit-> open/close Log File menu command, and then select Append.

Disable log files:

Use . Logclose Command  
( Only Windbg)Use the edit-> open/close Log File menu command, and then select Close open log file.

3. Set a workspace 
Workspace is a tool used to save the working environment in windbg. For example, the usual window layout mode, symbol path, and Exception Handling settings can all be saved in the workspace. You do not need to set them again during the next debugging.
You can use the windbg menu to complete related settings:
L open workspace: only the workspace that you save through saveas can be opened here.
L save Workspace: saves the current workspace by default. The workspace is automatically opened next time you open the same debugging target.
L save workspace as: You can set the workspace name by yourself, so that you can manually open it through open workspace.
L clear Workspace: You can select the settings to save when saving the workspace.
L Delete Workspace: Delete the currently saved workspace. All the workspace saved and saved by default can be viewed here, which is convenient for cleaning.
L save worlspace in file and open workspace in file: Save the workspace to a file or open it from the file. You can save your workspace so that you can easily use the same settings among multiple machines through USB flash drives.
If the window layout of windbg is adjusted when no debugging target is set, it will be saved as the default workspace. This setting is used next time you open a new target. Generally, we can set a default workspace and save additional settings for each task.