Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Defrag Tools: #28 - WinDbg - Scheduling

29 minutes, 9 seconds


Right click “Save as…”

In this episode of Defrag Tools, Andrew Richards, Chad Beeder and Larry Larsen continue looking at the Debugging Tools for Windows (in particular WinDbg). WinDbg is a debugger that supports user mode debugging of a process, or kernel mode debugging of a computer.

This installment goes over the Windows Scheduler. We look at Running, Ready and Waiting threads, and talks about the effect of Power Management on scheduling.

We use these commands:

  • !running
  • !running -t
  • !ready
  • !dpcs
  • !thread <addr> 17
  • !thread -1 17   (current thread)

Make sure you watch Defrag Tools Episode #1 and Defrag Tools Episode #23 for instructions on how to get the Debugging Tools for Windows and how to set the required environment variables for symbol and source code resolution.

Microsoft Data Center Tour

[00:00] - Episode #27's demo issue
[02:47] - Kernel Hangs
[05:18] - !running
[05:48] - Idle Threads & Processor Power Management
[10:10] - !running -t
[13:53] - !ready
[14:15] - Thread State Diagram
[16:45] - Saturated example
[20:48] - Thread Priority Diagram
[22:22] - Balance Set Manager
[25:30] - Waiting Threads
[26:52] - Summary


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • IgorIgor

    Could you elaborate more on thread scheduling according to thread priority (real time, non-real time) and core affinity, please?

  • Andrew Richardswindev Andrew Richards

    @Igor: Processes belong to a group of priorities. A thread with be in the center of the group if it doesn't change the thread priority (+2, +1, 0, -1, -2).

    All threads end up with a number between 0 and 31. While a thread with a higher priority wants to run, it will. All other threads already queued to the core will have to wait (ready).

    Based on the windows version and current power policy, the threads may be queued to an already busy core, or an idle one. Once queued it won't be moved. Each thread has an ideal core, set at birth. If the core is available and power policy allows it, it will be scheduled there. Failing that, the scheduler tries to use the same CPU socket, and then NUMA node.

    If affinity is set, a mask of the available cores is applied first. The decision is then made within that subset. You only use affinity if you know you are going to have more threads than cores, and want to reserve CPU power for other processes. in general, not common.

    Does that answer your question?

  • IgorIgor

    Hi windev,
    thanks for the response. I can imagine that the scheduling mechanism is not a simple thing. I’ve found great example by Joe Duffy (http://www.bluebytesoftware.com/blog/PermaLink,guid,1c013d42-c983-4102-9233-ca54b8f3d1a1.aspx) and also start reading Windows Internals part 1. Thanks for sharing Windows under the hood stuff with public.

  • EdwardEdward

    can you point us to that MS Data Center link you talked about @ 9:15


  • EdwardEdward

    Never mind. I'm a tool.. it was at the top in the "Resources".

  • Andrew Richardswindev Andrew Richards

    @Edward: Smiley

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.