WinDbg common Commands

=
Kd> LN 8046e100
(8046e100) nt! Keservicedescriptortableshadow | (8046e140) nt! Mmsectionextendresource
Exact matches:
Nt! Keservicedescriptortableshadow =

31.!gle View LastError Value

32, the designation of the form of the 0x/0n/0t/y, respectively, the 16/10/8/2 of the input system

? 0x12345678+0n10
Evaluate expression:305419906 = 12345682
33.!sym Noice/quiet symbol prompts switch

34, Srcpath set the path of the source code

35. DV View Local Variables

36.!teb shows the execution block of the current thread (execution block) 37,!peb shows the execution block of the current process (execution block) 38, Ln[address] Displays the object type on the current address

39,!locks Show deadlock

40,!handle can get the whole process or a handle details

Run the following!handle first, and you can see the type of each handle of the current process, as well as the statistical information
0:002>!handle
Handle 4
Type Key
Handle C
Type KeyEvent
.......
Then find a key to see more information
0:001>!handle 4 F
The details of this handle will be listed.
41!htrace command to check the history of an operation handle
The!htrace command can print out the most recent call stacks for the specified handle
0:001>!htrace 384

42.!cs List CriticalSection Details

43,!threadpool can see the completion port, the line Castle worker thread and timer callback the busy pool situation 44, time can see how long the process ran

45.!dso See what objects are in the current thread, and use the dump file of the dump save process to analyze the leak 46.

The dump file is a memory image of the process,

When you open the dump file in the debugger, use the command above to check to see the same results as you see in the Debug check process
. Dump/ma C://testdump.dmp
This command saves the image of the current process as C://TESTDUMP.DMP, where the/ms parameter indicates that the dump file should contain complete information about the process.
In WinDbg, the dump file is analyzed via the file-open---open Crash dump menu. When you open a file, the information and status that you see when you run the debug command is the state of the process when the dump file is saved. The dump file makes it easy to save the status of the process when a problem occurs, facilitating post-mortem analysis.

47. [Plain]View Plaincopy

2. 0:kd>!idt//view interrupt vector table contents
4. 0:kd> DT Nt!_kinterrupt 89c03bb0//view details of the corresponding interrupt vectors
6. 0:kd>!ioapic//Display I/O APIC (i.e. interrupt control unit connected to the device)
8. 0:kd>!pic//
10. 0:kd>!apic//Configuration of pic

Kd>!idt after running is displayed as

[Plain]View Plaincopy

2. 0:kd>!idt
6. Dumping IDT:
10. 37:806e7864 hal! PicSpuriousService37
12. 3D:806E8E2C hal! Halpapcinterrupt
14. 41:806e8c88 hal! Halpdispatchinterrupt
16. 50:806E793C hal! Halpapicrebootservice
18. 63:89ac57e4 usbport! Usbport_interruptservice (Kinterrupt 89ac57a8)
20. usbport! Usbport_interruptservice (Kinterrupt 8982abb0)
22. 73:89d6767c atapi! Ideportinterrupt (Kinterrupt 89d67640)
24. atapi! Ideportinterrupt (Kinterrupt 89dc4bb0)
26. 83:89c1471c videoprt!pvideoportinterrupt (Kinterrupt 89c146e0)
28. Hdaudbus! AZCONTROLLER::ISR (Kinterrupt 89c16ac8)
30. NDIS!NDISMISR (Kinterrupt 89847bb0)
32. 94:8976fbec usbport! Usbport_interruptservice (Kinterrupt 8976fbb0)
34. A4:89770bec usbport! Usbport_interruptservice (Kinterrupt 89770bb0)
36. B1:89d859e4 acpi! Acpiinterruptserviceroutine (Kinterrupt 89d859a8)
38. B4:89c03bec usbport! Usbport_interruptservice (Kinterrupt 89c03bb0)
40. C1:806E7AC0 hal! Halpbroadcastcallservice
42. D1:806e6e54 hal! Halpclockinterrupt
44. e1:806e8048 hal! Halpipihandler
46. E3:806E7DAC hal! Halplocalapicerrorservice
48. Fd:806e85a8 hal! Halpprofileinterrupt
50. fe:806e8748 hal! Halpperfinterrupt
52. The first part is the interrupt class model used. For example, number 83rd interrupts are three hardware reusable.

2.0:kd> DT Nt!_kinterrupt 89c03bb0, run after display as

[Plain]View Plaincopy

2. 0:kd> DT Nt!_kinterrupt 89c03bb0
4. +0x000 Type:0n22
6. +0x002 size:0n484
8. +0x004 interruptlistentry: _list_entry [0x89c03bb4-0x89c03bb4]
10. +0x00c serviceroutine:0xb9159e54 unsigned char usbport! Usbport_interruptservice+0
12. +0x010 servicecontext:0x89c38028 Void
14. +0x014 spinlock:0
16. +0x018 TICKCOUNT:0XFFFFFFFF
18. 0 +0x01c Actuallock:0x89c03e14
20. +0x020 dispatchaddress:0x805466d0 void nt! Kiinterruptdispatch+0
22. +0x024 VECTOR:0X1B4
24. +0x028 irql:0xa '
26. +0x029 synchronizeirql:0xa '
28. +0x02a floatingsave:0 '
30. +0x02b connected:0x1 '
32. +0x02c number:0 '
34. +0x02d sharevector:0x1 '
36. +0x030 mode:0 (levelsensitive)
38. +0x034 servicecount:0
40. +0x038 DISPATCHCOUNT:0XFFFFFFFF
42. +0x03c Dispatchcode: [106] 0x56535554

3.0:kd>!ioapic, post-run display

[Plain]View Plaincopy

2. 0:kd>!ioapic
4. Ioapic @ FEC00000 Id:8 (arb:170020)
6. Inti00.: 52000000 ' 000100ff vec:ff fixeddel ph:52000000 edg High m
8. Inti01.: 00c00000 ' 000100ff vec:ff fixeddel ph:00c00000 edg High m
10. Inti02.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
12. Inti03.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
14. Inti04.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
16. Inti05.: 52c00000 ' 000100ff vec:ff fixeddel ph:52c00000 edg High m
18. Inti06.: 00c00000 ' 000100ff vec:ff fixeddel ph:00c00000 edg High m
20. Inti07.: 02000000 ' 000100ff vec:ff fixeddel ph:02000000 edg High m
22. Inti08.: 01000000 ' 000008d1 vec:d1 fixeddel lg:01000000 EDG High
24. Inti09.: 03000000 ' 0000d9b1 vec:b1 lowestdl lg:03000000-pend lvl High Rirr
26. inti0a.: 00c00000 ' 000100ff vec:ff fixeddel ph:00c00000 edg High m
28. inti0b.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
30. inti0c.: 42000000 ' 000100ff vec:ff fixeddel ph:42000000 edg High m
32. inti0d.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
34. inti0e.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
36. inti0f.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
38. Inti10.: 03000000 ' 0000f983 vec:83 lowestdl lg:03000000-pend lvl Low Rirr
40. Inti11.: 00000000 ' 000100ff vec:ff fixeddel ph:00000000 edg High m
42. Inti12.: 03000000 ' 0000a994 vec:94 lowestdl lg:03000000 lvl Low
44. Inti13.: 00c00000 ' 000100ff vec:ff fixeddel ph:00c00000 edg High m
46. Inti14.: 03000000 ' 0000a973 vec:73 lowestdl lg:03000000 lvl Low
48. Inti15.: 03000000 ' 0000a963 vec:63 lowestdl lg:03000000 lvl Low
50. Inti16.: 03000000 ' 0000a9a4 vec:a4 lowestdl lg:03000000 lvl Low
52. Inti17.: 03000000 ' 0000f9b4 vec:b4 lowestdl lg:03000000-pend lvl Low Rirr

4.0:kd>!pic, post-run display

[Plain]View Plaincopy

2. 0:kd>!pic
4. -----IRQ Number-----Geneva, 0A 0B 0C 0D 0E 0F
6. Physically in service:.  .  .  .  .  .  .  .  .  .  .  .  .  .  . .
8. Physically masked:y y y y y y y x y y y y y y x y y
10. Physically requested:y.  .  Y.  Y.  .  Y. Y y.  .  . .

5.0:kd>!apic, post-run display

[Plain]View Plaincopy

2. 0:kd>!apic
4. Apic @ fffe0000 id:0 (50014) logdesc:01000000 destfmt:ffffffff TPR FF
6. TIMECNT:0FDAD680CLK spurvec:1f faultvec:e3 error:40
8. Ipi cmd:02000000 ' 000008e1 vec:e1 fixeddel lg:02000000 EDG High
10. Timer: 00000000 ' 000300fd vec:fd fixeddel dest=self edg High m
12. Linti0.: 00000000 ' 0001001f vec:1f fixeddel dest=self edg High m
14. Linti1.: 00000000 ' 000084ff vec:ff NMI dest=self lvl High
16. TMR:63, 94, A4, B1, B4
18. irr:41, B1, D1
20. Isr:d1

48,. CLS

. CLS for Clear Screen

Note: Only available when WinDbg is in command-line mode (that is, ctro+break is pressed)

Or use the toolbar directly:

Two

WinDbg Breakpoint Command

1. Set breakpoint command BU BP bm ba

1) BU BP bm set software Breakpoint

a). BP sets the breakpoint associated with the address

b). Bu sets the breakpoint associated with the symbol

c). BM supports setting breakpoints with wildcards, one or more BU or BP (bm/d) breakpoints can be created at a time

The main differences between BP and BU

A) BP set breakpoints and Address association, if the module to move the address of the instructions elsewhere, the breakpoint will not be moved, but still associated with the original address; The breakpoint set by BU is associated with the symbol, and if the address of the symbol changes, the breakpoint remains associated with the original symbol.

b) If the address of the breakpoint set by BP is found in the loaded module, then the software module is unloaded and the breakpoint is automatically removed, and the breakpoint set by BU is always present.

c) The breakpoint set by BP will not be saved WinDbg workspace, and the breakpoint set by BU will be saved.

2) BA Set hardware breakpoint (data breakpoint)

A hardware breakpoint is a breakpoint that is triggered when a memory address is accessed (read, write, execute), or an IO port is accessed.

2. Other command BL BC BD be. Bpcmds

BL enumerates all the breakpoints and their states

BC Delete corresponding Breakpoint

BD disables corresponding breakpoint

be enable corresponding breakpoint

. Bmcmds enumerate all breakpoints and commands to create them

3. Software breakpoints and hardware breakpoints

1) Software Breakpoint-The breakpoint that the Debug tool controls. When the debugger sets a breakpoint at an address, it will first save the contents of that address, when a break instruction (such as INT3 (0xCC)) is inserted, when the program executes to that address is the CPU goes into the debug state, when the debug is finished, the program re-load the address of the original instruction to re-execute.

2) hardware breakpoints-also known as data breakpoints-are processor-controlled breakpoints that can be used to monitor access to (read, write, execute) and IO addresses of a memory address (read, write). The processor has a corresponding debug register, which is used to record the address of the data breakpoint, and when the address (memory address or IO port address) is accessed, the breakpoint is triggered and the CPU enters the debug state.

3) Differences between software breakpoints and hardware breakpoints

A) Theoretically we can set an infinite number of software breakpoints, but setting a software breakpoint will slow the program, especially in the kernel state, most of the debugger will limit the number of breakpoints. For example, WinDbg supports up to 32 software breakpoints in the kernel state, and supports any number of user configurations; Hardware breakpoints depend on the processor, for example X86 supports four breakpoints (80386 has eight debug registers-DR0~DR3 for breakpoints, DR4~DR5 reserved, dr6~dr7 for control).

b) The software breakpoint needs to modify the corresponding code, so it cannot debug the code in Flash and ROM, while the hardware does not have this limitation.

3. References

1. http://www.lslnet.com/linux/dosc1/59/linux-389058.htm

2. http://blog.csdn.net/wingeek/article/details/4025475

3. http://embexperts.com/viewthread.php?tid=69

4. http://msdn.microsoft.com/en-us/library/ff538903%28v=VS.85%29.aspx

5. http://msdn.microsoft.com/en-us/library/ff538165%28v=VS.85%29.aspx

6. http://msdn.microsoft.com/en-us/library/ff553451%28v=VS.85%29.aspx

1. Use!process 0 0 to get information about all the processes in the user space

If there are multiple identical process names,!process 0 0 SampleExe.exe

kd> !process 0 0
NT ACTIVE PROCESS DUMP * * * *
PROCESS fe5039e0 sessionid:0 cid:0008 peb:00000000 parentcid:0000
dirbase:00030000 objecttable:fe529b68 tablesize:50.
Image:system

2. Use the. process/i to specify the process address

Because you want to place a breakpoint on the user-state code, this does not use/p, and the/I

If you want the kernel debugger to set breakpoints in user space, use the/I option to switch the target to The correct process context.

3. G continue, after another int 3 interrupt, the process context has been switched, using!process to view the confirmation.

4. reload symbol file.

5. BU, BP under User State breakpoint.

WinDbg common Commands