What I *think* I understand is that ntkrnlmp.exe is the x86 Arch with 4 Gb of physical memory or less.
The highlighted (bold) is the process (ntkrnlmp.exe) and the current thread (000 : 1). And that the only process / thread in the mini dump is the one the system thought caused the crash.
So my questions are:
Does that mean that there were 6 threads executing at the time of the crash for that process?
How does it, if at all, relate to the !thread command?
0: kd> !thread
GetPointerFromAddress: unable to read from fffff800030c4000
THREAD fffffa8004f21040 Cid 0004.002c Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0
GetUlongFromAddress: unable to read from fffff80003003ba4
Owning Process fffffa8004ea6b30 Image: System
Attached Process N/A Image: N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount 93973
Context Switch Count 31842
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
Win32 Start Address nt!ExpWorkerThread (0xfffff80002e9e740)
Stack Init fffff8800335bdb0 Current fffff8800335b440
Base fffff8800335c000 Limit fffff88003356000 Call 0
Priority 13 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff800`00ba2ae8 fffff800`02e94769 : 00000000`0000000a 00000000`0000000b 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff800`00ba2af0 fffff800`02e933e0 : 00000000`00000002 fffff800`02ec0180 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff800`00ba2c30 fffff880`0410ae79 : fffffa80`079de000 00000000`00000000 fffff800`00ba2e20 fffff980`1f598ee0 : nt!KiPageFault+0x260 (TrapFrame @ fffff800`00ba2c30)
fffff800`00ba2dc0 fffffa80`079de000 : 00000000`00000000 fffff800`00ba2e20 fffff980`1f598ee0 00000000`00000000 : nusb3xhc+0xde79
fffff800`00ba2dc8 00000000`00000000 : fffff800`00ba2e20 fffff980`1f598ee0 00000000`00000000 ffffe4fd`6df084c0 : 0xfffffa80`079de000
Features for Windbg for post mortem debugging depend on two things: dump size, and whether it's kernel or user mode dump. The dump size for kernel dumps ranging from smallest to largest is minidump, kernel dump, and full memory dump, respectively. For user mode, I believe it's just minidump or full dump (obviously no kernel dump). The full dump on the kernel side, however, is an image of the entire contents of memory at the time of the crash, so this includes both user and kernel mode stuff. Of course, like with any dump, the data not retained is anything stored on disk, such as everything in the paging file, and any file data on files that has been hooked on but has not been copied over to memory.
There are also features like stepping and whatnot that are exclusive to live debugging. There are also features restricted based on if you have symbols to a particular module, and if so, what symbols (public or private).
While Windbg is generally held as a kernel debugger, it has a copious amount of other functions that makes it extremely versatile beyond that simple definition.
Oh, btw, the reason why you have the weird process and threads list for ntkrnlmp.exe is because it is not a real process in the conventional sense (if I recall correctly). And as for ntkrnlmp.exe itself, it is what's loaded for multi-processor systems with 64-bit. The 32-bit MP alternative is ntkrpamp.exe. You can easily distinguish a 32-bit from a 64-bit system by looking at all the memory addresses in Windbg. If they are quadword, you're dealing with 64-bit.