So it happened, a serious Windows System Crash aka BSOD (Blue Screen Of Death). There may be hundreds of reasons why your Windows System has crashed but event logs just say that it crashed and wasn’t shut down clean – obvious!

We need to look a bit deeper in order to see what probably caused that behaviour. Let’s start with why it crashes. Windows crash most of time when:

  • a faulty or bad written driver wants to execute code outside its address range or tries to use different IRQ that it suppose to
  • a system service that is using a driver to perform specific tasks fails, thus driver fails. Services like this are often Firewalls and other parts of antivirus software. The work that way in order to avoid being stopped by a virus or user. You can disable it or set it to allow everything but it is working anyway
  • memory error. Faulty RAM can be problematic to narrow down but keep this in mind, that RAM sometimes just fails
  • other hardware error. Most of the parts that would be devices needing dedicated drivers, thus we are going to point 1

Ok so what to do if it crashes?

Mostly, ordinary reset would do the job. Trust me. Windows these days is a bit smarter that in Xp and previous era and can disable problematic drivers and services automatically. If after restart, or sometimes 2 or 3 Windows loads up and some service, software or device isn’t working. That was probably accused by Windows of crashing. Try to find newer/fixed versions.

But this is not the point! We WANT to know what caused this!

So, there are two most used by me and free tools to debug BSOD:

First one is quite easy to use. Just download, open as administrator and it should automatically find crash dumps and point to file that caused this. The thing is, it often blames ntoskrnl.exe which is Windows Kernel… Ok. So Kernel Crashed, and what next?

Next is more advanced tool, but litte harder to use. I personally prefer WinDbg over BlueScreenView but is completely up to you.

First you need to download Windows SDK and install only Debugging Tools for Windows from install options.

Then when you open WinDbg, you need to provided “symbols path” by selecting File->Symbols File Path or by pressing CTRL+S

Paste below code:

It should look like:


Output should look like:

Then, select File->Open Crash Dump or press CTRL+D

Select crash dump, usually located in C:\Windows\MiniDump or in other folder if debugging dumps from other computers.


Now, in analyzer window execute command:

!analyze -v

After a couple of seconds we should get output similiar to below:

As we can see in above example, driver fault related to TeamViewer Service caused blue screen. This still might be misleading, since it tells us what directly caused BSOD but didn’t tell us WHY. It would be possible when debugging full memory dump, looking at the related memory stack and loaded files but I think it is more kind of a art that really useful knowledge for most people. Of course people who really need that kind of a info already know how to use above tools, so in my opinion explaining it here is unnecessary. In this particular example driver fault might be related to either anti-virus blocking it or RAM error. I would check RAM, run chkdsk to check disk for errors and let anti-virus software to fully update assuming TeamViewer is in newest available version.