Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Identify thread waittime in the user mode process dump

Jay_KumarJay_Kumar Member Posts: 25

Hi All,

How can I identify the total wait time of a thread that is waiting on something from the user mode process dump file. From the kernel mode dump file we can use !thread to check the waitstart tick count but there is no equivalent for the user mode dump. The .ttime command shows only the kernel and user times but not the wait time.

Any idea how can I see the wait time from the user mode dump file?



  • ThatsBerkanThatsBerkan Member Posts: 45

    I'm guessing you're using WinDbg.
    Dump the _KTHREAD structure, look near the end to find the offsets of both 'UserWaitTime' and 'KernelWaitTime'.
    From there, you can manually read the wait time for both contexts, of the thread you're targeting.

  • Jay_KumarJay_Kumar Member Posts: 25

    Thanks for the reply.

    I got user mode threads id as well as the thread stacks from the dump file using "~" command . How can I get the address of the KTHREAD structure for the particular thread so that I can dump its structure to see the waittime.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,401

    AFAIK that number isn't available in user mode. All you get for times are user, kernel, and start (see !runaway).


  • MBond2MBond2 Member Posts: 278

    If you have a repeatable problem, you add some instrumentation to the code to keep track of this, then recreate the problem. Make sure that you store the value in something like a volatile global so that the compiler does not elide or re-order the write in optimized builds

    If you have only a crash dump from an incident that you can't reproduce, then you look for inferential information - usually higher up in the call stack. Sequence numbers, timestamps and counters are often helpful, but it requires a detailed knowledge of what the specific program does to make much sense of this kind of information.

    But more to the point, why do you care? I don't think that I have ever used knowledge of the duration of a wait to successfully diagnose a live lock or dead lock problem. Usually crash dumps are helpful in identifying the presence of these kinds of bugs, but usually nothing but the involved stacks are helpful in resolving them. Detailed review of the lock hierarchy is almost always the solution in my experience. Which makes it even more of a shame that MS badly broke the SAL annotations when restructuring their compiler. In my shop we still add them to document the assumptions made in the code - even if the automated tools fail to consider them properly

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE