kd718和kb688参数_kb 参数使用示例

What does a Pushlock look like?

3: kd> !thread 8c9764c0

THREAD 8c9764c0Cid 2410.1be4Teb: 7ff9f000 Win32Thread: e5c6f298 GATEWAIT

Stack Init b386b000 Current b386a978 Base b386b000 Limit b3867000 Call 0

ChildEBP RetAddrArgs to Child

b386a990 80833485 8c9764c0 8c9764e4 00000003 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

b386a9bc 8082ffe0 b06a6a03 e11e0b18 b386aa54 nt!KiSwapThread+0x2e5 (FPO: [Non-Fpo]) (CONV: fastcall)

b386a9e4 8087d722 00000000 e11e0b08 e11e0b18 nt!KeWaitForGate+0x152 (FPO: [Non-Fpo]) (CONV: fastcall)

e11e0b18 00000000 0c050204 7346744e e37b2808 nt!ExfAcquirePushLockExclusive+0x112 (FPO: [Non-Fpo]) (CONV: fastcall)

Above is a snipped output from a dump that I was recently looking at. From the stack, you can see the ExfAcquirePushLockExclusive call trying to acquire the pushlock, which then calls KEWaitForGate. In this case, the lock was already acquired, so this thread allocated a wait block on its stack, and then added itself to the waitlist.

Also, the stack is broken due to the fastcall, therefore the debugger cannot display it entirely. So we can manually reconstruct the stack by passing parameters to the kb command.

k[b|p|P|v] = BasePtr StackPtr InstructionPtr

To get the arguments, we first dump the stack manually using the dps command with the current esp.

3: kd> dps b386a978 l50

b386a978b386ad40

b386a97c00000000

b386a9808088dafe nt!KiSwapContext+0x26

b386a984b386a9bc

b386a988b386aa00

b386a98cf773f120

b386a9908c9764c0

b386a99480833485 nt!KiSwapThread+0x2e5

b386a9988c9764c0

b386a99c8c9764e4

b386a9a000000003

b386a9a48c9764c0

b386a9a800000003

b386a9ac00000002

b386a9b000000002

b386a9b4f773fa7c

b386a9b8008c0030

b386a9bcb386a9e4

b386a9c08082ffe0 nt!KeWaitForGate+0x152

b386a9c4b06a6a03

b386a9c8e11e0b18

b386a9ccb386aa54

b386a9d000000000

b386a9d48c976504

b386a9d800000000

b386a9dc0000001c

b386a9e000000000

b386a9e4b386aa40

b386a9e88087d722 nt!ExfAcquirePushLockExclusive+0x112

b386a9ec00000000

b386a9f0e11e0b08

b386a9f4e11e0b18

b386a9f8b386aa40

b386a9fc8096e9a9 nt!SeOpenObjectAuditAlarm+0x1cf

b386aa0000040007

b386aa0400000000

b386aa088c976568

b386aa0c8c976568

b386aa10b06a6a00

b386aa14b4ee0a00

b386aa18b127cc10

b386aa1c00000000

b386aa2000000001

b386aa2480a60456 hal!KfLowerIrql+0x62

b386aa28b386ac04

b386aa2c8d117800

b386aa3000000000

b386aa3400000000

b386aa38b386aa20

b386aa3c01943080

b386aa40b386aa64

b386aa44808b7a14 nt!CmpCheckRecursionAndRecordThreadInfo+0x2a

From the output above, we can see the stack. To reconstruct the stack, we can get the ebp, esp, and eip from the stack for the ExfAcquirePushLockExclusive frame, and pass it to the kb command. Voila!

3: kd> kb = b386aa40 b386a9e4 8087d722

ChildEBP RetAddrArgs to Child

b386aa40 808b7a14 b386ac04 e11e0b18 e11e0b18 nt!ExfAcquirePushLockExclusive+0x112

b386aa64 808b7b09 e11e0b18 b386aa80 e101bf40 nt!CmpCheckRecursionAndRecordThreadInfo+0x2a

b386aaa4 808da118 0000001c b386ab58 00000001 nt!CmpCallCallBacks+0x6b

b386ab90 80937942 e101bf40 00000000 89f13648 nt!CmpParseKey+0xd4

b386ac10 80933a76 00000000 b386ac50 00000040 nt!ObpLookupObjectName+0x5b0

b386ac64 808bb471 00000000 8e930480 00000d01 nt!ObOpenObjectByName+0xea

b386ad50 808897bc 0243eba0 00020019 0243eb68 nt!NtOpenKey+0x1ad

b386ad50 7c8285ec 0243eba0 00020019 0243eb68 nt!KiFastCallEntry+0xfc

WARNING: Frame IP not in any known module. Following frames may be wrong.

0243eba4 00000000 00000000 00000000 00000000 0x7c8285ec