WINDOW10 using WinDbg and Virtual machine (WINDOW7) in the Debug driver establishment method

Think of their own WinDbg configuration is reproduced: Eqera Windows kernel Debug configuration, really benefit a lot of hope he won't mind I reproduced his blog, helped me a lot, recorded down to me also to everyone,

One of the main things I'm looking at is the build of the pipe of VMware, and I share some of the DDK in the vs2015, and then in the Start Menu window kits see windbgx86 or the type you want to use, and

Sending a shortcut to the desktop facilitates later use. After you send it to the desktop, insert the path to the symbol you placed in the attribute, and let's not forget to check the path in WinDbg.

Eqera His explains gave me a lot of help, can read patiently. Next time I will write some of my things for debugging, if for the path settings do not understand, can give me a message, I tell you.

WinDbg Local debugging tool is a driver-level debugging tool, in the WIN10 system debugging process involves the system driver, so with WinDbg is the best choice. In general, drive commissioning requires two computers to mate

A computer as the leading driver debugging, another computer as a target machine to drive the installation.

Kernel debugging is mainly used to debug driver code, analyze kernel structure and so on. WinDbg can be debugged with two computers, one of which is shipped
Line WinDbg, known as the host, and another computer running the program or system being debugged, is called the target machine. In general, both computers are real machines.
, so debugging the most in line with the actual situation, two computers through the serial line, 1394-wire or USB line connected to achieve the dual-machine core debugging. If not
Two computers, can also use virtual machine to simulate the target machine, run WinDbg on the host, install Windows in virtual machine to run the program that is debugged, virtual
The machine through the analog serial port output is a named pipe on the main machine, thus connects with the WinDbg on the host to realize the dual-machine kernel debugging.
In addition to the two-machine kernel debugging, windowsxp also introduced a native kernel debugging method, only need a computer, directly run WinDbg can
View changes to the system kernel structure, etc., but all commands related to the interrupt target system cannot be executed, such as breakpoint commands.
If the virtual machine is used to simulate the target machine, debugging response speed is sometimes a problem, compared to the 1394-wire connection of the real two-machine debugging speed is much slower, special
Not a command that performs large amounts of memory (such as a Search memory command), it feels very star. Therefore, a special auxiliary debugging is also introduced for this situation.
Tool VMKD, this tool can greatly speed up the kernel debugging, bring us a lot of convenience.
The following sections describe the configuration of various kernel debugging scenarios in detail, as described in each step.

Real machine dual-machine kernel debugging

The kernel debugging between the real machine first needs to prepare the connection line, can use the serial line, 1394 line or the USB couplet line.
Serial line speed is too slow, and the computer city generally can not buy the serial line directly used, need to put the wire and the connector to buy their own welding, according to WinDbg
The instructions in the Help cross-weld, you can get a serial line that can be used for debugging. Use the serial cable to connect the two computers, the first with Windows comes with the
HyperTerminal tool, choose a good serial port and baud rate connection. If you press the key in HyperTerminal to display the key on another computer's HyperTerminal, it means
The serial cable is connected successfully. Next, you can use WinDbg to connect the serial debugging. Some notebooks may not have a serial port, you can buy a USB to the serial port
Connector, and then set the USB converted serial number, you can use this notebook as a host.
1394 line speed, price is also cheap, if there is no 1394 on the computer, you can buy another 1394 card, the price is very cheap. 1394 min
Big mouth and small mouth, just follow the computer's interface size to buy the right line on the line. If there is no 1394, it is troublesome to pack a 1394 card, you can also
To buy a USB to 1394 port connector, but the same can only be used as a host.
USB couplet line is the Vista system after the support of the kernel debugging connection mode, did not see where to buy such a line, the estimated speed will be faster!
Because the 1394-wire connection debugging is the most convenient and faster, so it is recommended to use this method.
When the computer, cable, etc. are ready, set the target system to enable the kernel debug engine embedded in the system. Vista before the system, with Notepad
Open the boot. ini file under the system's packing directory, add a new startup item, and add debugging options to the new startup item. As shown in the table below, the red line indicates the newly added
Startup item,/debug indicates that the kernel debug engine is turned on,/debugport=1394 represents a 1394 connection,/channel=10
Logos is 10.

