Idle thread not visible in !process 0 7?

WINDBG
1

OK, let me start by asserting that I am assuming operator error until
someone suggests that I try something that suggests otherwise. I really
think I’m doing something uninformed, I’m just not sure what.

My target partially hung, meaning that it responded to mouse movement, but
not mouse click or keyboard. I suspected a deadlock of some kind. So I
broke in from the host, and it broke in on a thread that showed my DPC
waiting for an interrupt spinlock. (We keep the hardware access in the DPC
to an absolute minimum we can, but it’s (probably) unavoidable. Need to
acquire the spinlock to keep other things from stomping on the access
sequence.) OK, so far so good.

This is the thread stack(with source references snipped), but I didn’t
actually run this until later. I knew this is the stack because it’s in
the stack window:
0: kd> kb
ChildEBP RetAddr Args to Child
80550180 80544109 00000001 8919ae06 000000d1
nt!RtlpBreakWithStatusInstruction
80550180 8053f982 00000001 8919ae06 000000d1 nt!KeUpdateSystemTime+0x175
80550204 804f8215 8833ff18 00000000 80550228
nt!KefAcquireSpinLockAtDpcLevel+0x12
80550214 bac9aa40 88237008 77cc2190 bac8e827
nt!KeAcquireInterruptSpinLock+0x1d
80550220 bac8e827 80550238 bacc9ca6 8833c688
Wdf01000!FxInterrupt::AcquireLock+0x16
80550228 bacc9ca6 8833c688 8833ff18 80550244
Wdf01000!imp_WdfInterruptAcquireLock+0x29
80550238 bacc9c67 77cc00e0 80550254 bacc68f8
Sk_SiI3124!WdfInterruptAcquireLock+0x16
80550244 bacc68f8 8833f124 00000000 80550274
Sk_SiI3124!OsaAcquireHardwareSync+0x27
80550254 bacc78b9 8833ee00 00000000 00000004
Sk_SiI3124!SiI3124ResetChannel+0x18
80550274 bacc4d4a 87c2a9e8 00000000 8833ea84
Sk_SiI3124!SiI3124CancelIo+0xc9
80550290 bacc4400 87c2a9e8 8833df20 87c2a9e8 Sk_SiI3124!BaseCancelIo+0x9a
805502b8 bac7fa1e 77cc2190 80550308 8833de68
Sk_SiI3124!OseEvtTimerPostRequests+0x80
805502cc bac7fa3e 8833dec8 8f24caca 01c6f7a1
Wdf01000!FxTimer::TimerHandler+0x63
805502e0 80501543 8833dec8 8833de68 8f24caca
Wdf01000!FxTimer::FxTimerDpcThunk+0x16
805503fc 8050165f 8055b0a0 ffdff9c0 ffdff000 nt!KiTimerListExpire+0x14b
80550428 80544e5f 8055b4a0 00000000 00056115 nt!KiTimerExpiration+0xb1
80550450 80544d44 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61
80550454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28

So I ran !locks. My thread, and the lock it was trying to acquire, didn’t
show up. Not so good.
So then I ran kb to see if I was crazy. No, it produced the stack trace
above.
So then I ran !stacks with lots of different parameters, didn’t find that
thread.
So then I ran !process 0 0 and !process 0 7, and still didn’t find that
thread.

So now I’m wondering if I’m hallucinating the stack backtrace I’ve copied
and pasted? :slight_smile:

Why wouldn’t the stack I’ve broken into show up in the output from these
commands?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

2

Hi,

!locks doesn’t work because that’s for ERESOURCEs only.

IIRC, I don’t think that the Idle process gets put into the process list,
which is probably why the debugger commands aren’t displaying it.

In any case, you should be able to find this thread either in the PCR:

0: kd> !pcr
…
IdleThread: 80562ca0
…

Or by doing a !process on the global that holds the Idle process address
(!process poi(nt!PsIdleProcess)
on the machine I’m broken into)

