As of April 11, 2017, Windows Vista customers are no longer receiving new security updates, non-security hotfixes, free or paid assisted support options, or online technical content updates from Microsoft. This article will no longer be updated and remains for information only. Please visit the Microsoft site
for the full end of support statement.
- What Is a Blue Screen Error?
- Troubleshooting Common Blue Screen Error Messages
- 0x000000ED and 0x0000007B
- 0x0000007E and 0x0000008E
- Using the Windows Debugger
This article describes what Blue Screen errors are, why they occur, how to recognize them, and how to resolve some of the more common error messages.
This article is specific to Microsoft Windows 7.
Click below to change the operating system.
How to fix BlueScreen (STOP) errors that cause Windows Vista to shut down or restart unexpectedly
When Windows encounters certain situations, it halts 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 it cannot recover from without losing data
- Windows detects that critical OS data has become corrupted
- Windows detects that hardware has failed in a non-recoverable fashion
- The exact text displayed has changed over the years from a dense wall of information in Windows NT 4.0 to the comparatively sparse message employed by modern versions of Windows.
These two errors have similar causes and the same troubleshooting 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:
- The system has completed the Power-On Self-Test (POST).
- The system has loaded NTLDR and transferred control of the startup process to NTOSKRNL (the kernel).
- 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.
When troubleshooting this error, your task is to 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 will not be able to 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 the NTFS file system driver encountered a situation 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
- Reseat the memory and all drive data cables to eliminate data corruption issues stemming from poorly or improperly seated hardware.
- Run a complete memory and hard drive diagnostic. The quick test will not be thorough enough here. You need to run the full system diagnostic.
- 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.
- If none of the above solves the issue, reinstall Windows.
- 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 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 means the system tried to access a nonexistent piece of memory, almost always 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
- 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.
- If the error happens during the startup process, try booting to the Last Known Good Configuration.
- If the error started appearing after a program or driver was installed, uninstall that program or driver.
- Try running a full hard drive and memory diagnostic after reseating the memory and hard drive data cables.
This stop code indicates 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/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:
- Ensure the video drivers are updated to the latest Dell version.
- The system BIOS is fully up-to-date.
- If both the video driver and the system BIOS are fully up-to-date, check with the manufacturer for recent driver updates.
- As a last resort, try exchanging the video card.
Reinstalling Windows is not likely to prevent this error from reoccurring.
The Windows Debugger is one of the primary tools used by Microsoft software developers and support staff to analyze and resolve errors that result in memory dumps, and it's available for you.
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 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:
- Download and install the Windows Debugger from the Microsoft Web Site .
If you use Google to search for "windows debugger," the first link returned will be the Windows Debugger home page.
- Once installation completes click Start, click All Programs, click Debugging Tools for Windows, then click WinDbg to open the Windows Debugger.
- 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*http://msdl.microsoft.com/download/symbols" in the dialog box then click OK.
- 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.).
- The debugger will open the dump file and give a brief description of what caused the system to crash. (Figure 2)
The first time 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
Suggested command for the Debugger's command line
Stop code from the blue screen (1000007F is the same as 0x7F)
What Windows thinks caused the crash (atapi.sysin this example, you will sometimes see things like memory_corruption
- 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
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
The bug check code (notice in the example it includes the number 8, indicating the double fault)
The number of times the system has crashed with this exact error (typically 1)
The bucket in which Windows has categorized the crash
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
The name of the module the system was in when it crashed. On an actual system, the module name is a link you can click to receive some useful information about the module, who created it, how old it is, etc