Is this strange?

NTDEV
1

Hi All

I am debugging a concurrency problem. So I just wanted to find out all different stacks in which my driver code is in. So I did “!stacks 2 mydrv” to get the list. It brought out 2 threads whose stack had my driver code.

Strangely when I ran through all the processors with “~procnum” I saw in one of the processors there was a third stack, I could see in the call stack window which also had my driver code. I dont understand why this one didnt show up in the !stacks command

Thanks
AK

2

More details:

When I did !thread in the processor where I found this third stack, I see its System Idle loop.
!stacks doesnt include System idle thread in its search?

output of !thread:
###########

THREAD fffff88001e680c0 Cid 0000.0000 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 2
Not impersonating
DeviceMap fffff8a000007ee0
Owning Process fffff80001dff140 Image: Idle
Attached Process fffffa80129f55f0 Image: System
Wait Start TickCount 574666 Ticks: 215085 (0:00:55:55.347)
Context Switch Count 219241
UserTime 00:00:00.000
KernelTime 03:11:02.891
Win32 Start Address nt!KiIdleLoop (0xfffff80001c806a0)
Stack Init fffff88001e85db0 Current fffff88001e85d40
Base fffff88001e86000 Limit fffff88001e80000 Call 0
Priority 16 BasePriority 0 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 0
…
…
…
…
fffff88001e85cd0 fffff80001c806fa : fffff88001e5d180 fffff88001e680c0 0000000000000000 fffff88000e42c50 : nt!KiRetireDpcList+0x1bc
fffff88001e85d80 0000000000000000 : fffff88001e86000 fffff88001e80000 fffff88001e85d40 0000000000000000 : nt!KiIdleLoop+0x5a

3

>!stacks doesnt include System idle thread in its search?

Correct. The Idle process isn’t linked in to the active process list, so
!stacks output doesn’t include it. In this case you have your DPC being
executed within the context of the Idle process, so your output was a bit
misleading.

I always use !running -it also as part of the analysis to avoid this kind of
thing (though I suppose it would be nice for !stacks to include the Idle
threads).

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

4

Hi Scott

Thanks for the affirmation. +1 on !stacks to include the idle threads.

I find it annoying when I dont get the entire stack trace till the bottom. Both in Callstack window and “!running -it” output. Is there any settings in the windbg which will help in avoiding this downsizing behaviour in the output? Please do share if you know a way around this, I would really appreciate.

Thanks
AK

5

>I find it annoying when I dont get the entire stack trace till the bottom.

Both in Callstack window and “!running -it” output. Is there any >settings
in the windbg which will help in avoiding this downsizing behaviour in the
output?

.kframes will fix this for the !running output, try:

.kframes 1000

Which sets the call stack depth to the maximum of 4096.

In the call stack window you have to click the “More” button to increase the
depth, I don’t know of a way to force it to match the .kframes value (also,
not all commands listen to the .kframes setting).

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

6

Thanks