WhoCrashed (and NirSoft's BlueScreenView) are excellent programs, but they have some serious limitations.
As long as one understands those limitations, they're OK to use (and may save you a lot of time if they're correct!)
I emailed back and forth with Nir Sofer (the owner of NirSoft) about this (several years ago) and the gist was that the 64 bit dumps aren't always interpreted correctly (due to that randomizing of memory thing in 64 bit Windows).
Also, these programs just take what appears to be the "Probably caused By" line - and that's not necessarily the cause. It's just the best guess of the debugger based on that particular register/thread context.
Then they attach a canned speech that says it's either hardware or a driver problem.
A few of us battled with the communities back when Vista came out about hardware vs software.
The community insisted that STOP 0x124 errors (updated from 0x9C errors in XP) were solely hardware errors.
We proved that they could also be compatibility, malware, or even low-level drivers (which revolutionized BSOD analysis for users)
This shows that you can't make a hardware vs software analysis easily. Add to this the fact that diagnostics aren't 100% accurate and BSOD analysis becomes more of an art than a science.
It's most common to see ntoskrnl.exe errors being blamed - and in a fully updated system this is most likely NOT the cause. Here's my canned speech about ntoskrnl.exe:
ntoskrnl.exe (also seen as ntkrnlpa.exe, ntkrnlmp.exe, or ntkrpamp.exe) is the kernel (core) of the Windows operating system. It is protected by security features and the Windows System File Checker. As such, if ntoskrnl.exe was to blame, you'd be experiencing many more problems other than the occasional BSOD.
In most cases tntoskrnl.exe was blamed because a driver (typically a 3rd party driver) has corrupted the memory space that ntoskrnl.exe considers as it's own. When this happens, ntoskrnl.exe typically finds unknown data (from the 3rd party driver) in it's memory space. At this point the OS panics and throws a BSOD to prevent damage to the system.
More info here: https://en.wikipedia.org/wiki/Ntoskrnl.exe
If the culprit (the offending 3rd party driver) hasn't exited yet, then a BSOD analyst may be able to find traces of it in the reports/dumps. If the culprit has exited, then the chase is on and further tests/reports will be needed to help identify what actually caused it.
Finally, just to complete this discussion, there's a huge difference between BSOD analysis for developers and BSOD analysis for users.
The major reason is that developers will change the program that they're working on in order to stop BSOD's - users can't usually do this.
Also, developers work in a more controller environment and are able to test and retest in order to fix things. Users don't have this ability.
So, over the years we've developed a small community dedicated to helping users with BSOD's. We each have our own techniques and preferences - but we work together and help each other out with problem situations. It's not unusual for an analyst to ask for a 2nd set of eyes to see if there's something that they weren't familiar with.
Edited by usasma, 01 June 2016 - 07:56 AM.