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.
