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:

– now, check Executalbe image paths by executing .exepath. This should return with :

– you now need to re-load ntoskrnl.exe, by executing .reload /f /v ntoskrnl.exe . It should return with something similar to this:

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


Now I know its the usbhub driver in my case that causes BSOD.



Leave a Reply