While I don’t know if this helps you directly, it should at least prove
you’re not insanse :slight_smile:

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@windbg…
>
> OK, let me start by asserting that I am assuming operator error until
> someone suggests that I try something that suggests otherwise. I really
> think I’m doing something uninformed, I’m just not sure what.
>
> My target partially hung, meaning that it responded to mouse movement, but
> not mouse click or keyboard. I suspected a deadlock of some kind. So I
> broke in from the host, and it broke in on a thread that showed my DPC
> waiting for an interrupt spinlock. (We keep the hardware access in the
> DPC
> to an absolute minimum we can, but it’s (probably) unavoidable. Need to
> acquire the spinlock to keep other things from stomping on the access
> sequence.) OK, so far so good.
>
> This is the thread stack(with source references snipped), but I didn’t
> actually run this until later. I knew this is the stack because it’s in
> the stack window:
> 0: kd> kb
> ChildEBP RetAddr Args to Child
> 80550180 80544109 00000001 8919ae06 000000d1
> nt!RtlpBreakWithStatusInstruction
> 80550180 8053f982 00000001 8919ae06 000000d1 nt!KeUpdateSystemTime+0x175
> 80550204 804f8215 8833ff18 00000000 80550228
> nt!KefAcquireSpinLockAtDpcLevel+0x12
> 80550214 bac9aa40 88237008 77cc2190 bac8e827
> nt!KeAcquireInterruptSpinLock+0x1d
> 80550220 bac8e827 80550238 bacc9ca6 8833c688
> Wdf01000!FxInterrupt::AcquireLock+0x16
> 80550228 bacc9ca6 8833c688 8833ff18 80550244
> Wdf01000!imp_WdfInterruptAcquireLock+0x29
> 80550238 bacc9c67 77cc00e0 80550254 bacc68f8
> Sk_SiI3124!WdfInterruptAcquireLock+0x16
> 80550244 bacc68f8 8833f124 00000000 80550274
> Sk_SiI3124!OsaAcquireHardwareSync+0x27
> 80550254 bacc78b9 8833ee00 00000000 00000004
> Sk_SiI3124!SiI3124ResetChannel+0x18
> 80550274 bacc4d4a 87c2a9e8 00000000 8833ea84
> Sk_SiI3124!SiI3124CancelIo+0xc9
> 80550290 bacc4400 87c2a9e8 8833df20 87c2a9e8 Sk_SiI3124!BaseCancelIo+0x9a
> 805502b8 bac7fa1e 77cc2190 80550308 8833de68
> Sk_SiI3124!OseEvtTimerPostRequests+0x80
> 805502cc bac7fa3e 8833dec8 8f24caca 01c6f7a1
> Wdf01000!FxTimer::TimerHandler+0x63
> 805502e0 80501543 8833dec8 8833de68 8f24caca
> Wdf01000!FxTimer::FxTimerDpcThunk+0x16
> 805503fc 8050165f 8055b0a0 ffdff9c0 ffdff000 nt!KiTimerListExpire+0x14b
> 80550428 80544e5f 8055b4a0 00000000 00056115 nt!KiTimerExpiration+0xb1
> 80550450 80544d44 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61
> 80550454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28
>
> So I ran !locks. My thread, and the lock it was trying to acquire, didn’t
> show up. Not so good.
> So then I ran kb to see if I was crazy. No, it produced the stack trace
> above.
> So then I ran !stacks with lots of different parameters, didn’t find that
> thread.
> So then I ran !process 0 0 and !process 0 7, and still didn’t find that
> thread.
>
> So now I’m wondering if I’m hallucinating the stack backtrace I’ve copied
> and pasted? :slight_smile:
>
> Why wouldn’t the stack I’ve broken into show up in the output from these
> commands?
>
> Phil
>
> Philip D. Barila
> Seagate Technology LLC
> (720) 684-1842
>
>

3

You’re correct that the idle thread (and idle process) are not real
kernel objects and aren’t in the normal lists.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Tuesday, October 24, 2006 2:21 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Idle thread not visible in !process 0 7?

Hi,

!locks doesn’t work because that’s for ERESOURCEs only.

IIRC, I don’t think that the Idle process gets put into the process
list, which is probably why the debugger commands aren’t displaying it.

In any case, you should be able to find this thread either in the PCR:

0: kd> !pcr
…
IdleThread: 80562ca0
…

Or by doing a !process on the global that holds the Idle process address
(!process poi(nt!PsIdleProcess) on the machine I’m broken into)

While I don’t know if this helps you directly, it should at least prove
you’re not insanse :slight_smile:

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@windbg…
>
> OK, let me start by asserting that I am assuming operator error until
> someone suggests that I try something that suggests otherwise. I
> really think I’m doing something uninformed, I’m just not sure what.
>
> My target partially hung, meaning that it responded to mouse movement,

> but not mouse click or keyboard. I suspected a deadlock of some kind.

> So I broke in from the host, and it broke in on a thread that showed
> my DPC waiting for an interrupt spinlock. (We keep the hardware
> access in the DPC to an absolute minimum we can, but it’s (probably)
> unavoidable. Need to acquire the spinlock to keep other things from
> stomping on the access
> sequence.) OK, so far so good.
>
> This is the thread stack(with source references snipped), but I didn’t

