When writing custom extensions for Windbg to analyse user-mode crash dumps (using the IDebugSystemObjects4 interface provided by dbgeng.h), IDebugSystemObjects4–>GetTotalNumberThreads returns a smaller number than Strike/SOS.

There is no documentation about where IDebugSystemObjects4 gets the thread count from — it just states:

The GetTotalNumberThreads method returns the total number of threads for all the processes in the current target, in addition to the largest number of threads in any process for the current target.

(Emphasis mine.)

Below is an example output from Windbg:

0:000> <Custom Windbg Extension Method Here>
Getting IDebugSymbols…
Getting IDebugSystemObjects…
Getting GetTotalNumberThreads…
Total Threads: 581
Largest Process: 581
Frames: 32
0:000> !threads
ThreadCount: 587
UnstartedThread: 0
BackgroundThread: 26
PendingThread: 0
DeadThread: 47
Hosted Runtime: no

Note that the IDebugSystemObjects4–>GetTotalNumberThreads method is returning 581 threads but Strike/SOS is returning 587.

For what it’s worth, Strike/SOS gets this data from the DAC — which is, presumably, a different source than IDebugSystemObjects4 is getting the thread count from.

Is this a bug in dbgeng.h? If not, is it because IDebugSystemObjects4 ignores finaliser threads; whereas those are not ignored when committed to the DAC?

Also, sorry if this is the wrong place for this, I was thinking Windows SDK-related questions/bugs would fall under “Windows OS Platform”.

​When writing custom extensions for Windbg to analyse user-mode crash dumps (using the IDebugSystemObjects4 interface provided by dbgeng.h), IDebugSystemObjects4–>GetTotalNumberThreads returns a smaller number than Strike/SOS. There is no documentation about where IDebugSystemObjects4 gets the thread count from — it just states: The GetTotalNumberThreads method returns the total number of threads for all the processes in the current target, in addition to the largest number of threads in any process for the current target. (Emphasis mine.) Below is an example output from Windbg:  0:000> <Custom Windbg Extension Method Here>
Getting IDebugSymbols…
Getting IDebugSystemObjects…
Getting GetTotalNumberThreads…
Total Threads: 581
Largest Process: 581
Frames: 32
0:000> !threads
ThreadCount: 587
UnstartedThread: 0
BackgroundThread: 26
PendingThread: 0
DeadThread: 47
Hosted Runtime: no  Note that the IDebugSystemObjects4–>GetTotalNumberThreads method is returning 581 threads but Strike/SOS is returning 587. For what it’s worth, Strike/SOS gets this data from the DAC — which is, presumably, a different source than IDebugSystemObjects4 is getting the thread count from. Is this a bug in dbgeng.h? If not, is it because IDebugSystemObjects4 ignores finaliser threads; whereas those are not ignored when committed to the DAC? Also, sorry if this is the wrong place for this, I was thinking Windows SDK-related questions/bugs would fall under “Windows OS Platform”.  Read More

​