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

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.

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.

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.