WinDbg Introductory Tutorials

WINDBG Introductory Tutorials introduce

In my career, I've seen that most of us use Visual Studio for debugging, not many other free debuggers. You may have many reasons to use such a debugger, such as not having a development environment installed on your home machine, but a program crashes over and over. In fact, according to the stack dump can determine whether IE crash is due to a third-party plug-in.

For WinDbg, I haven't found a good QuickStart tutorial so far. This article discusses the use of WinDbg in combination with examples. Let me first assume that you are familiar with the basic concepts of debugging: Stepping in, stepping out, breakpoints, and remote debugging.

Note that this would have been an introductory document for seating, which you can read and start using WinDbg. If you have questions about a particular command, consult the WinDbg documentation. You can use the commands mentioned in this article in any debugger provided by Microsoft, for example, in the VS command line window.

This article is based on WinDbg 6.3.

This is just the first of a series of articles on debugging technology. In the next article, I'll explain how to write an extension DLL for the debugger. Debugger Overview

Here's a description of the debugger you can download from the Microsoft website:

· Kd-the kernel debugger. You can use it to debug a blue screen type of system problem. If you are developing a device driver, it is unavoidable.

· cdb-Command Line Debugger. This is a command-line program.

· Ntsd-nt the debugger. This is a user-mode debugger that you can use to debug user-mode applications. It is actually a CDB Windows UI enhancement.

· windbg-the KD and ntsd with a nice UI. WinDbg can debug kernel mode or debug user-mode programs.

· VS, vs.net-uses the same debugging engine as KD and NTSD, and provides a richer interface than the same windbg for debugging purposes. comparisons 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
Attaching to processes	Y	Y	Y	Y
Detach from process	Y	Y	Y	Y
SQL debugging	N	N	N	Y

WINDBG

WinDbg actually packs 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 a crash file (-Z). It supports three different types of commands.

· Regular commands (for example: K) is used to debug a process

· The Dot commands (for example:. Sympath) is used to control the debugger

· Extension commands (for example:!handle)-These commands are custom commands that can be used to add to WinDbg, and they are implemented using an extension DLL's output function. PDB Files

The PDB file refers to the linker Generator database file (program databases files). Private PDB files include private and public symbols, source code line numbers, types, local, and global variables. The public PDB file does not contain types, local variables, and source code line number information.

Debugging Scenarios Remote Debugging

It is easy to use WinDbg for remote debugging, and there are a number of possible ways. In the following, 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.

· Using the debugger: You need CDB, NTSD, or WinDbg already installed on the remote machine. The WinDbg client can connect to either CDB, NTSD, or WinDbg as a server, and vice versa. TCP or Named pipes can be selected directly from the client and the server as a communication protocol.

o The server-side boot process:

§windbg–server Npipe:pipe=pipename (Note: Multiple clients can be allowed to connect or

§ from WinDbg internal:. Server Npipe:pipe=pipename (note, connecting a single client)

You can use a variety of protocols to open different service sessions. And a password is available to protect a session.

O Connect from client:

§windbg-remote Npipe:server=server, Pipe=pipename[,password=password]

§ From WinDbg Interior: File->connect to Remote session:for connection string, enter Npipe:server=server, Pipe=pipename [, Passwor D=password]

· Use Named pipes as a way to communicate using Remote.exe:Remote.exe. If you are using a command-line interface program, such as KD,CDB or NTSD. You can use Remote.exe to debug remotely. Note: Use @q (not Q) to exit the client without turning off the server.

o to start a service side:

§remote.exe/s "Cdp–p <pid>" test1

O Connect from client:

§REMOTE.EXE/C <machinename> Test1

The test1 above is the name of the named pipe we chose.

The server side displays the command that the client is connecting from and executed. You can use the ' QQ ' command to exit the server, or use File->exit to exit the client. In addition, if you want to do remote debugging, you must belong to the "Debugger User" Group of the remote machine and the server must allow remote connections. Instant Debugging

This is discussed in detail in the "Enabling Postmorten Debugging" section of the WinDbg documentation. In short, you can set the Windbg as the default instant debugger, the command is: Windbg–i. This command actually sets the key value of the Hklm/software/microsoft/windows Nt/currentversion/aedebug in the registry to WinDbg. If you want to set the WinDbg as the default managed debugger, you need to display a registry key that is set as follows: hklm/software/microsoft/. The netframework/dbgjitdebuglaunchsetting is set to 2 hklm/software/microsoft/. Netframework/dbgmanageddebugger set into WinDbg. (Note the startup parameter settings in it)

With JIT settings, a WinDbg is started when an application throws an unhandled exception in a state that is not debugged. 64-bit debugging

All of these debuggers support 64-bit debugging environments on AMD64 and IA64. Debugging a managed application

The WINDBG 6.3 version supports the internal Development code for Widbey (VS2005 and. NET 2.0). NET CLR managed debugging. There is a good discussion in the document for managed debugging. It is important to note that for a managed program, there is no PDB in the sense that it is actually a PDB, but this PDB actually records the concepts of C # code and IL code correspondence and some related information, because all programs are compiled into ILAsm. The debugger queries the required additional information through the CLR.

There are a few things to note:

You can only set breakpoints after the code in the Bracket function has been executed at least once. Only in this way can it be compiled into assembly code. Keep the following points in mind:

· About the complexity of the address of a function and the corresponding breakpoint settings:

o The CLR may discard code that has already been compiled, so the entry address of the function 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 within the application domain of the current thread (the logical thread of the CLR).

A special instance of the O generic may cause the same function to have a different address ...

· The complexity of the data storage layout and the corresponding data checks: The CLR may arbitrarily alter the storage layout of the data at run time, so the offset of a struct member may be changed. The data layout that is actually determined when a type is loaded is not changed. A type of information is loaded the first time it is used, so you may not be able to view a data member if it has not been used.

· Complications of Debugger Commands

o When tracking managed code, you will need to pass through large sections of the CLR's own code, such as the JIT compiler, for the first time you have entered a function, or you have switched between managed and unmanaged code. Debugging Windows Services

With WinDbg, you can debug a Windows service program as you would any other application. That is, you can start the Windows service by attaching the process, or you can treat WinDbg as an instant debugger, call DbgBreakPoint or DebugBreak in your code, or add an int 3 assembly instruction to the x86 machine. Debug Exceptions

A debugger gets two exception notifications-the first time before an application has an opportunity to handle an exception (' Chance exception '); If the application does not handle this exception, the debugger will have a chance to handle the exception (' Second-chance Exception '). If the debugger does not handle an exception with two chances, the application exits.

. lastevent or, the!ANALYZE–V command shows you the record of the exception and the stack trace of the function that the exception throws.

You can also use the. EXR,. CXR and. ECXR commands to display exceptions and context records. Also note that you can also change the processing options for first-chance. The corresponding commands are: Sxe, Sxd, Sxn and SXi.

Can I ask you a question:
My WinDbg cannot set breakpoints, and there are always a few loading failures when reloading symbols files, symbols the settings for file path are:
Srv*c:/symbols*http://msdl.microsoft.com/download/symbols.
Similar environment variables are also set, but how to do it, and there is no good advice.

Use; separate symbols file path, for example:
D:/DEV/SRC; Srv*c:/symbols*http://msdl.microsoft.com/download/symbols

the function of WinDbg Debugger Extension DLL

the so-called extension refers to some DLLs that you can use to invoke and execute some custom commands within the debugger. These DLLs must implement certain functions and satisfy some requirements in order to be considered an extension DLL. In the next article, we'll learn how to write an extension DLL. The so-called bang (!) A command is a command that is executed from within your extension DLL. Note that these DLLs are loaded into the debugger's process space. memory dump file

You can use the Dump feature to get snapshot information for a process. A mini-dump is usually relatively small unless you use a full memory minidump (. dump/mf). It is also useful to be able to dump handle information, which is the command. Dump/mfh. A small dump typically contains a stack of all threads and a list of modules that have been loaded. A full dump contains more information, such as a heap of processes. Crash Dump analysis

If your Windows system is a machine, it will store data in physical memory and all process information in a single file. Can be configured with control Panel->system->advanced-> ' Startup and Recovery '. You can also first configure the WinDbg as an instant debugger, and then you can get the dump (. dump) of any process that is not normally terminated. Note that the analysis of bugs in the code from the dump file is often a complex and laborious process.

Use the following steps to parse a dump file:

1 in WinDbg, point to dump file by file-> ' Open Crash dump '.

2 WINDGB will show you the instructions that are executed when the application crashes.

3 correctly set your symbol file directory and source code directory. If you are not able to match the correct symbol file, it is very difficult to figure out the logic of the program. If you can match the symbol file to the correct version of the source code, it should be easy to analyze the cause of the bug. Note that the private symbol file contains line number information and will blindly display the corresponding line in your source code without any checking; If your source version is not correct, then you will not be able to see the right source for the matching assembly code. If you only have a public symbol file, you will see the last called function (on the stack).

Note that debugging-driven or managed code is very different from this. Refer to the Windows Device Driver book for debugging device-driven technology. Common set symbol files and folders for WinDbg

If you want to debug more effectively, you need a symbol file. The symbol file can be an old-fashioned COFF format or PDB format. The PDB is the program database file and contains the public symbols. Within these debuggers, you can use a series of addresses to let the debugger look for symbols for binary files that have already been loaded.

Symbol files for the operating system are generally stored in the%systemdir%symbols directory. The symbol file for the driver (. DBG or. PDB are typically stored in the same directory as the driver file (. sys file). The private symbol file contains information such as functions, local and global variables, and the line number information used to correlate the assembly code with the source code; For customers, the symbol file is half public-the files only include public members.

You can set the symbol file directory by using File-symbol file path, or use the. sympath command. If you want to add a reference to a symbol file on your network, add the following 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 to the store. Note that this symbolic server only opens up public symbol files.

when the debugger puts a binary file (DLL or EXE), he checks for such things as file names, timestamps, and checksum values. If you have symbolic information, you can see the function names and their arguments on the call stack. If binaries and PDB files 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 path by File->source File path, or use the. Srcpath command. If you set the path of the code, when you debug, the debugger will be through the PDB file line number information to display the matching source code. breakpoints, tracking

· Set a soft breakpoint by using the BP command or a breakpoint picture on the toolbar.

· Set a hard breakpoint by code such as DbgBreakPoint () or Kdbreakpoint ().

         Use trace functions in extension DLLs Dbgprint, Kdprint, OutputDebugString To display the output in the WinDbg Output window.