
BSOD is no reason to panic. Find out the nature of the "screen of death"
Until recently, I thought that the only way to find out about the cause of BSOD is through white letters on the blue "death screen." Recent events have expanded my knowledge in the field of troubleshooting a little, and I want to share this knowledge with you, harazhiteli.
There was another breakdown of the system at the next client. “The blue screen, and nothing stirs” - this is how the girl who worked at the computer described the problem. It was about 18 in the evening, and I did not want to leave at all. Calling the client back, I said that I would look at the computer remotely, although I myself understood that I would have to deal with it tomorrow. Nevertheless, conscience did not allow just to forget about the computer until tomorrow.
The only reasonable thought that I had then was to read the Event Viewer, which I did.

Here's an approximate entry that caught my attention. Well, since the system generated a bugcheck, why not read it.
I googled a little about opening the “.dmp” file, and came across Debugging Tools for Windows. This is part of the large Microsoft Windows SDK for Windows 7 product. Why look for solutions on the side when the developer himself provides them. It took quite a bit of time to install Debugging Tools (as well as to install the .NET Framework 4, which is necessary for work). Naturally, during the installation I did not select additional components, otherwise my remote diagnostics would drag on for a long time (see screenshot)

I understand that using a tool with such huge functionality just to look at a .dmp file is not entirely correct, but, except of this, I don’t need him.
So - the program is installed, it remains only to look at the minidump itself. To do this, run WinDbg from the Debugging Tools for Windows package, and select "Open crash dump" in the "File" menu.

After a short analysis, the program gives an estimated cause of the BSOD call.

In my case, the reason was the wrong Storage Controller driver. Having downloaded a fresh driver from the website, we managed to overcome the cause of inoperability.
Unfortunately, the causes of malfunctions often do not lie on the surface, and such an analysis may not bring the desired result.
There was another breakdown of the system at the next client. “The blue screen, and nothing stirs” - this is how the girl who worked at the computer described the problem. It was about 18 in the evening, and I did not want to leave at all. Calling the client back, I said that I would look at the computer remotely, although I myself understood that I would have to deal with it tomorrow. Nevertheless, conscience did not allow just to forget about the computer until tomorrow.
The only reasonable thought that I had then was to read the Event Viewer, which I did.

Here's an approximate entry that caught my attention. Well, since the system generated a bugcheck, why not read it.
I googled a little about opening the “.dmp” file, and came across Debugging Tools for Windows. This is part of the large Microsoft Windows SDK for Windows 7 product. Why look for solutions on the side when the developer himself provides them. It took quite a bit of time to install Debugging Tools (as well as to install the .NET Framework 4, which is necessary for work). Naturally, during the installation I did not select additional components, otherwise my remote diagnostics would drag on for a long time (see screenshot)

I understand that using a tool with such huge functionality just to look at a .dmp file is not entirely correct, but, except of this, I don’t need him.
So - the program is installed, it remains only to look at the minidump itself. To do this, run WinDbg from the Debugging Tools for Windows package, and select "Open crash dump" in the "File" menu.

After a short analysis, the program gives an estimated cause of the BSOD call.

In my case, the reason was the wrong Storage Controller driver. Having downloaded a fresh driver from the website, we managed to overcome the cause of inoperability.
Unfortunately, the causes of malfunctions often do not lie on the surface, and such an analysis may not bring the desired result.