Windows Live Alerts
Start access
Support Forum
Remote Desktop Services
Terminal Services
Web Interface
Tips & Tools
Lassen Sie sich von einem Experten Beraten

Windows crash debugging Print E-mail

I have collected most of the following information from the Internet and brought it together in this very short description.

An extended version for crash debugging can be downloaded as PDF file. This Document is just an extended collection of crash debugging information that I found on the Internet.

Image Introduction to Debugging

Basic crash dump analysis is actually pretty straightforward. Many systems administrators ignore Windows crash dump options but isn’t it worth spending a few minutes even if only 1 out of 10 dumps tells you what’s wrong? Let's have a quick look at the basics.

Kernel Mode & User Mode

On Windows NT and above the memory is divided into two parts, the user mode and the kernel mode. What differentiates user mode from kernel mode is the privilege level. The primary memory restriction placed on user-mode programs is that they cannot access any of the kernel-mode memory.

Although a user-mode program can try to directly communicate with a hardware device, the system prevents it from doing so. You probably have seen the result of such an attempt, the point where Dr. Watson pops up.

A kernel-mode component must determine whether an exception is the result of a legal or an illegal operation; when a kernel-mode component catches an illegal exception, it notifies the Dr. Watson user-mode application.

Using Dr. Watson
When a user-mode fault has occurred, start Dr. Watson [ start | run | drwtsn32 ] and click on the last entry in the Application Errors list and then click on the View button. The portion of the Dr. Watson Log file containing the details of the fault will be displayed.

kernel-mode device drivers and subsystems can almost do anything they want. This lack of protection also emphasize the need to take care when loading a third-party device driver, because once in kernel mode the software has complete access to all OS data.

Now at this point you can see why it’s so critical when you are installing 3rd. party printer driver on a Windows Server with Terminal Services enabled.

Stop Errors – BSOD (blue screen of death)

Bugs in code can cause fatal errors, but so can some server hardware failures, especially RAM problems. Many problems will not result in Blue Screens: service or driver failures will usually generate messages logged in the System Event Log, and application exceptions are more likely to be recorded as "Dr. Watson" errors.
When a mission critical operating system fails, though, the OS elects to generate an obvious error message, such as the blue screen, rather than to simply fail in an “invisible” manner and possibly damage data. In other words, the BSOD itself is not a cause of system problems, but an indicator that serious problems need to be addressed.

Memory Dump Files

When Stop errors occur, the system automatically dumps the contents of its RAM to the paging file, and then writes the pagefile contents to the systemdrive root by default. Analyzing the dump file can help provide more information about the root cause of a problem.

Reading the Stop Screen

A Blue Screen contains an intimidating collection of data, but the key information is the error code and parameters, and list of modules that have been successfully loaded and initialized. After the word STOP the error or BugCheck code is displayed, this is the most important part of the Stop screen. You can find the explanation for many Common Stop Messages on Microsoft’s website.

Process attempted to access a portion of memory at IRQL that was too high.
Process tried to execute an illegal or unknown processor instruction.
Occurs when requested data is not found in memory.

If an event is written to the system log, it should contain the same key BugCheck code and parameters from the Stop screen. The description and format of the event log differs from the format displayed when the computer is writing the Memory.dmp file, but the majority of the information is the same.

System debugging

If the data which can be gleaned from the Blue Screen is not sufficient to identify the source of a fatal error, one way to learn more — a lot more — is to run a debugging tool like WinDBG. A debugger digs for errors by inserting itself into the system’s operation, and letting a troubleshooter go through programs step by step, examining data and system conditions along the way.

WinDBG is a popular GUI lightweight debugger. It can be used to debug Win32 applications on Windows . It can perform source-level debugging, can read dump files, and has excellent support for symbols. Because it is a GUI debugger it is a bit slower than other debugger.

WinDBG Symbols Configuration

  1. To change the symbols path: on the View menu, click Options. In the Windows Debugger Options dialog box, click the Symbols tab, specify the path to the symbols file in the Debug Symbol Search Path text box.
  2. For example, to download symbols to c:\websymbols, you would add the following to your symbol path:
  3. Click OK.

WinDBG & Crash Dumps

  1. Start WinDBG 
  2. On the Debug menu File, click Open Crash Dump, select the .dmp (Memory.dmp, user.dmp etc.) file, and then click open.
  3. In the command window, type !analyze –v 
  4. This performs a analysis with fully verbose display of data and is useful to get more information.
  5. To quit, type q in the command window. 

Image Knowledgebase articles on debugging

  • How to debug Windows services
  • Extracting the Computer Name From a Dump
  • Troubleshooting of Heap Corruption in Applications
  • How to Set NTSD as a Default Windows Postmortem Debugger
  • How to Attach WinDbg to a Process
  • How to Check In a User Dump That Full Page Heap Was Enabled
  • How to Enable User Mode Stack Trace Database for IMA Service to Detect Memory Leaks
  • Using LiveKD to Save a Complete Memory Dump
Image WebLinks

find or follow me @