Microsoft Windows 7 Crashes, Restarts or a Blue Screen Appears

Summary: Find out what are Blue Screen errors, why they occur, how to recognize them, and how to resolve them by exploring this page.

Article Content


This article describes what Windows 7 Blue Screen errors are, why they occur, and how to recognize and fix them.

Table of Contents:

  1. What Is a Blue Screen Error?
  2. Run an online diagnostic
  3. Troubleshooting Common Blue Screen Error Messages
    1. 0x000000ED and 0x0000007B
    2. 0x00000024
    3. 0x0000007E and 0x0000008E
    4. 0x00000050
    5. 0x000000D1
    6. 0x000000EA
  4. Using the Windows Debugger

This article is specific to Microsoft Windows 7.
Click below to change the operating system.

Dell Recommended:

Resolving stop (blue screen) errors in Windows 7 (Microsoft Content)

Troubleshoot Blue Screen Issues in Windows (Microsoft Content)

What Is a Blue Screen Error?

When Windows encounters certain situations, it stops and the resulting diagnostic information is displayed in white text on a blue screen. The appearance of these errors is where the term "Blue Screen" or "Blue Screen of Death" has come from.

Blue Screen errors occur when:

  • Windows detects an error that it cannot recover from without losing data
  • Windows detects that critical OS data has become corrupted
  • Windows detects that hardware has failed in a nonrecoverable fashion
The error message has changed from a dense wall of information in Windows NT 4.0 to the comparatively sparse message in modern versions of Windows.

Run an online diagnostic

Dell provides online diagnostics that can identify problems with your computer hardware or configuration that may be causing the issue. Visit the Dell Online Diagnostics to get more information and run a scan of your computer.

Troubleshooting Common Blue Screen Error Messages


These two errors have similar causes and the same , steps apply to both of them. These stop codes always occur during the startup process. When you encounter one of these stop codes, the following has happened:
  1. The system has completed the Power-On Self-Test (POST).
  2. The system has loaded NTLDR and transferred control of the startup process to NTOSKRNL (the kernel).
  3. NTOSKRNL is confused. Either it cannot find the rest of itself, or it cannot read the file system at the location it believes it is stored.
    To troubleshoot this error, you must find out why the Windows kernel is confused and fix the cause of the confusion.
Things to check
  • The SATA controller configuration in the system BIOS: If the SATA controller gets toggled from ATA to AHCI mode (or vice versa), then Windows cannot talk to the SATA controller because the different modes require different drivers. Try toggling the SATA controller mode in the BIOS.
  • RAID settings: You may receive this error if you've been experimenting with the RAID controller settings. Try changing the RAID settings back to Autodetect (usually accurate).
  • Improperly or poorly seated cabling: Try reseating the data cables that connect the drive and its controller at both ends.
  • Hard drive failure: Run the built-in diagnostics on the hard drive. Remember: Code 7 signifies correctable data corruption, not disk failure.
  • File system corruption: Launch the recovery console from the Windows installation disc and run chkdsk /f /r.
  • Improperly configured BOOT.INI (Windows Vista): If you have inadvertently erased or tinkered with the boot.ini file, you may receive stop code 0x7B during the startup process. Launch the recovery console from the Windows installation disc and run BOOTCFG /REBUILD



This stop code indicates that the NTFS file system driver encountered a situation that it could not handle, and is almost always caused by 3 things:
  • Data corruption on the disk
  • Data corruption in memory
  • The system completely running out of memory (this typically only happens on heavily loaded servers)
Things to check
  1. Reseat the memory and all drive data cables to eliminate data corruption issues stemming from poorly or improperly seated hardware.
  2. Run a complete memory and hard drive diagnostic. The quick test is not thorough enough here. You need to run the full system diagnostic.
  3. If those diagnostics pass, run a full file system check from the Recovery Console (chkdsk /f /r) to detect and (potentially) fix any corrupted data.
  4. If none of the above solves the issue, reinstall Windows.
  5. If that does not fix the issue, replace the hard drive.



These two errors indicate that a program running in the kernel encountered an unexpected condition that it could not recover from. They have identical troubleshooting and resolution steps, and you will probably need to use the Windows Debugger to find out what caused the error.
Things to check
  • If the Blue Screen message mentions a driver or library file, figure out what driver or application that file is part of and update or disable it.
  • Update the system BIOS to the latest available revision.
  • Uninstall any recently installed programs, and roll-back any recently installed drivers.
  • Run diagnostics on the computer's memory.


This stop code indicates that the system tried to access a nonexistent piece of memory. This is typically due to:

  • A driver trying to access a page of memory that is not present
  • A system service (ex. virus scanner) failing in an exceptional way
  • Faulty or incorrectly seated memory
  • Corrupted data on the hard drive
Use the Windows Debugger to pinpoint the exact cause of these errors.
Things to check
  1. If the Blue Screen error mentions a driver or library file, figure out what driver or program the file is a part of and either upgrade to the latest version or uninstall the driver or program.
  2. If the error happens during the startup process, try booting to the Last Known Good Configuration.
  3. If the error started appearing after a program or driver was installed, uninstall that program or driver.
  4. Try running a full hard drive and memory diagnostic after reseating the memory and hard drive data cables.



