Troubleshooting Windows Blue Screen

Windows Blue Screen can be because of either hardware, software, or device drivers Problem and can be solved in three step.
Step 1:
Check the on screen error, read it properly there may be enough information displayed to point you to the cause.if the error is caused by a kernel-mode driver, the driver image name will be generally shown in the message. Once you know the name of the driver locate it, it can be located on disk and the vendor found by checking the file properties. In terms of finding quick solutions to the problem, the vendor may have an updated driver you can try, or could have a knowledge base you can search for a resolution. Please not: there will be a STOP message in Blue Scree error, each error code has different steps for trouble shoot. if you are not able to translate STOP error code follow Step 2.

Step 2:
If the stop message hasn’t given enough information to start troubleshooting, the next step is to search for more details. Use the Microsoft Support knowledge base, Microsoft TechNet, MSDN, or some other on-line resources when troubleshooting blue screen errors.

For example, a quick search of MSDN or TechNet will reveal that the stop code e.g:0x0000007B, translates as INACCESSIBLE_BOOT_DEVICE, which means that the operating system failed to initialize the storage device it is attempting to boot from during the I/O system initialization. This generally indicates a storage driver problem, and knowing that the problem is caused by the storage subsystem helps to focus troubleshooting to a specific area, which should make the error easier to diagnose.

There are many, many websites offering help with troubleshooting stop errors. My preference is always to start with Microsoft sites or hardware vendor sites, then broaden my searching to other sites and forums if I can’t find what I need. In most cases, someone else will have experienced the same problem, and there may be documented solutions or workarounds offered.

Of course, both steps one and two rely on one crucial thing – that you’ve witnessed and/or recorded the stop message. If you haven’t seen the stop message occur, then you can find the stop error and parameters in the System event log, but unfortunately there are no additional details such as the stack trace. Nevertheless, even with the details of the stop message, there still may not be enough information for a conclusive diagnosis, and at this point we need to move on to step three.

Step3:
The third and final method in my approach is to perform basic analysis on the crash dump file, which all Windows systems are configured by default to create. There are three types of crash dump file, and the settings for controlling which type of files are created can be found on the Advanced tab in the System Properties dialogue box.

Complete Memory Dump

A complete memory dump contains all the data which was in physical memory at the time of the crash. Complete dump files require that a page file exists on the system volume, and that it is at least the size of physical memory plus 1MB. Because complete memory dumps can be very large, they are automatically hidden from the UI on systems with more than 2GB of physical RAM, although this can be overridden with a registry change.

Kernel Memory Dump

A kernel memory dump contains the kernel-mode read/write pages which were in physical memory at the time of the crash. The dump file also contains a list of running processes, the stack of the current thread, and the list of loaded device drivers. Kernel memory dumps are the default on Windows Server 2008 and Windows 7.

Small Memory Dump

A small memory dump (sometimes also called a mini-dump) contains the stop error code and parameters as well as a list of loaded device drivers, and a small amount of other data. Small memory dumps must be analysed on a system which has access to exactly the same images as the system which generated the dump file, meaning that it can be difficult to analyse the dump file on a system other than the one on which it was created.