Windbg getting started tutorial

Several references:
Windbg
Http://help.wugnet.com/vista/collecting-Crash-dump-vista-ftopict24054.html
Http://www.eggheadcafe.com/conversation.aspx? Messageid = 31157261 & threadid = 31157181
Http://www.codeproject.com/KB/debug/windbg_part1.aspx
Http://www.codeproject.com/KB/debug/cdbntsd.aspx
Http://guide.it168.com/files/22620/22620.html

The sogou search engine is also good. You can find a lot of things that Baidu cannot find!
Pin it down! After all, the two databases are different!

 

Windbg getting started tutorial
From the red black guest Union (www.7747.net) Original: http://www.7747.net/Article/200812/31157.html

Introduction
In my career, I saw that most of us use Visual Studio for debugging, rather than using many other free debuggers. You may have many reasons to use such a debugger. For example, you do not have a development environment installed on your home machine, but a program crashes again and again. In fact, based on the stack dump, you can determine whether the IE crash is caused by a third-party plug-in.

For windbg, I have not found any quick start tutorials. This article discusses the use of windbg in combination with examples. First, let me assume that you are familiar with the basic concepts of debugging: stepping in, stepping out, breakpoint, and remote debugging.

Note: This is a getting started documentation for the seats. You can read and start using windbg. If you have any questions about specific commands, please refer to the windbg documentation. You can use the commands mentioned in this article in any debugger provided by Microsoft, such as in the command line window of.

This article is based on windbg 6.3.

This is only the first article in a series of articles about debugging technology. In the next article, I will explain how to write extension DLL for the debugger.

Debugger Overview
The following describes the debugger you can download from the Microsoft Website:

· KD-kernel debugger. You can use it to debug system problems such as blue screens. It is indispensable to develop a device driver.

· CDB-command line debugger. This is a command line program

· NTSD-NT debugger. This is a user-mode debugger that can be used to debug user-mode applications. It is actually a Windows UI enhancement for CDB.

· Windbg-wrapped kD and ntsd with a beautiful UI. Windbg can debug the kernel mode or user mode programs.

· Vs, vs.net-uses the same debugging engine as KD and ntsd, and provides richer interfaces than windbg for debugging purposes.

Comparison between debuggers
Function
KD
Ntsd
Windbg
Visual Studio. NET
 
Kernel mode debugging
Y
N
Y
N
 
User mode debugging

Y
Y
Y
 
Unmanaged debugging
Y
Y
Y
Y
 
Managed debugging

Y
Y
Y
 
Remote debugging
Y
Y
Y
Y
 
Attach to process
Y
Y
Y
Y
 
Detach from process
Y
Y
Y
Y
 
SQL debugging
N
N
N
Y
 

Windbg
Windbg actually encapsulates ntsd and KD and provides a better user interface. It also provides command line switches, such as minimizing startup (-m), attaching to a PID-Specified Process (-P), and automatically opening the crashed file (-Z ). It supports three types of commands.

· Regular commands (for example, k) is used to debug processes.

· Dot commands (for example,. sympath) is used to control the debugger.

· Extension commands (for example :! Handle)-These commands are custom commands that can be added to windbg. They are implemented using the output functions of the extended DLL.

PDB File
The PDB file refers to the program database files generated by the linker ). Private PDB files include private and public symbols, source code line numbers, types, local variables, and global variables. Public PDB files do not contain types, local variables, and source code line numbers.

Debugging scenario
Remote debugging
It is easy to use windbg for remote debugging, and there are many feasible methods. In the following section, the 'debug Server' refers to the debugger running on the remote machine you want to debug. 'Debug client' refers to the debugger that controls the current session.

· Use the debugger: You need to install CDB, ntsd, or windbg on a remote machine. The windbg client can be connected to any CDB, ntsd, or windbg as a server, and vice versa. You can directly select TCP or named pipe as the communication protocol on the client and server.

O Startup Process on the server:

