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 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 , 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*

– 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*

– 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:


DRIVER_OBJECT: fffffa8007461730

IMAGE_NAME:  usbhub.sys



FAULTING_MODULE: fffff88004f27000 usbhub





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.



Leave a Reply

Your email address will not be published. Required fields are marked *