[CSharp]View PlainCopy

1. [Bootloader]
2. Timeout=30
3. Default=multi (0) disk (0) rdisk (0) partition (1) \ Windows
4. [Operatingsystems]
5. multi (0) disk (0) rdisk (0) partition (1) \windows="Microsoftwindowsxpprofessional"
6. /noexecute=optin/fastdetect
7. multi (0) disk (0) rdisk (0) partition (1) \windows="Winxp-debug"/noexecute=optin/debug
8. /debugport=1394/channel=10

After Vista, the system needs to modify the BCD database, use the Bcdedit tool to add startup items, and set debug options. As shown in the following table, administrator-style

Run the command-line program, copy the current item to generate a new startup item, then operate on the new startup item, open kernel debugging, set the debug connection mode,
1394 channel number.

[CSharp]View PlainCopy

1. c:\>bcdedit/copy{default}/d"Vista-remotedebug"
2. The item was successfully copied to {13FBBEDC-756A-11DC-AED8-0016E68BCEB3}.
3. c:\>bcdedit/set{13fbbedc-756a-11dc-aed8-0016e68bceb3}debugtype1394
4. The operation completed successfully.
5. c:\>bcdedit/Set{13fbbedc-756a-11dc-aed8-0016e68bceb3}channel10
6. The operation completed successfully.
7. C:\>bcdedit/debug{13fbbedc-756a-11dc-aed8-0016e68bceb3}on
8. Operation completed successfully

After setting the target system reboot, stop when the boot menu is selected, run WinDbg on the host with the following command line ready to connect to the target machine

[CSharp]View PlainCopy

1. d:\windbg>windbg-d-k1394:channel=10

-d means to interrupt immediately after the target system is connected, this is also the earliest breakpoint, this option is mainly to break down in the early stage of the target system initialization
Check the system status, the current situation can not, 1394:channel=10 represents the connection method and the channel number. When debugging for the first time with 1394 cores,
WinDbg may show a boot drive failure and running WinDbg again should be good. After running WinDbg, the following interface is displayed:

Indicates that WinDbg is ready to wait for 1394 connections. Then go back to the target machine and select the boot item you added earlier (that is, kernel debugging is turned on
option), such as a real machine, which is replaced with a virtual machine.

When this startup item is selected, the kernel is loaded, the kernel debug engine is initialized, and in a few seconds it is possible to see the output message on the host's WinDbg
WinDbg, such as (when writing this article or using the virtual machine, hehe):

You can see that the WinDbg display is connected to the windowsxp system and displays information such as the symbol path, the kernel base address, and then interrupts to get control
Control, enter the K command to see the current call stack, enter the G command to allow the target system to continue to boot. After you start debugging, you can press the WinDbg at any time

Ctrl+break the target system with a key combination or through a toolbar button.

If you are not accustomed to command-line mode when you run WinDbg earlier, you can open WinDbg first, and then choose menu File/kerneldebug Open
Kernel Debug Connection dialog box, switch to the second "1394" tab, enter the channel Number 10 in the edit box below the channel, and click "OK" to press
button to start connecting to the target machine.

This is the same as the previous command line run WinDbg effect, is not the-D option, you can wait for the connection of the interface to press two times Ctrl+alt+k key combination
Achieve the same effect

Real machine with 1394 debugging, if the target system is Windows2003 (not installed servicepack) or WINDOWSXPSP 1,
Before you connect to debug, you need to disable the 1394 controller in Device Manager on the target machine. If the target is Vista, WINDOWS2003SP1
or WindowsXPSP2 system after the system, do not disable the 1394 controller. Also, if the host is a pre-vista system, use 1 394
There is a problem with the connection while debugging, you can try disabling the 1394 network adapter in Device Manager on the host.

Virtual machine dual-machine kernel debug

The real machine after all hardware cost is high, needs two computers, also must buy the connection line. If the debugging requirements are not high, in many cases the virtual machine can be used to simulate the target
Machine, and realize the debug of dual-machine kernel. There are two types of virtual machines currently in use: VMware and VIRTUALPC, all with a free version that runs at the same speed as the master
About half the machine. It is estimated that everyone is a dual-core computer and running a virtual machine is no problem. VMware seems to be a little faster and provides
The snapshot feature is very convenient, you can restore the system to a previously saved state at any time. VIRTUALPC seems to be better compatible, sometimes in VMware
Install the system on the blue screen, with VIRTUALPC is no problem.
The first is to choose the connection mode, with the virtual machine only a serial port method, through the virtual machine analog serial port output to the host named pipe, and then
WinDbg connects this named pipe to the host and virtual machine.
After installing the system in the virtual machine, turn off the virtual machine system and open the Virtual machine system settings box, as in VMware:

Select Editvirtualmachinesettings to open the Settings dialog box:

First select Add ... button to add the serial device, and then follow the settings serial property. Named pipe name is required for WinDbg connection
Pipe name, \\.\pipe\ prefix is not small, followed by an easy-to-understand name.
VIRTUALPC virtual machine is similar, first install the system, select the system, click the Settings button:

Open the Virtual Machine System Settings dialog box, select the COM1 item on the left, and set the named pipe name for the output on the right.

After you set up the hardware connection mode (here is the virtual hardware), start the system in the virtual machine and add the Debug startup item. Because the virtual machine is just a virtual serial port,
So you can only use the serial port when setting up system startup items. Vista's previous system was implemented by modifying the boot. ini file, as in the following table. A red item indicates a new addition
/debug indicates that the kernel debug engine is turned on,/debugport=com1 indicates that serial 1 communication is used,/baudrate=115200
The baud rate of the serial port 1 is 115200.

[CSharp]View PlainCopy

1. [Bootloader]
2. Timeout=30
3. Default=multi (0) disk (0) rdisk (0) partition (1) \ Windows
4. [Operatingsystems]
5. multi (0) disk (0) rdisk (0) partition (1) \windows="Microsoftwindowsxpprofessional"
6. /noexecute=optin/fastdetect
7. multi (0) disk (0) rdisk (0) partition (1) \windows="Winxp-debug"/noexecute=optin/debug
8. /debugport=com1/baudrate=115200

After Vista, open a command-line window with administrator privileges, and modify the BCD data by Bcdedit tools to add startup items.

[CSharp]View PlainCopy

1. c:\>bcdedit/copy{default}/d"vista-remotedebug-1394"
2. The item was successfully copied to {13FBBEDC-756A-11DC-AED8-0016E68BCEB3}.
3. c:\>bcdedit/set{13fbbedc-756a-11dc-aed8-0016e68bceb3}debugtypeserialdebugport:1
4. baudrate:115200
5. The operation completed successfully.
6. C:\>bcdedit/debug{13fbbedc-756a-11dc-aed8-0016e68bceb3}on
7. Operation completed successfully

After setting the startup item, restart the system in the virtual machine, stop when the boot menu item is selected, return to the host, and start WinDbg from the command line.

[CSharp]View PlainCopy

1. D:\windbg>windbg-d-kcom:pipe,port= \\.\pipe\vmdbg_winxpen,baud=115200

Note the name of the pipe as indicated by the red word, which needs to be the same as the settings in the virtual machine. You can also use the menu to open the Kernel Debug Connection dialog box.

Note the pipe name should be the same, select the pipe item, and then OK, WinDbg will start waiting for the connection.

Now return to the virtual machine and select the Debug startup item, and you will see the information in the WinDbg showing the virtual machine on the connection.

Once the connection is established, it is the same as debugging a real machine. Only when debugging certain and special hardware-related drivers, or debugging and 3D games

Related programs, you still have to use the real machine. In addition, running the virtual machine after all affect the host speed, especially when reading the hard disk feel more obvious. And when
WinDbg interrupt the target system, the virtual machine basically the CPU is full, the dual-core is OK, the single-core host is not able to move. Of course debugging
Speed is also a problem, it is supposed to be a computer (virtual machine is also running on the host), transmission speed should be fast. But because the serial port is completely analog,
The serial port design determines that the speed cannot be fast, so the following describes an accelerator tool for virtual machine debugging: VMKD.

VMKD is a tool that the kernel debug master skywing launched, mainly used to speed up the debugging of the VMware kernel, the official website in:
http://www.nynaeve.net/?page_id=168. VMKD is equivalent to taking over the kernel debug engine transport channel, previously: Inside the virtual machine system
Core <-> analog serial port <-> named pipe <->windbg, using VMKD to become: Virtual machine system kernel <->VMKD kernel module kdvmware <->VMKD injection module Vmxpatch <-> new named pipe <->windbg, because the virtual machine does not take the analog serial port to transmit data, but the virtual machine side
Kdvmware and the host side of the Vmxpath directly replicate memory, so the transfer speed is greatly accelerated.

The detailed use steps are as follows:
1. Install the system in the virtual machine and set up the serial debugging as described in the previous section.
2. Copy the Kdvmware.sys from the VMKD to the C:\WINDOWS\system32\drivers directory in the virtual machine and make
Sccreatekdvmwarestart=demandtype=kernelbinpath= with command line
C:\windows\system32\drivers\kdvmware.sysdisplayname=kdvmware install the driver.

3. Restart the system in the virtual machine and select Debug boot entry system.

4. Locate the PID of the Vmware-vmx.exe process that initiated the virtual machine on the host, and use the Vmxinject.exepid command to Vmxpatch. Dll
Inject into the vmware-vmx.exe process

[CSharp]View PlainCopy

1. D:\dbgtools\vmkd>tlist-mvmware-vmx.exe
2. D:\ProgramFiles\VMware\VMwareServer\bin\vmware-vmx.exe-6096vmware-vmx.exe
3. Olemainthreadwndname
4. d:\dbgtools\vmkd>vmxinject6096
5. Ok

5. Start the drive with the Netstartkdvmware command in the virtual machine.

6. Start the system in the WinDbg connected virtual machine on the host computer to start debugging, the Winxpen in the named pipe name is the installation text of the virtual machine system
(For example: D:\VMs\winxpen).

[CSharp]View PlainCopy

1. windbg-kcom:pipe,port=\\.\pipe\kdvmware_winxpen,baud=115200

Named pipe name If you are unsure, you can use the Winobjex tool to view all named pipe names in the system, such as the VM KD
The name of the pipe used.

After connection such as:

At this point, the debugging will find that the step speed is very fast, run a search command s can feel, even. The dump command can be executed very quickly.

Native kernel debugging

Native kernel debugging is a kernel debugging method introduced after windowsxp system, said debugging is actually a bit inaccurate, because there is no single step, broken
Point, such as debugging the necessary functions, only read and write memory. However, it is very convenient to view the system kernel information, it does not need two computers (even the virtual machine
Not required, fully native run), can use most of the WinDbg's own extension commands, can be used on the system after XP, including 32/64
System.

On systems prior to WINDOWS2003SP1, the system passed ntdll! The Zwsystemdebugcontrol function provides native kernel debugging support.
Subsequent systems are invoked via the WinDbg Kldbgdrv.sys driver nt! The Kdsystemdebugcontrol function provides native kernel debugging support.
Official documentation It is recommended that you start the system by adding the/debug option in the startup item, and then use the native kernel debugging feature. But generally don't need to do this, Vista
Prior to the system, you can directly run WinDbg to open the native kernel debugging; Vista and the subsequent 32-bit system can be used by the author of a handyman
With VISTALKD to turn on the native kernel debugging function, and then run WinDbg to open the native kernel debugging; Vista and the subsequent 64-bit system can only be modified temporarily
The startup item adds the/DEBUG option to turn on the native kernel debugging feature.
Starting the native kernel debugging is very simple, plus-KL command line startup WinDbg can be

[CSharp]View PlainCopy

1. D:\windbg>windbg-kl

The display interface is as follows:

You can also run WinDbg after you open the Kernel Debug Connection dialog box, select the Local Options page, click the "OK" button to open the native kernel debugging function

Vista and future systems, remember to first run the VISTALKD tool with administrator privileges, click the Enablelocalkerneldebug button to open the
Machine kernel debug feature, and then run WinDbg with administrator privileges to open native kernel debugging.

Native kernel debugging can do a lot of things, such as view the kernel structure definition, disassembly kernel functions, display kernel hooks and so on.

WINDOW10 using WinDbg and Virtual machine (WINDOW7) in the Debug driver establishment method