Forum Discussion

felsokning's avatar
felsokning
Copper Contributor
Oct 20, 2024

dbgeng.h: GetTotalNumberThreads Returns Incorrect Thread Count (According to DAC)

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 https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/controlling-threads-and-processes for all the https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/controlling-threads-and-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, https://github.com/dotnet/diagnostics/blob/6a90923439dc43693f2a2fc8766b3cdb2c4dd366/src/SOS/Strike/strike.cpp#L4358 -- 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".

No RepliesBe the first to reply

Resources