THREAD 893683b0 Cid 0d9c.0f38 Teb: 7ffad000 Win32Thread: e6be2850 WAIT: (UserRequest) UserMode Non-Alertable
895ae760 NotificationEvent
893684a0 NotificationTimer
IRP List:
895e3c68: (0006,0190) Flags: 00000000 Mdl: 895712c0
893c2858: (0006,0190) Flags: 00000000 Mdl: 8937c008
Not impersonating
DeviceMap e1009200
Owning Process 0 Image:
Attached Process 89573b98 Image: iftpsvc.exe
Wait Start TickCount 19645 Ticks: 92 (0:00:00:01.437)
Context Switch Count 309 LargeStack
UserTime 00:00:00.265
KernelTime 00:00:00.046
Win32 Start Address 0x79f9205f
Start Address 0x7c8106e9
Stack Init b1173000 Current b1172ca0 Base b1173000 Limit b116f000 Call 0
Priority 9 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr
b1172cb8 804e1bd2 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
b1172cc4 804e1c1e nt!KiSwapThread+0x8a (FPO: [0,0,0])
b1172cec 8056dff6 nt!KeWaitForSingleObject+0x1c2 (FPO: [5,5,4])
b1172d50 804dd99f nt!NtWaitForSingleObject+0x9a (FPO: [Non-Fpo])
b1172d50 7c90e4f4 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b1172d64)
However, I would like to confirm the thread is really in wait state. To do so, I first retrieve KeTickCount, which was saved when the dump was generated, then calculate the delta between KeTickCount and Wait Start TickCount for the thread. If the delta is equal to Ticks, then the thread is still in wait state. If the delta is larger than Ticks, the thread is no longer in wait state.
0: kd> dd KeTickCount l1
8055a000 00004d19
0: kd> ? 00004d19
Evaluate expression: 19737 = 00004d19
0: kd> ? 0n19737 - 0n19645
Evaluate expression: 92 = 0000005c
So the thread is still in wait state.
0 comments:
Post a Comment