This stop code indicates that a driver tried to access a certain area of memory when it should not have, meaning there is a flaw in the driver itself. The goal of your troubleshooting is to find that driver and either disable or replace it. Use the Windows Debugger to troubleshoot this error.
Without the debugger, you are limited to uninstalling, updating, or rolling back the driver that contains the driver file the Blue Screen mentions.




This Blue Screen error indicates that a device driver-almost always a video card driver-is stuck waiting for something (usually a hardware operation) to happen. Most of you have probably seen nv4_disp.sys associated with this Blue Screen.
Things to check:
  1. Ensure that the video drivers are updated to the latest Dell version.
  2. The system BIOS is fully up to date.
  3. If both the video driver and the system BIOS are fully up-to-date, check with the manufacturer for recent driver updates.
  4. As a last resort, try exchanging the video card.

Reinstalling Windows is not likely to prevent this error from reoccurring.


Using the Windows Debugger

The Windows Debugger is one of the primary tools that are used by Microsoft software developers and support staff to analyze and resolve errors that result in memory dumps.

The Windows Debugger is a powerful tool with many useful applications, but for this article, we are only interested in its ability to analyze memory dump files that are generated by blue screen errors to determine the cause of the error.

Before you can use the tool, keep in mind the following:

  • The Windows Debugger is not a native Windows tool. You must download and install the application (15 MB) from the Microsoft web site. Administrator access is required to install the tool.
  • The Debugger requires some minor customization before use.
  • The Debugger can take anywhere from 30 seconds to two minutes to fully analyze a memory dump.
To use the tool, follow these steps:
  1. Download and install the Windows Debugger from the Microsoft Web Site 


    If you use Google to search for "windows debugger," the first result will be the Windows Debugger home page.


  2. Once installation completes click Start, click All Programs, click Debugging Tools for Windows, then click WinDbg to open the Windows Debugger.


  3. Configure the symbol path used by the debugger to turn addresses in the memory dump file into meaningful location names: expand the File menu, select Symbol File Path, type "SRV*c:\debug_symbols*" in the dialog box then click OK.


  4. Open a minidump file: expand the File menu, select Open Crash Dump, select the desired dump file and click Open.


    The system usually stores minidump files in either: C:\WINNT\Minidump\ or C:\Windows\Minidump\. The files will be named miniMMDDYY-NN.dmp, where MMis the month, DD is the day, and YY is the year in which the dump file was created. NN is the sequence the dump files were created in if multiple dumps were generated on the same day (the first crash dump on a given day will be numbered 01, the second 02, etc.).


  5. The debugger opens the dump file and give a brief description of what caused the system to crash. (Figure 2)


    The first time that you use the Debugger to open and dump file on a system, it will take a few minutes to download symbol information in the background before it returns any information.

    Figure 2: Windows Debugger

    SLN115577_en_US__2W_cat_Caption1_cc_v1 Suggested command for the Debugger's command line

    SLN115577_en_US__3W_cat_Caption2_cc_v1 Stop code from the blue screen (1000007F is the same as 0x7F)

    SLN115577_en_US__4W_cat_Caption3_cc_v1 What Windows thinks caused the crash (atapi.sysin this example, you will sometimes see things like memory_corruption


  6. When it returns this preliminary analysis, the Debugger tells you how to dig deeper. Type "!analyze -v" in the command line (kd>) field at the bottom of the window and press theEnter key to have the WinDbg perform a detailed analysis of the file.


    The results will be lengthy, and you may have to scroll vertically within the Debugger's window to locate all the pertinent information.

    Figure 3: Analyze the Results

    SLN115577_en_US__2W_cat_Caption1_cc_v1 A detailed explanation of the stop code (in the example, you can see that the kernel encountered an EXCEPTION_DOUBLE_FAULT (8), or an error while trying to process an error)

    Figure 4: Further Analysis of the Results

    SLN115577_en_US__2W_cat_Caption1_cc_v1 The bug check code (notice in the example it includes the number 8, indicating the double fault)

    SLN115577_en_US__3W_cat_Caption2_cc_v1 The number of times the system has crashed with this exact error (typically 1)

    SLN115577_en_US__4W_cat_Caption3_cc_v1 The bucket in which Windows has categorized the crash

    SLN115577_en_US__11W_cat_Caption4_cc_v1 The stack trace at the time the system crashed, with the most recently called procedure on top (you can see in the example the system crashed while processing a request from the IDE controller)

    Figure 5: Additional Analysis

    SLN115577_en_US__2W_cat_Caption1_cc_v1 The name of the module the system was in when it crashed. On an actual system, the module name is a link that you can click to receive some useful information about the module


Article Properties

Last Published Date

21 Feb 2021



Article Type


Rate This Article

Easy to Understand
Was this article helpful?

0/3000 characters