What is Windbg?
Windbg is a free source code-level debugging tool developed by Microsoft. Windbg can be used for KERNEL mode debugging and user mode debugging, and you can debug DUMP files. Since most of the programmers don't need to make KERNEL mode debugging, I will not introduce Kernel mode debug in this article. KERNEL mode debugging is very helpful for learning Windows core. If you are interested in this, you can read the help files of Inside Windows 2000 and Windbg.
This article has a primary purpose to introduce the main functions of Windbg and related orders. For detailed grammar on these commands, see the help file. Many commands mentioned in the article, Windbg have the corresponding menu options.
How to get help
Enter .hh life will call up the help file order in the command window.
.hh Keyword
The detailed commands about Keyword will be displayed.
Start Debugger
Windbg can be used in three debugging:
Remote debug: You can striates the program executed on Machine B from the machine A. Specific steps are as follows:
Start a debug session on the machine B. You can run a program directly under WindBG or add WindBG to a process. Start a remote debug interface on the Windbg Command window of Machine B :. Server Npipe: Pipe = PIPE_NAMEPIPE_NAME is the name of the interface. Run on Machine A: Windbg -Remote Npipe: Server = Server_Name, PIPE = PIPE_NAMESERVER_NAME is the name of the machine B.
Dump file debug: If there is a problem on your customer's machine, you may not be able to use remote debugging to solve the problem.
You can ask your user to attach Windbg to the process of problems, then enter: .dump / ma file name in the Command Window Create a Dump file. After getting the DUMP file, use the following command to open it: windbg -z dump_file_name
Local Process Debug: You can under Windbg
Running a program directly: Windbg "path to executable" arguments can also attach Windbg to a running program: windbg -p "process ID" WINDBG -PN "Process Name" Note A non-invasive (Noninvasive) mode can be used Check the status of a process and do not execute. Of course, in this mode, it is not possible to control the execution of the debugged program. This model can also be used to see a process that is already running under Debugger control. The specific command is as follows: windbg-pv -p "process id" windbg -pv -pn "process name"
Commissioning multiple processes and threads
If you want to control a process and the execution of its child process, add -O options on the Windbg command line. There is also a new command in Windbg. Thechilddbg can be used to control the debugging of the child process. If you commission a few processes simultaneously, you can use the | command to display and switch to a different process.
There may be multiple threads in the same process. ~ Command can be used to display and switch threads.
Prerequisites before debugging
The first thing you want to do before starting debugging is to set the Symbols path. No symbols, the call stack you see is basically meaningless. Microsoft's operating system symbol file (PDB) is public. Also note that you choose to generate a PDB file in compiling your own program. If you set a symbol path, call the stack looks still right. You can verify that the symbol path is correct.
Windbg also supports source level debugging. Before starting the source code debugging, you need to set the source code path with .srcpath. If you are debugging on the machine that generates the executed code, the source path in the symbol file points to the correct location, so you do not need to set the source code path. If the executed code is generated on another machine, you can use the source code to copy (maintain the original directory structure) and set the source path to the source code path. The path of the folder. Note If you are remote debugging, you need to use .lsrcpath to set the source path. Static command:
Display Call Stack: After connecting to a debug window, you first want to know is that the program current execution k * command displays the stack of the current thread. ~ * KB will display the call stack of all threads. If the stack is too long, Windbg will only display part of the stack. .Kframes can be used to set the number of default display frames.
Display local variable: Next, do information that is usually displayed with a local variable using DV. Ctrl Alt V can switch to a more detailed display mode. About DV should be noted that the output of DV in the optimized code may be inaccurate. At this time, you can do it is to read the assembly code to find that the value you are interested in is stored in the register or on the stack. Sometimes the current framework (Frame) may not find the data you want to know. If the data is transmitted as a parameter to the current method, you can read the assembly code of one or more frames, it is possible that the data is still on an address of the stack. Static variables are stored in a fixed address, so it is easy to find the value of static variables. .Frame (or double-click in the calling stack window) can be used to switch the current frame. Note that the DV command displays the content of the current frame. You can also observe the value of local variables in the Watch window.
Display class and linked list: DT can display the data structure. For example, DT PEB displays the operating system process structure. The address of the structure will display the details of the structure: DT PEB 7FFDF000.
The DL command can display some specific linked table structures.
Displays the error value of the current thread:! Gle displays the previous error value and status value of the current thread. ! Error command can decode HRESULT.
Search or modify memory: Use the S command to search for bytes, words or double words, QWORD, or strings. Use the E command to modify the memory.
Calculate expression:? The command can be used to calculate. For the format of the expression, please refer to the help documentation. Use the n command to switch the input of the input numbers.
Display current threads, processes, and module information:! TEB displays environmental information for the current thread. The most common use is to view the starting address of the current thread stack, then search the value in the stack. ! PEB displays environmental information for the current process, such as the path to execute files, and more. LM Displays the module information loaded in the process.
The value of the display register: The R command can display and modify the value of the register. If you want to use the value of the register in the expression, add @ symbols (such as @eax) before the register.
Show the most similar symbol: ln address. If you have a pointer to a C object, you can use LN to view the object type.
Find symbol: x command can be used to find the address or process of global variables. The x command supports the matching symbol. X kernel32! * Display all visible variables, data structures, and procedures in kernel32.dll.
View Lock:! LOCKS Displays the lock resource usage of each thread. It is useful to debug the deadlock.
View Handle:! Handle displays handle information. If a code causes the handle to leak, you only need to use it before and after the code! Handle command and compare the difference between the two outputs. There is a command! HTRACE is very useful for the BUG related to the handle. Enter before start debugging:
HTRACE -ENABLE
Then use! Htrace handle_value during the debugging process to display all call stacks related to the handle. Display assembly code: u.
Program execution control command:
Setting code breakpoint: BP / BU / BM can be used to set up code breakpoints. You can specify the number of times the breakpoint is skipped. Suppose a code Kernel32! SetLastError will be wrong after running many times, you can set the following breakpoints:
BP Kernel32! setLastError 0x100.
Use BL to display breakpoint information after an error (pay attention to the value of bold display):
0 E 77E7A3B0 004F (0100) 0: *** kernel32! SetLastError
Restart debug (.restart command) and set the following breakpoints:
BP kernel32! setLastError 0x100-0x4f
Debugger will stop calling the process in the last time before the error.
You can specify the command string that the DEBUGER should execute when the breakpoint is activated. Using the J command in this command string can be used to set the condition breakpoint:
BP `mysource.cpp: 143`" J (POI (MyVar "0N20) ''; 'g'
The above breakpoint is activated only when the value of myvar is greater than 32 (g command
The use of the conditional breakpoint is extremely wide. You can specify a breakpoint only in special cases, such as incoming parameters satisfying certain conditions, the caller is a special process, and a global variable is set to a special value, and so on.
Set internal storage points: BA can be used to set the internal storage point. A common problem in the debugging process is to track changes in certain data. The following breakpoints:
BA W4 0x40000000 "KB; G"
You can print all modified 0x40000000 call stacks.
The control program executes: p, pa, t, ta, etc. can be used to control the execution of the program.
Control anomalies and event processing: Debugger's default settings are the first exception (first chance expression), the execution of the program when the second exception is second. The SX command displays the setting of Debugger. SX and SXD can change the settings of Debugger.
SXE CLR
You can control the execution of the DEBUGER interrupt when managed. Common DEBUGER events are:
AV access exception
EH C abnormal
CLR hosted abnormal
LD module loading
The -c option can be used to specify the debug commands executed when the event occurs.
