What information is shown in the Blue Screen of Death (BSOD) ?

A. The NT operating system has 2 basic layers, the user mode and kernel mode. The user mode cannot directly access hardware, is limited to an assigned address space and operates at Ring 3 (lower priority). If a user mode program has an error, then NT just halts the programs process and generates an Operation error, and as the application runs in its own virtual address it cannot affect any other program. Common components that run in user mode are

NT 4.0 introduced a change in the NT architecture as Kernel mode process run much faster (Ring 0) they moved Video and Printer drivers from User mode to Kernel mode. Kernel mode is a privileged processor mode, allowing direct access to the memory and hardware. Kernel mode errors are not usually recoverable and a reboot of the system will be required. The BSOD is a built in error trapping mechanism which is used to halt any further processing to avoid system/data corruption. This means a faulty graphics/print driver could now crash NT. Components in kernel mode are

But what does the BSOD (or STOP message screen) show? Below is the basic structure of the BSOD, however what you see will differ and you may not have some of the sections as I'll explain below

--------------------------------------------------
Section 1: Debug Port Status Indicators
DSR CTS SND
--------------------------------------------------
Section 2: BugCheck Information
*** STOP: 0x0000000A (0x00000002,0x00000000,0xDB30442D)
IRQL_NOT_LESS_OR_EQUAL *** Address db30442d has base at db300000 - matrxmil.SYS

CPUID: GenuineIntel 5.2.4 irql:1f SYSVER 0xF0000565
--------------------------------------------------
Section 3: Driver Information

etc..
--------------------------------------------------
Section 4: Kernel Build and Stack Dump
Address dword dump Build [1381] -Name
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx - matrxmil.SYS
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx - ntoskrnl.exe
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx - ntoskrnl.exe
etc..
--------------------------------------------------
Section 5: Debug Port Information
Restart and set the recovery options in the system control panel
or the /CRASHDEBUG system start option if this message reappears,
contact your system administrator or technical support group

OR if you system is started with /debug or /crashdebug

Kernel Debugger Using : Com2 (Port 0x2f8, Baud Rate 9600)
Beginning Dump of physical memory
Physical memory dump complete. Contact your system administrator or
technical support group

Section 1: This section will only be shown if the system was start /debug or /crashdebug. To tell if your system is debugger enabled, just look at the boot menu when you start the machine and the words [debugger enabled] will be shown next to the Windows NT menu choice. To enable /debug follow the instructions below:

The 3 letter words are signals, e.g. RTS is Ready to Send, DSR Data Send Ready, CTS Clear to Send, and SND means data is being sent to the COM port

Section 2: This sections contains the error (or BugCheck) code with up to four developer-defined parameters (defined in the KeBugCheckEx() function call). In this case the BugCheck was 0x0000000A IRQL_NOT_LESS_OR_EQUAL which means a process attempted to access pageable memory at a process level that was to high and is usually caused by a device driver.

For example, a BugCheck of 0x00000077 or 0x0000007A mean the pagefile could not be loaded into memory. The second hexadecimal value will help you diagnose the cause, e.g.

For a full list of what the codes mean see knowledge base article Q103059 at http://support.microsoft.com/support/kb/articles/q103/0/59.asp .

Section 3: This lists out all drivers that were loaded at the time of the crash. It is split into 2 sides, with 3 columns to each site. The first column is the link time stamp (in seconds since the year 1970) and can be converted into real time using the cvtime.exe application (f$cvtime on VMS :-) ).

Section 4: This shows the build number of the Operating System and a stack dump that shows the addresses that were used by the failed module. The top lines may show the offending code/driver, however not always as kernel trap handlers may execute last to preserve error information.

Section 5: This will depend on if you have the /debug setup, but it basically just shows the communication settings and if a .dmp file has been created.