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:
- Modify boot.ini to be editable
attrib c:\boot.ini -r -s - 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 - Save the file
- 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.
