Login    Forum    Search    FAQ

Board index » Upgrading and Repairing Forum » Scott's Tips




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Troubleshooting Windows crashes (BSOD/Stop errors)
 Post Posted: Mon Jan 26, 2009 8:14 pm 
Offline
Site Admin

Joined: Sun Feb 04, 2007 11:44 am
Posts: 5855
When Windows encounters severe problems such as malware that corrupts or interferes with system operation, bugs in drivers or other low-level software, inconsistencies in data necessary for operation, or even hardware defects, the system is halted or shut down in a condition that is technically called a bug check. Bug checks are also known as stop errors, kernel errors, trap errors, fatal system errors, or system crashes, and since the error information is normally displayed on a blue text-mode screen, they are also informally known as blue-screen or BSOD (Blue Screen Of Death) errors. When these errors occur, in addition to the blue-screen text, Windows will normally save a memory dump file and then restart the system.

Unfortunately the automatic restart makes it almost impossible to read the blue-screen error text, so I recommend reconfiguring the system failure and recovery options in Windows to disable the automatic restart. To do this select Start; Run; enter "sysdm.cpl" and hit enter. Then in the System Properties window select the Advanced tab; Startup and Recovery; Settings; System failure; and uncheck the Automatically restart box. Alternately, to accomplish the same thing you can change the registry directly by entering *one* of the following commands in either the Start; Run box or at a command prompt:

  • REG ADD HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /v AutoReboot /t REG_DWORD /d 0
  • wmic recoveros set AutoReboot = False

Note that both of the above commands accomplish exactly the same thing, so use one or the other. With the automatic restart disabled, if a blue-screen error occurs you will be able to view (and write down) the text on the screen before restarting the system. When looking at blue-screen errors, the hexadecimal number following the word "STOP" is called the bug check or stop error code, and indicates the cause of the problem. For more information, Microsoft has published a detailed list of bug check codes, along with explanations and troubleshooting information.

While the bug check (stop error) code by itself is useful, in most cases it would be helpful to have even more information. By using the Debugging Tools for Windows you can examine the memory dump file created when the stop error occurred, and find a great deal more information about exactly what might have caused the crash.

Windows can create several different types of memory dump files, but the default configuration in most cases is to create a "small memory dump" (also called a minidump) file which is 64KB in size. If not, I recommend you follow the instructions for configuring the dump type here, and set the "Write debugging information" option to "Small memory dump (64KB)". Minidump files include the following information:

  • The Stop message and its parameters and other data
  • A list of loaded drivers
  • The processor context for the processor that stopped
  • The process information and kernel context for the process that stopped
  • The process information and kernel context for the thread that stopped
  • The Kernel-mode call stack for the thread that stopped

Every time a stop error occurs a new minidump file should be created. These files are normally saved in the %SystemRoot%\Minidump (e.g. C:\WINDOWS\Minidump) folder using the name syntax MiniMMDDYY-NN.dmp, where MMDDYY indicates the date the file was created and NN indicates the sequential number of the file(s) created on that day. For example, Mini011009-01.dmp would be the name of the first minidump file created on January 10, 2009.

Microsoft provides several different tools and methods for examining memory dump files, but the best for most uses is the WinDbg.exe utility included in the Debugging Tools for Windows. While the Debugging Tools for Windows are designed to perform many functions only a programmer would use, the ability to examine memory dump files is useful even for non-programmers.

To facilitate examining memory dumps, the WinDbg.exe program needs access to special files containing symbols. Symbols are normally created by the linker used in the programming process, which also creates the final .exe or .dll program file. You won't have access to symbols for most 3rd party drivers and programs you run (unless you wrote and/or compiled them yourself), however Microsoft provides symbol packages containing symbols for files in the OS you are debugging. Unfortunately these symbol packages are very large (up to 1GB or more), and are specific to the OS that produced the memory dump file you are examining (which might be different from the OS you are running). Rather than downloading multiple complete symbol packages, if the system doing the debugging has a broadband internet connection you can instead use the "-y <SymbolPath>" switch to tell WinDbg.exe to use the Microsoft Symbol Server, a public resource with all of the necessary Windows OS symbols. The benefit is that during the debugging process only the specific symbols necessary for the current session will be downloaded to a temporary symbol store, saving both time and disk space in the process.

With that information in mind, here is how to install WinDbg.exe, then add the "-y <SymbolPath>" switch, causing WinDbg to use the Microsoft Symbol Server automatically each time it is run:

  1. Download the Debugging Tools for Windows. If you are running 64-bit Windows, then you want the 64-bit version, otherwise you will want the 32-bit version.
  2. Install the program (complete).
  3. Select Start; Programs; Debugging Tools for Windows; right click on WinDbg and select Properties.
  4. In the Target box, add a space plus the following text to the end of the existing command:

    -y SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