> actually run this until later. I knew this is the stack because it’s
> in the stack window:
> 0: kd> kb
> ChildEBP RetAddr Args to Child
> 80550180 80544109 00000001 8919ae06 000000d1
> nt!RtlpBreakWithStatusInstruction 80550180 8053f982 00000001 8919ae06
> 000000d1 nt!KeUpdateSystemTime+0x175
> 80550204 804f8215 8833ff18 00000000 80550228
> nt!KefAcquireSpinLockAtDpcLevel+0x12
> 80550214 bac9aa40 88237008 77cc2190 bac8e827
> nt!KeAcquireInterruptSpinLock+0x1d
> 80550220 bac8e827 80550238 bacc9ca6 8833c688
> Wdf01000!FxInterrupt::AcquireLock+0x16
> 80550228 bacc9ca6 8833c688 8833ff18 80550244
> Wdf01000!imp_WdfInterruptAcquireLock+0x29
> 80550238 bacc9c67 77cc00e0 80550254 bacc68f8
> Sk_SiI3124!WdfInterruptAcquireLock+0x16
> 80550244 bacc68f8 8833f124 00000000 80550274
> Sk_SiI3124!OsaAcquireHardwareSync+0x27
> 80550254 bacc78b9 8833ee00 00000000 00000004
> Sk_SiI3124!SiI3124ResetChannel+0x18
> 80550274 bacc4d4a 87c2a9e8 00000000 8833ea84
> Sk_SiI3124!SiI3124CancelIo+0xc9
> 80550290 bacc4400 87c2a9e8 8833df20 87c2a9e8
> Sk_SiI3124!BaseCancelIo+0x9a
> 805502b8 bac7fa1e 77cc2190 80550308 8833de68
> Sk_SiI3124!OseEvtTimerPostRequests+0x80
> 805502cc bac7fa3e 8833dec8 8f24caca 01c6f7a1
> Wdf01000!FxTimer::TimerHandler+0x63
> 805502e0 80501543 8833dec8 8833de68 8f24caca
> Wdf01000!FxTimer::FxTimerDpcThunk+0x16
> 805503fc 8050165f 8055b0a0 ffdff9c0 ffdff000
> nt!KiTimerListExpire+0x14b
> 80550428 80544e5f 8055b4a0 00000000 00056115 nt!KiTimerExpiration+0xb1

> 80550450 80544d44 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61
> 80550454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28
>
> So I ran !locks. My thread, and the lock it was trying to acquire,
> didn’t show up. Not so good.
> So then I ran kb to see if I was crazy. No, it produced the stack
> trace above.
> So then I ran !stacks with lots of different parameters, didn’t find
> that thread.
> So then I ran !process 0 0 and !process 0 7, and still didn’t find
> that thread.
>
> So now I’m wondering if I’m hallucinating the stack backtrace I’ve
> copied and pasted? :slight_smile:
>
> Why wouldn’t the stack I’ve broken into show up in the output from
> these commands?
>
> Phil
>
> Philip D. Barila
> Seagate Technology LLC
> (720) 684-1842
>
>

—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

4

Thanks to both of you.

Turns out it was right in front of me. If I had just looked at each
routine on the stack the first time, the obvious double acquire would have
been obvious. >-( I discovered that by looking at each routine on the
stack and finding the obvious double acquire the second time it hung. I
forget why I turned off verifier not too long ago (maybe performance test),
but I’m turning it back on. :smiley:

Phil

Philip D. Barila

Seagate Technology LLC

(720) 684-1842

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss


Sent: Tuesday, October 24, 2006 4:08 PM

To: “Kernel Debugging Interest List”

Subject: RE: [windbg] Idle thread not visible in !process 0 7?

You’re correct that the idle thread (and idle process) are not real

kernel objects and aren’t in the normal lists.

-----Original Message-----

From: xxxxx@lists.osr.com

[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone

Sent: Tuesday, October 24, 2006 2:21 PM

To: Kernel Debugging Interest List

Subject: Re:[windbg] Idle thread not visible in !process 0 7?

Hi,

!locks doesn’t work because that’s for ERESOURCEs only.

IIRC, I don’t think that the Idle process gets put into the process

list, which is probably why the debugger commands aren’t displaying it.

In any case, you should be able to find this thread either in the PCR:

0: kd> !pcr

…

IdleThread: 80562ca0

…

Or by doing a !process on the global that holds the Idle process address

(!process poi(nt!PsIdleProcess) on the machine I’m broken into)

While I don’t know if this helps you directly, it should at least prove

you’re not insanse :slight_smile: