【转】WinDbg debug used command

0: kd> !runaway 
No export runaway found 

This is because: !runaway is a user-mode extension.  There is no direct kernel-mode equivalent. 

 

0: kd> .thread               //查看转储文件时所有的线程

Implicit process is now fffffa80`0231e340

0: kd> !thread fffffa80`0290aa60          //查看该线程详细信息

 

0: kd> .process               //查看转储文件时所有的线程

Implicit process is now fffffa80`0231e340

0：kd> kb          //查看stack call information，列出前三个形参的地址

0：kd> kP          //查看stack call information，列出每个形参的名字及值

 

    If the kb or kv commands are used, the first three parameters passed to each function are displayed. If the kv command is used, FPO(frame pointer omission) data is displayed as well. On an x86 processor, the kv command also displays calling convention information.

    After "!analyze -v" or "kv", if there are the information like:

TRAP_FRAME:  fffffade620a77e0 -- (.trap 0xfffffade620a77e0)

or

fffffade`620a77e0 fffffade`5e94f7f5 : fffffade`5e8684cf 00000000`00000000 fffff800`0128d358 fffffade`5e7a41e8 : nt!KiPageFault+0x119 (TrapFrame @ fffffade`620a77e0)

0: kd>.trap 0xfffffade620a77e0   is very useful. It displays the important registers for the specified trap frame. It can display issue module name.

0:015> dt <structure name>     //查看结构体内各成员及其在内存中的地址分配

0:015> dda <structure address>   //查看对应地址空间的内容

dda和dt结合使用可以查看结构体中各成员变量在内存中的内容

Sometimes when listing processes we see the so called Zombie Processes. They are better visible in the output of !vm command as processes with zero private memory.

0:kd>!vm

3654 explorer.exe      2083 (      8332 Kb)
037c MyService.exe     2082 (      8328 Kb)
315c explorer.exe      2045 (      8180 Kb)
0380 smss.exe            38 (       152 Kb)
0004 System               7 (        28 Kb)
6ee8 cmd.exe              0 (         0 Kb)
6d7c cmd.exe              0 (         0 Kb)
6ca8 cmd.exe              0 (         0 Kb)

0:kd>!process <process number displayed by !vm>   //可以获得父进程信息(ParentCid: 037c)

0:kd> !kdexts.handle 0 3 037c   //peek inside cid=037c handle table

(kdexts = Kernel-Mode Extensions)

0510: Object: 89237d88  GrantedAccess: 001f0fff Entry: e1cafa20
Object: 89237d88  Type: (8ad84900) Process
    ObjectHeader: 89237d70 (old version)
        HandleCount: 1  PointerCount: 2

Therefore we may guess that MyService.exe probably forgot to close process handles either after launching cmd.exe or after waiting for their exit when process objects become signaled.

0: kd> dt _DISPATCHER_HEADER 89237d88
ntdll!_DISPATCHER_HEADER
   +0x000 Type             : 0x3 '' ; PROCESS OBJECT
   +0x001 Absolute         : 0 ''
   +0x001 NpxIrql          : 0 ''
   +0x002 Size             : 0x1e ''
   +0x002 Hand             : 0x1e ''
   +0x003 Inserted         : 0 ''
   +0x003 DebugActive      : 0 ''
   +0x000 Lock             : 1966083
   +0x004 SignalState      : 1
   +0x008 WaitListHead     : _LIST_ENTRY [ 0×89237d90 - 0×89237d90 ]

This pattern can also be seen a specialization of a more general Handle Leak pattern.

 

 handle leaks  

step 1:

0: kd> !vm

*** Virtual Memory Usage ***
 Physical Memory:     1048352 (   4193408 Kb)
 Page File: \??\C:\pagefile.sys
   Current:   4190208 Kb  Free Space:   3749732 Kb
   Minimum:   4190208 Kb  Maximum:      4190208 Kb
 Free Special NP:           0 (         0 Kb)
 Modified Pages:          195 (       780 Kb)
 Modified PF Pages:       195 (       780 Kb)
 NonPagedPool Usage:    65244 (    260976 Kb)
 NonPagedPool Max:      65503 (    262012 Kb)
 ********** Excessive NonPaged Pool Usage *****
 PagedPool 0 Usage:      6576 (     26304 Kb)
 PagedPool 3 Usage:       608 (      2432 Kb)
 PagedPool 4 Usage:       625 (      2500 Kb)
 PagedPool Usage:        9062 (     36248 Kb)
 PagedPool Maximum:     66560 (    266240 Kb)

********** 184 pool allocations have failed **********

 Shared Commit:          7711 (     30844 Kb)

step 2: Looking at non-paged pool consumption reveals excessive number of thread objects:

0: kd> !poolused 3
   Sorting by  NonPaged Pool Consumed

  Pool Used:
            NonPaged
Tag   Allocs  Frees     Diff     Used
Thre  772672  463590   309082 192867168  Thread objects , Binary: nt!ps

MmCm      42       9       33 12153104   Calls made to MmAllocateContiguousMemory , Binary: nt!mm

step 3: The next logical step would be to list processes and find their handle usage. Indeed there is such a process:

0: kd> !process 0 0

PROCESS 88b75020  SessionId: 7  Cid: 172e4    Peb: 7ffdf000  ParentCid: 17238
    DirBase: c7fb6bc0  ObjectTable: e17f50a0  HandleCount: 143428.
    Image: iexplore.exe
step 4:Use !handle  !thread查看handle、线程信息

0: kd> !thread 88b4a730
THREAD 88b4a730  Cid 0004.1885c  Teb: 00000000 Win32Thread: 00000000 TERMINATED
Not impersonating
DeviceMap                 e1000930
Owning Process            8b7807a8       Image:         System
Wait Start TickCount      975361         Ticks: 980987 (0:04:15:27.921)
Context Switch Count      1
UserTime                  00:00:00.0000
KernelTime                00:00:00.0000
Start Address mydriver!StatusWaitThread (0xf5c5d128