If you are using the 32-bit version, the command shown in the Target box should then be as follows:

    "C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe" -y srv*DownstreamStore*http://msdl.microsoft.com/download/symbols

The text after the "-y" switch tells WinDbg.exe to use the Microsoft Symbol Server directly, and to store the temporarily downloaded symbols in a DownstreamStore folder in the debugging tools installation folder.

Once the program is installed, here's how to use the debugging tools and examine a small memory dump (minidump) file:

  1. Select Start; Programs; Debugging Tools for Windows, WinDbg.
  2. Click File; Open Crash Dump; then browse to the %SystemRoot%\Minidump (e.g. C:\WINDOWS\Minidump) folder and select the MiniMMDDYY-NN.dmp (where MMDDYY indicates the date and NN indicates the number) file you wish to examine.
  3. If asked to "Save information for workspace?", you can answer No.
  4. A Command - Dump window will appear and debugging will proceed. Allow a minute or so for the process to complete.

As a practical example, I recently used WinDbg to troubleshoot a video driver problem. I had reloaded Windows XP from scratch on an HP Pavilion zv5000 for a client. This system has an ATI Mobility Radeon 9600 graphics adapter. Since the latest graphics driver offered by HP was 8.003.3c dated 07/2005, I downloaded and installed the latest version (8.12 at the time of the install) direct from ATI instead. With the latest drivers installed, I fully tested the system and everything was working great, including StandBy and Hibernation.

I then ran Windows Update and saw that Microsoft was offering an ATI video driver as a hardware driver update. Being an experienced installer I knew that this update should be ignored (as should *most* hardware driver updates offered for laptops via Windows Update), but I decided to install it anyway just to see if I could prove that point. With the "updated" driver installed, I restarted the system, and all seemed well until I tried to put the system into either StandBy or Hibernation, where upon the system immediately crashed. In this case there was no BSOD (the system simply locked up), but after restarting I checked and saw that a minidump file had been created none the less. I ran WinDbg.exe, examined the minidump file, and the last few lines in the Command - Dump window looked like this:

    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 10000050, {80000008, 0, bfa8d719, 0}

    Unable to load image ati3duag.dll, Win32 error 0n2
    *** WARNING: Unable to verify timestamp for ati3duag.dll
    *** ERROR: Module load completed but symbols could not be loaded for ati3duag.dll
    *** WARNING: Unable to verify timestamp for ati2dvag.dll
    *** ERROR: Module load completed but symbols could not be loaded for ati2dvag.dll
    Probably caused by : ati3duag.dll ( ati3duag+58719 )

I highlighted the important lines in RED. Note the "Probably caused by :" information, which usually points to the suspect driver or application, which in this case is one of the files in the ATI video driver package. Note also the "BugCheck" code, which ends in 0x50, also known as a Stop Error 0x50 or 0x00000050. Clicking on the "!analyze -v" hyperlink displays more detailed information, which may be helpful in further isolating the cause. In this example, the additional information displayed after clicking that link included the following:

    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************

    PAGE_FAULT_IN_NONPAGED_AREA (50)
    Invalid system memory was referenced. This cannot be protected by try-except,
    it must be protected by a Probe. Typically the address is just plain bad or it
    is pointing at freed memory.

This indicates that a Stop Error 50 is also known as a PAGE_FAULT_IN_NONPAGED_AREA, which means the program referenced invalid memory. The additional information also included a stack dump, which had the following information:

    STACK_TEXT:
    WARNING: Stack unwind information not available. Following frames may be wrong.
    f783c328 bf9f57fb e1539080 00000010 00000001 ati3duag+0x58719
    f783c34c bf9f59cb e1539080 00000000 00000000 ati2dvag+0x207fb
    f783c36c bf9f5a1d e1539080 00000000 bf960d35 ati2dvag+0x209cb
    f783c3b4 bf93ea83 e1539080 00000000 00000000 ati2dvag+0x20a1d
    f783c3e0 bf93eb9b e1538008 00000000 00000000 win32k!DrvDisableDisplay+0xcf
    f783c404 bf91189c e1538008 00000001 bf8bfc50 win32k!DrvDisableMDEV+0x97
    f783c410 bf8bfc50 82a1c438 82a1c430 80507252 win32k!SafeDisableMDEV+0x18
    f783c53c bf8bf9d6 82a1c438 82a1c430 f783c56c win32k!xxxUserPowerEventCalloutWorker+0x1b7
    f783c558 bf8bfb55 00000004 00000000 81e8056c win32k!xxxUserPowerCalloutWorker+0x34
    f783c57c 8052b2cb f783c5a4 81e80420 81e80420 win32k!QueuePowerRequest+0xd4
    f783c5ac 80670693 00000008 00000004 00000000 nt!PopEventCalloutDispatch+0xc3
    f783c5d4 8066f523 00000000 f783c6d0 00000002 nt!PopSetDevicesSystemState+0x16d
    f783c6a8 f76d30e4 00000002 00000004 00000001 nt!NtSetSystemPowerState+0x42f
    f783c740 8066f14c 00000002 00000004 00000001 nt!ZwSetSystemPowerState+0x11
    f783c81c f76d30e4 00000002 00000004 00000001 nt!NtSetSystemPowerState+0x65
    f783c848 badb0d00 0006f168 00000000 00000005 0x7c90e4f4
    f783c84c 0006f168 00000000 00000005 00000045 0xbadb0d00
    f783c850 00000000 00000005 00000045 00000000 0x6f168

Note that the driver file previously referenced is included at the end of the stack trace (they are read from the bottom up), and that many of the lines reference power state settings (the crash occurred when going into StandBy). Of course I already *knew* that the ATI driver supplied by Microsoft was causing the problem, but the information gleaned from the memory dump file analysis was helpful in confirming that fact.

In this particular case the repair for this self-induced "problem" was simple. I merely used the Device Manager to "Roll Back" the display adapter driver, which reinstalled the correctly functioning driver I had originally installed.

Note that memory dump file analysis are not always so direct. Stop errors can be caused by hardware errors such as memory problems, malware, or even improper hardware or software configuration. As such, the "Probably caused by :" reference may be misleading or entirely incorrect. For general troubleshooting of Windows bug check (stop error) codes, I recommend you follow these suggestions:

  • If any hardware was recently installed in the system, try removing it.
  • If any software was recently installed, try uninstalling it.
  • If any drivers, updates or hotfixes were recently installed, try rolling back, removing or updating them.
  • Insure that the system is free from malware such as viruses, rootkits, and spyware/adware.
  • Check with the motherboard manufacturer to see if an updated BIOS is available.
  • Make sure that the processor, expansion cards, memory modules, etc. are fully seated.
  • Make sure that all cables are fully connected.
  • Make sure that the system has the latest Service Pack and critical updates installed.
  • Check the System Log and Application Log in the Event Viewer to see if any additional error messages have been logged recently.

For another excellent example of using a memory dump file analysis to troubleshoot a problem, see The Case of the Crashed Phone Call on Mark Russinovich's technical blog.

Scott.


Top 
 Profile  
Reply with quote  
 Post subject: Re: Troubleshooting Windows crashes (BSOD/Stop errors)
 Post Posted: Thu Jan 27, 2011 8:11 pm 
Offline
Site Admin

Joined: Sun Feb 04, 2007 11:44 am
Posts: 5855
Another tool that is useful for examining minidump files is the BlueScreenView utility by Nirsoft. This is one of the many programs I install by default on all of the systems I build and/or reload. Scott.


Top 
 Profile  
Reply with quote  
 Post subject: Re: Troubleshooting Windows crashes (BSOD/Stop errors)
 Post Posted: Thu Jan 27, 2011 9:40 pm 
Offline

Joined: Thu Jan 15, 2009 1:27 pm
Posts: 1105
Location: Stowmarket, Suffolk England
Thanks Scott, great utility's there! :)

I see that in (I assume NT6) you can cause a BSOD from the keyboard driver using "Right Ctrl-Scroll Lock, Scroll Lock"

Is it possible to cause a BSOD in Windows XP without ahem removing cards, memory, processors, Static or EMP's?


Top 
 Profile  
Reply with quote  
 Post subject: Re: Troubleshooting Windows crashes (BSOD/Stop errors)
 Post Posted: Fri Jan 28, 2011 2:45 am 
Offline
Site Admin

Joined: Sun Feb 04, 2007 11:44 am
Posts: 5855
The CrashOnCtrlScroll feature is available in Windows 2000 and later when using a PS/2 keyboard, and in Windows 2003 and later when using a USB keyboard. Scott.


Top 
 Profile  
Reply with quote  
 Post subject: Re: Troubleshooting Windows crashes (BSOD/Stop errors)
 Post Posted: Fri Jan 28, 2011 11:54 pm 
Offline

Joined: Thu Jan 15, 2009 1:27 pm
Posts: 1105
Location: Stowmarket, Suffolk England
Thank you Scott :)


Top 
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
 
Post new topic Reply to topic  [ 5 posts ] 

Board index » Upgrading and Repairing Forum » Scott's Tips


Who is online

Users browsing this forum: No registered users and 3 guests

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: