debugging windbg crash-dumps memory-dump

Exqueue shows only waiting worker threads on forced memory dump

I'm debugging a system hang/freeze issue by forcing a complete memory dump (ctrl + scrl + scrl method) and I don't understand some of the data.

When I run !exqueue 6 I see 6 Critical, 8 Delayed and 1 HyperCritical thread but each contains a similar stack with only the following calls:

nt!KiSwapContext+0x7a
nt!KiCommitThreadWait+0x1d2
nt!KeRemoveQueueEx+0x323
nt!ExpWorkerThread+0xe9
nt!PspSystemThreadStartup+0x5a
nt!KxStartSystemThread+0x16

To my knowledge these are all threads that were created but not given any work, right?

Is this what is actually happening on the system at the time of the dump or is this just the effects of forcing a dump with this method?

Is this also why the only running threads are actually intelppm under the Idle PID and the breakpoint?

                        [fffff80003617180 Idle]
   0.000000  fffff80003616cc0 ffff8835 RUNNING    nt!KeBugCheckEx
   0.000000  fffff880009f9fc0 ffff92bb RUNNING    intelppm!MWaitIdle+0x19
   0.000000  fffff88002f6ffc0 ffff9191 RUNNING    intelppm!MWaitIdle+0x19
   0.000000  fffff88002fe1fc0 ffff93c4 RUNNING    intelppm!MWaitIdle+0x19

It doesn't seem like I'm actually getting an accurate picture of the work queue or running threads at the time of the dump. Am I misinterpreting the data or is it all because of how it was captured?

Any help would be appreciated.

Solution

During boot your system will automatically create a number of system threads. Later on the system can create more system threads if it deems it necessary based on load. The system threads that you are showing does not have anything to do right now but they might have been busy earlier on. I don't think (6, 8, 1) threads indicates anything abnormal wrt. load.

The 3 threads that were executing intelppm were idling and then most likely power collapsed.

There could be other reasons for a system to become unresponsive than high load. Sometimes all it takes is one thread being deadlocked. So perhaps look at what other threads were doing and if any one of them have a "suspicious" looking call stack. Also did core 0 (which executed the bugcheck) do anything special before executing the bugcheck?