Windbg: Processes and Threads in mini dump?????

[Shintaro]

I was hoping that someone could explain the "Processes and Threads" tree in Windbg.

000:f0f0f0f0 ntkrnlmp.exe
000 : 1
000 : 2
000 : 3
000 : 4
000 : 5
000 : 6

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?

[FONT=Lucida Console]0: kd> !thread
GetPointerFromAddress: unable to read from fffff800030c4000
THREAD fffffa8004f21040  Cid 0004.002c  Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0
Not impersonating
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.
UserTime                  00:00:00.000
KernelTime                00:00:00.000
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[/FONT]

 

[jcgriff2]

Hi -

The Processes and Threads window from Windbg -

​

ntkrnlmp.exe = Windows NT Kernel w/ multiple core CPU

On the left in screenshot -
000 = Proc 0
001 = Proc 1

Threads appear under each process(es) that you are debugging.

That is for live kernel debugging.

BSODs produce post-mortem dumps.

Use the BSOD scripts - BSOD Processing Scripts v1.1.0.0


Regards. . .

jcgriff2

 

[Shintaro]

Thanks jcgriff2,

I suppose what is not clear to me is what (commands an windbg features) is available in a post-mortem dump.

 

[jcgriff2]

Windbg GUI is encouraged as there are times where you will need to further interrogate a dump file.

After loading a dump file, paste this into kd> command line -

 [FONT=Lucida Console]!analyze -v;r;kv;lmtn;.bugcheck;!sysinfo cpuinfo;!sysinfo machineid; !sysinfo cpuspeed; !sysinfo smbios
[/FONT]

1 of the 4 BSOD Scripts output file _99-dbug.txt contains the same logs for each dump that you would get by running the Windbg GUI.

The best place for additional BSOD related info -

BSOD Kernel Dump Analysis Debugging Information​

Regards. . .

jcgriff2

 

[Vir Gnarus]

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.