§ Windbg-server npipe: pipe = pipename (Note: multiple clients can be connected or

§ From inside windbg:. Server npipe: pipe = pipename (Note: connect to a single client)

You can use multiple protocols to enable different service sessions. A password can be used to protect a session.

O connect from the client:

§ Windbg-remote npipe: Server = server, pipe = pipename [, password = PASSWORD]

§ From inside windbg: file-> connect to remote session: for connection string, enter npipe: Server = server, pipe = pipename [, password = PASSWORD]

· Use remote.exe: remote.exe to use the Named Pipe for communication. If you are using a command line interface program, such as KD, CDB, or ntsd. You can use remote.exe for remote debugging. Note: Use @ Q (not Q) to exit the client. You do not need to disable the server.

O start a server:

§ Remote.exe/s "CDP-P <pid>" test1

O connect from the client:

§ Remote.exe/C <machinename> test1

The test1 above is the name of the named pipeline we selected.

The server displays the commands that the client connects to and executed from that server. You can use the 'qq' command to exit the server, or use file-> exit to exit the client. In addition, to perform remote debugging, you must belong to the "Debugger user" group of the remote machine and the server must allow remote connection.

Instant debugging
In the "enabling postmorten debugging" section of windbg, we will discuss this in detail. In short, you can set windbg as the default instant debugger. The command is windbg-I. In fact, this command sets the key value of HKLM/software/Microsoft/Windows NT/CurrentVersion/AeDebug in the Registry to windbg. If you want to set windbg as the default managed debugger, You need to display the following registry key values:

HKLM/software/Microsoft/. netframework/dbgjitdebuglaunchsetting is set to 2
HKLM/software/Microsoft/. netframework/dbgmanageddebugger is set to windbg. (note the startup parameter settings)
Through JIT settings, windbg is started when an application throws an unhandled exception while it is not being debugged.

64-bit debugging
All these debuggers support 64-bit Debugging Environments on amd64 and IA64.

Debugging managed applications
Versions later than windbg 6.3 support debugging hosted by widbey (internal development code of vs2005 and. NET 2.0). Net CLR. This document provides a good discussion of hosted debugging. It should be noted that for a hosted program, there is no PDB as mentioned earlier, but this PDB actually records the correspondence between C # code and IL code and some related information), because all programs are compiled into ilasm. The debugger uses CLR to query the required additional information.

Pay attention to the following points:

You can set a breakpoint only after the code of the token function is executed at least once. Only in this way can it be compiled into assembly code. Remember the following:

The complexity of the function address and the corresponding breakpoint settings:
O clr may discard compiled code, so the function entry address may change.

O the same code may be compiled multiple times, if the code is not shared by multiple application domains. If you set a breakpoint, It will be set in the application domain where the current thread (the logic thread of the CLR) is located.

O generic special instances may lead to different addresses for the same function ..

Complexity of data storage layout and corresponding data check:
CLR may change the layout of data storage at runtime, so the offset of a struct member may be changed. in fact, the data layout is determined when a type is loaded, and will not change afterwards .)
A type of information is loaded when it is used for the first time, so you may not be able to view a data member if it has not been used.
Complexity of Debugger commands
O when tracking and hosting code, you will need to traverse the large segment of CLR's own code, such as the Code of the JIT compiler, probably because you entered a function for the first time, or you can switch between hosted and unmanaged code.

Debug Windows Services
With windbg, You can debug Windows service programs as you debug other applications. That is, you can start the Windows service by attaching a process, or use windbg as an instant debugger, and call dbgbreakpoint or debugbreak in the code, or add an int 3 Assembly command to the x86 machine.

Debugging exception
A debugger will receive two exception notifications-the first time before the application has the chance to handle the exception ('first chance exception'); If the application does not handle this exception, at this time, the debugger will have a chance to handle exceptions ('second-chance exception '). If the debugger does not handle a secondary exception, the application exits.

