Query on thread wait time

WINDBG
1

Hi,
From the following sample !thread output I see that there is a mention
of a “wait start tickcount” and “ticks” for the thread:

1: kd> !thread 8728a020
THREAD 8728a020 Cid 4c9c.59a4 Teb: 7ffdf000 Win32Thread: bc012008 WAIT:
(Unknown) UserMode Non-Alertable
8728a20c Semaphore Limit 0x1
Waiting for reply to LPC MessageId 017db413:
Current LPC port e5fcff68
Impersonation token: e2b07028 (Level Impersonation)
DeviceMap e1da6518
Owning Process 89d20740 Image: winlogon.exe
Wait Start TickCount 8576667 Ticks: 7256 (0:00:01:53.375)
Context Switch Count 1719 LargeStack
UserTime 00:00:00.0359
KernelTime 00:00:00.0375

Do the “wait start tickcount” and “ticks” values refer to the current wait
in the thread? In other words, for a thread with multiple different wait
conditions, do these values get reset on each satisfied wait condition in
the thread?
Also, is the “KernelTime” indicative of the actual total time spent by the
thread in the kernel in the “running” condition (excluding the wait times,
if any)?

Thanks,
Girish.

2

Girish Aithal wrote:

From the following sample !thread output I see that there is a mention
of a “wait start tickcount” and “ticks” for the thread:

1: kd> !thread 8728a020
THREAD 8728a020 Cid 4c9c.59a4 Teb: 7ffdf000 Win32Thread: bc012008 WAIT:
(Unknown) UserMode Non-Alertable
8728a20c Semaphore Limit 0x1
Waiting for reply to LPC MessageId 017db413:
Current LPC port e5fcff68
Impersonation token: e2b07028 (Level Impersonation)
DeviceMap e1da6518
Owning Process 89d20740 Image: winlogon.exe
Wait Start TickCount 8576667 Ticks: 7256 (0:00:01:53.375)
Context Switch Count 1719 LargeStack
UserTime 00:00:00.0359
KernelTime 00:00:00.0375

Do the “wait start tickcount” and “ticks” values refer to the current wait
in the thread? In other words, for a thread with multiple different wait
conditions, do these values get reset on each satisfied wait condition in
the thread?

Pause a moment to think about this. Regardless of how many conditions
there are, when you issue a blocking request, your thread transitions
from “running” to “waiting”. At some point in the future, when your
condition(s) are satisfied (either one or many, depending on how you
blocked), you transition back from “waiting” to “running”. The “wait
start tickcount” is merely the tick count at the point you started
waiting. If you are waiting for multiple things, the fact that some of
them got signaled is irrelevant to scheduling. You won’t get awakened
and then put back to sleep. It’s one long sleep.

Also, is the “KernelTime” indicative of the actual total time spent by the
thread in the kernel in the “running” condition (excluding the wait times,
if any)?

That’s the theory. What else could it be?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Thanks Tim for clarifying this for me.