BSOD caused by ntoskrnl.exe – how to find out what exactly crashes the system?
ntoskrnl.exe is a Windows Kernel image that provides kernel and executive layers of the Windows NT kernel space, and is responsible for various system services. If your Windows is configured to save minidump files after every BSOD (C:\Windows\Minidump) you can sometimes be a little bit disappointed when you open minidump file with BlueScreenView or something similar to see what has crashed your system and the only thing you’d see would be … ntoskrnl.exe and this means that pretty much anything could crash it. Not much help, huh?
I just had such issue like this one and after a bit of root cause analysis I figured out how to find out what exactly causes the BSOD.
What we need is a proper debugger, WinDbg, which is a part of Debugging Tools For Windows is exactly what we need.
Microsoft made it available for download for free from here, which is nice. What we need is to download and install WDK 8.
Once installed, open WinDbg from your start menu then click “File” and “Open Crash Dump” and point to your minidump file (you don’t need to “save information for workspace“)
This will open your minidump file in command window, as you can notice, you have command box bellow. What you see is a generic cause of the BSOD with “Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win 32 error” or similar error.
1. Now, you need to check Symbol and Executable image paths.
– to check Symbol path: execute .sympath in the command box – if the .sympath returns <empty> , execute .symfix – this should set symbol store to point to msdl.microsoft.com/download/symbols if it won’t for some reasons, you may want to specify the path manually, to do so press Ctrl+S to open Symbol Path window and paste msdl.microsoft.com/download/symbols , select “reload” and click OK.
– run .sympath again and it should return with:
0: kd> .sympath Symbol search path is: srv* Expanded Symbol search path is: cache*;SRV*http://msdl.microsoft.com/download/symbols
– now, check Executalbe image paths by executing .exepath. This should return with :
0: kd> .exepath Executable image search path is: srv* Expanded Executable image search path is: cache*;SRV*http://msdl.microsoft.com/download/symbols
– you now need to re-load ntoskrnl.exe, by executing .reload /f /v ntoskrnl.exe . It should return with something similar to this:
AddImage: \SystemRoot\system32\ntoskrnl.exe
DllBase = fffff800`02e11000
Size = 005e6000
Checksum = 0055a245
TimeDateStamp = 51fb06cd
DBGHELP: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86\sym\ntoskrnl.exe\51FB06CD5e6000\ntoskrnl.exe - OK
DBGENG: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86\sym\ntoskrnl.exe\51FB06CD5e6000\ntoskrnl.exe - Mapped image memory
DBGHELP: nt - public symbols
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86\sym\ntkrnlmp.pdb\444961FE7BC64E8ABAA9F36D9855C08C2\ntkrnlmp.pdb
– now its time to re-analyze the mimidump file to check what exactly is causing our BSOD.
To do so, execute the following command: !analyze -v
Once this is done, it should tell you exactly what is the failing module. In my example the return info was:
RVPOWERSTATE_SUBCODE: 3 DRIVER_OBJECT: fffffa8007461730 IMAGE_NAME: usbhub.sys DEBUG_FLR_IMAGE_TIMESTAMP: 52954dd0 MODULE_NAME: usbhub FAULTING_MODULE: fffff88004f27000 usbhub CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
STACK_COMMAND: kb FOLLOWUP_NAME: MachineOwner FAILURE_BUCKET_ID: X64_0x9F_3_IMAGE_usbhub.sys BUCKET_ID: X64_0x9F_3_IMAGE_usbhub.sys
Now I know its the usbhub driver in my case that causes BSOD.