Maybe :-),
I like BSV just fine, but when I suggest it, I include a disclaimer:
BlueScreenView tries to locate the right driver or module that caused the blue screen by looking inside the crash stack. However, be aware that the driver detection mechanism is not 100% accurate, and you should also look in the lower pane, that display all
drivers/modules found in the stack.
Sometimes BlueScreenView will implicate XP files as the cause of the crash (ntoskrnl.exe, win32k.sys, hal.dll, etc.) but they are probably not the real cause of the crash (BSV does the best it can) and you need to look at some other crash dumps or use the Windows
debugging tools to dig a little deeper into the crash dump to find the real cause.
Even WhoCrashed says:
Possibly this problem is caused by another driver that cannot be identified at this time.
Using the Windows debugging tools, it says:
Debugging Details:
BUGCHECK_STR: 0x1a_4128b
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: wmpnetwk.exe
LAST_CONTROL_TRANSFER: from 80525171 to 805338be
STACK_TEXT:
b9d54b9c 80525171 0000001a 0004128b 006d1201 nt!KeBugCheckEx+0x1b
b9d54bd0 804e71b8 0000062e 00001b18 006d1201 nt!MiSwapWslEntries+0x157
b9d54bfc 804e9138 b9d54c28 c050a2fc 89a4ea28 nt!MiUpdateWsle+0x159
b9d54c20 804e99ac 00001b18 c01f2200 81d9a190 nt!MiAddValidPageToWorkingSet+0x99
b9d54c50 804e98b4 00000000 7c880b0f c01f2200 nt!MiCompleteProtoPteFault+0x167
b9d54c80 804e92b7 00000000 7c880b0f c01f2200 nt!MiResolveProtoPteFault+0x17d
b9d54cfc 804e9036 00000000 7c880b0f c01f2200 nt!MiDispatchFault+0x13b
b9d54d4c 804e172b 00000000 7c880b0f 01000001 nt!MmAccessFault+0xc09
b9d54d4c 7c880b0f 00000000 7c880b0f 01000001 nt!KiTrap0E+0xcc
WARNING: Frame IP not in any known module. Following frames may be wrong.
00c4fb20 00000000 00000000 00000000 00000000 0x7c880b0f
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!MiSwapWslEntries+157
80525171 8b4d10 mov ecx,dword ptr [ebp+10h]
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt!MiSwapWslEntries+157
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
DEBUG_FLR_IMAGE_TIMESTAMP: 50338d20
IMAGE_NAME: memory_corruption
FAILURE_BUCKET_ID: 0x1a_4128b_nt!MiSwapWslEntries+157
BUCKET_ID: 0x1a_4128b_nt!MiSwapWslEntries+157
Followup: MachineOwner
I will use BSV first usually, then if it implicates an XP file like hal.dll, ntoskrnl.exe, win32k.sys or whatever else it says about XP files, I just don't believe it and I will use the Windows debugger.
Even if BSV says it is some other file that you recognize as third party, I still use the debugger since I can get more information about the crash and other system information (like system make and model, etc.) and if there is a third party file, you can also
usually get the version of the file and other things.
If we get more crash dumps, and they keep pointing to the same thing, we can look more closely at that.
I have BSV in my minidump folder and made a little batch file that runs the Windows debugger in there too, so I just copy the crash dumps to look at in my minidump folder, run BSV and see what it has to say, then run the batch file that launches the debugger
(I am so lazy) and see what I can see in that.