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

  • Logon Process
  • Security Subsystem
  • Win32 Application and Subsystem
  • OS/2 Application and Subsystem
  • POSIX Application and Subsystem

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

  • Various managers, handling IO, objects, security, IPC (inter process communication), graphics, window and virtual memory
  • Microkernel that provides the basic Operating System functionality
  • Hardware Abstraction Layer
  • Device Drivers

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

Dll Base DateStmp - Name Dll Base DateStmp - Name
80100000 2cd348a4 - ntoskrnl.exe 80400000 2cd348b2 - hal.dll
80010000 2cd348b5 - ncrc810.sys 80013000 2cda574d - SCSIPORT.SYS

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:

  1. Modify boot.ini to be editable
    attrib c:\boot.ini -r -s
  2. Edit the file and edit the Windows NT start line to include /debug (to tell the system to load the kernel debugger into memory at bootup) or /crashdebug (to tell the system to load the kernel debugger but swap it out to the pagefile). Other options are /Debugport to tell which COM port to use (by default COM2) and /Baudrate for the speed (by default 19200, better to be 9600), e.g.
    \[operating systems\]
    multi(0)disk(0)rdisk(0)partition(0)\WINDOWS="Windows NT" /debug /debugport=com3 /baudrate=9600
  3. Save the file
  4. Set boot.ini attributes back
    attrib c:\boot.ini +r +s

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.

0xC000009A STATUS_INSUFFICIENT_RESOURCES, caused by lack of non-paged pool.
0xC000009C STATUS_DEVICE_DATA_ERROR, generally due to bad block on the drive.
0xC000009D STATUS_DEVICE_NOT_CONNECTED, bad or loose cabling, termination, or controller not seeing drive.
0xC000016A STATUS_DISK_OPERATION_FAILED, also caused by bad block on the drive.
0xC0000185 STATUS_IO_DEVICE_ERROR, caused by improper termination or bad cabling on SCSI devices.

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.