. Lastevent or ,! The analyze-V command will show you the exception record and the stack trace information of the function where the exception is thrown.

You can also use the. EXR,. cxr, And. ecxr commands to display exceptions and context records. You can also change the first-chance processing options. The corresponding commands are: sxe, sxd, sxn, and sxi.

Functions of windbg
Debugger extension DLL
The so-called extension refers to some DLL. You can call and execute some custom commands in the debugger. These dll must implement some specific functions and meet some requirements to be considered as an extension DLL. In the next article, we will learn how to write an extended DLL. The so-called bang (!) A command is a command executed from your extension DLL. Note that these DLL files are loaded into the process space of the debugger.

Memory Dump File
You can use the dump function to obtain the snapshot information of a process. A mini-dump is usually relatively small, unless you use a full-memory minidump (. Dump/MF ). The command is. Dump/MFH. A small dump usually contains the stacks of all threads and a list of loaded modules. A full dump contains more information, such as the heap of a process.

Crash Dump Analysis
If your windows system is on the machine, it will dump data in the physical memory and all process information in a file. You can configure it through control panel-> system-> advanced-> 'startup and recovery. You can also configure windbg as an instant debugger first, and then you can get a dump of any abnormally terminated process ). Note: analyzing the bugs in the code from the dump file is often a complicated and laborious process.

To analyze a dump file, follow these steps:

1) In windbg, point to the dump file through file-> 'open crash dump.

2) windgb will show you the commands executed when the application crashes.

3) correctly set your symbol file directory and source code directory. If you cannot match the correct symbol file, it is very difficult to figure out the program logic. If you can match the symbol file to the source code of the correct version, it is very easy to analyze the cause of the bug. Note that private symbolic files contain line numbers and will blindly display the corresponding lines in your source code without any check; if your source code version is incorrect, then you cannot see the correct source code that matches the assembly code. If you only have public symbol files, you will see the last called function (on the stack ).

Note that the debugging driver or managed code is very different from this. Refer to the Windows 2000 Device Driver book to obtain the device driver debugging technology.

Common settings of windbg
Symbol files and folders
For more effective debugging, you need a symbolic file. Symbol files can be in the old-fashioned coff format or PDB format. PDB is a program database file and contains a public symbol. In these debuggers, you can use a series of addresses to find the symbols of the loaded binary files.

The operating system symbol files are generally stored in the % SystemDir % symbols directory. The symbolic file (. dbg or. PDB) of the driver is generally stored in the same directory as the driver file (. SYS file. Private symbol files contain information such as functions, local and global variables, and line numbers used to associate assembly code with source code. For customers, half of symbol files are public-these files only include public members.

You can use file-symbol file path to set the directory of the symbolic file, or use the. sympath command. If you want to add a reference to a symbolic file on the network, add the following content to your. sympath

SRV * downstream_store * http://msdl.microsoft.com/download/symbols

The command used is:

. Sympath + SRV * C:/tmp * http://msdl.microsoft.com/download/symbols

C:/tmp is download_store, and the required symbol files are downloaded and stored to this point. Note that this symbolic server only opens public symbolic files.

When the debugger runs a binary file (DLL or EXE), it checks such files, timestamps, and checksum values. If you have symbolic information, you can view the function name and their parameters on the call stack. If both the binary file and the PDB file come from your own application, you can see additional information such as private functions, local variables, and types.

Source code path
You can set the source code path through file-> source file path, or use the. srcpath command. If you have set the code path, when debugging, the debugger displays the matched source code through the line number information of the PDB file.

Breakpoint, tracking
· Use the BP command or the breakpoint image on the toolbar to set soft breakpoints.

· Set a hard breakpoint through Code such as dbgbreakpoint () or kdbreakpoint.

· In extended DLL, use the tracking functions dbuplint, kdprint, and outputdebugstring to display the output in the windbg output window.

From the red black guest Union (www.7747.net) Original: http://www.7747.net/Article/200812/31157.html