WinDbg is designed for people developing their own kernel mode drivers. Unless you're interested in trying to track down which function caused the BSOD, you shouldn't need to 'go deeper' than which driver crashed.
Thank you for your reply.
This is precisely what I want to do, try to re-create the driver scenario that caused the crash, "Force BSOD".
For instance, I'm dealing with the ambiguous ""ntkrnlmp.exe" BSOD. This can be any hardware or software issue. In the WinDbg it shows the call stack as:
STACK_TEXT:
fffff880`0a06c888 fffff800`032f7b40 : 00000000`0000001a 00000000`00041790 fffffa80`0092cf10 00000000`0000ffff : nt!KeBugCheckEx
fffff880`0a06c890 fffff800`0325d405 : ffffffff`00000000 00000000`0789ffff fffffa80`00000000 fffffa80`08291060 : nt! ?? ::FNODOBFM::`string'+0x355e4
fffff880`0a06ca50 fffff800`0355d6da : fffff8a0`017f3050 00000000`00000001 00000000`00000000 fffffa80`08291060 : nt!MmCleanProcessAddressSpace+0x679
fffff880`0a06caa0 fffff800`0353efb8 : 00000000`00000000 00000000`00000001 00000000`fffdb000 00000000`00000000 : nt!PspExitThread+0x56a
fffff880`0a06cba0 fffff800`0328b453 : fffffa80`07977060 00000000`00000000 fffffa80`08291060 00000000`05595110 : nt!NtTerminateProcess+0x138
fffff880`0a06cc20 00000000`771215da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0018dfc8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x771215da
This is the last memory transfers before the BSOD. I'm trying to figure out if I can discern exactly when, what and where caused the BSOD. Is it hardware, or is it software?
In the case of the ntkrnl crashes, I DO need to track down the functions
