Almost everyone has experienced the situation where windows can stop responding and hangs, no mouse movement, no keyboard and even worse... the Blue Screen of Death! (aka BSOD)
When faced with this situation, what do you do? Google, right?
Then you read some posts in various help forums that might suggest you do a disk scan. Others tell you to restart Windows with the Last Good Known Configuration or to swap out your memory chips. The extremists may even suggest you need to format and reinstall Windows!
You have to know that in most cases, Windows' hangs and crashes are related to a misbehaving or bad driver and that generally happens after you install a new device, or when you upgrade to a new Windows version. Sometimes, even up to date loaded device drivers can just become corrupted and thus need replacing.
A common crash source is a reference to a memory address that caused an access violation, either a write operation to read-only memory, or a read operation on an address that is not mapped. It can also be caused by an unexpected exception the driver didn't handle correctly.
But why doesn't Windows just ignore the exception and let the device driver continue to execute as if nothing had happened?
Imagine if Windows let the system continue running with these parts of system memory corrupted. At some point in time, the content of this memory would be written back to disk and the next time Windows booted, a corrupt image would load into memory and the system would just continue to crash again and again. Eventually, you would be forced to reinstall your OS.
So when a kernel-mode driver does such operations, windows makes the whole system crash in order to preserve the integrity of the system.
Now the question is; how can I identify the crash source and solve this problem?
The answer lays in the "C:\Windows\Minidump" folder of your system hard drive. When Windows crashes or hangs, it copies the content of the memory considered relevant to the crash into a dump file.
The Dump file contains the stop code, (called Bug Check) the list of loaded device drivers, the data structures that describe the current process and thread, the kernel stack for the thread that caused the crash and so on.
To read the dump file you will need to use something like Windbg (part of the Windows Software Development Kit), that can be downloaded from here.
Once installed, open the generated dump file in Windbg and type this magic command
This command will analyse the dump file and try to give you the reason for the crash by identifying the faulting driver. Read a post I made about a real case study here.
The dump file also contains a Bug Check. With that bug code, you can navigate to the Microsoft Bug Check reference website to find out more about the cause of the crash.
The bottom line is this; the next time your Windows installation hangs or crashes, remember this windbg command "!Analyze -v" as it will save you a lot of time when trying to solve your problem.
Another quick tip for when you decide to upgrade to a newer Windows version is to always search for new driver versions on the computers manufacturer website. If you have a non-branded machine, check the computer's mainboard (aka motherboard) manufacturers website for updated drivers.
You can also use a Windows built-in tool called "Driver Verifier Manager"
Run it from a command line by simply typing "verifier"
If you find an outdated driver version, then go ahead and update it.
See the example screen shots provided below to learn how to go about using it.
I hope you found this information useful.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.