Some of the main topics in this chapter are
The Windows NT boot process is one of the most crucial processes that your system undergoes. If a problem occurs during booting, your system can be left in an unusable state, which can be disastrous if this happens to a mission critical file server. This chapter discusses the Windows NT boot process, as well as some common boot problems. To troubleshoot the boot process, you must have a thorough understanding of what takes place during each step of the boot process.
A successful startup of Windows NT involves many steps, including the following:
2. Hard drive boot sequence
3. Windows NT boot loader process
4. Selection of the operating system
5. Hardware detection
6. Kernel loading
7. Kernel initialization
Although the boot process on Intel x86-based systems differs from the boot process on RISC-based systems, they share some similarities. Because of hardware dissimilarities, the initial boot loader phases differ between x86 and RISC platforms. After the initial boot loader phase, much of the boot process is the same between the different platforms. Figure 9.1 shows a graphical representation of the boot process and illustrates the differences between the Intel boot process and the RISC boot process.
The boot process on RISC-based systems differs from that on Intel x86-based systems.
The start of the Intel x86 boot process consists of the following steps:
2. Loading the Master Boot Record
3. Executing the Partition Boot Record
4. Executing NTLDR
5. Executing NTDETECT
The following sections discuss each of these events in greater detail.
When the system is first powered on, all system components must be tested and initialized before the boot process can take place. This Power-On Self Test is referred to by the acronym POST.
In the first step of POST, the CPU is set to real mode and the code at location F000:0000h is executed. This code checks the amount of memory installed and verifies that all required hardware is installed and functioning properly. Next, any ROMs located on adapter cards, such as a SCSI adapter, are executed. After all hardware has been initialized, BIOS INT 19h is invoked. This is the interrupt that calls the bootstrap loader.
INT 19h first checks if a disk is in the floppy drive. If so, the system tries to boot from a floppy disk. If no floppy is present, the Master Boot Record (MBR) of the hard disk is read and loaded into memory.
The Master Boot Record (MBR) is the first sector on the hard drive. It is always located on track 0, head 0, sector 1. The MBR contains a small amount of executable code, as well as the partition table for the disk. The MBR is created when the first partition on the hard drive is created. The purpose of the MBR is to determine where the active system partition is located and to transfer control to the boot loader of that partition.
After the MBR is loaded into memory by POST, the code is executed. This code searches the hard drive partition table to locate the active system partition. After the active system partition is located, the MBR loads and executes the code located in sector 0 of this partition. This sector is referred to as the partition boot record.
The Partition Boot Record contains the first Windows NT-specific code thus far and is always located on the same physical disk as the MBR. The length of the partition boot record varies depending on the type of file system on the partition. For FAT volumes, the boot record is only one sector long. On NTFS volumes, the boot record is 16 sectors long. The extra sectors are needed for NTFS volumes because of the extra code required to be able to recognize the NTFS file system.
The Partition Boot Record is responsible for two functions. First, the code located in the Partition Boot Record must be able to recognize enough of the file system to be able to find NTLDR. Second, NTLDR must be loaded into memory and executed.
The Windows NT boot loader, NTLDR, enables the user to select the preferred operating system and then initiates the booting of that operating system. NTLDR gets its name from condensing "NT loader." The execution of NTLDR can be recognized by the clearing of the screen and the following message being displayed:
OS Loader V4.0
The following files are required by NTLDR:
When NTLDR first starts, it switches the processor from real mode to 32-bit flat memory mode. This must be done because Windows NT is a 32-bit operating system. Next, before the load process can continue, the appropriate mini-file system must be started. The code for the FAT and NTFS mini-file system is contained within NTLDR. This mini-file system is required for reading, writing, and changing directories on the system boot drive. Next, the BOOT.INI file is read, and then the boot loader screen is displayed. You're then prompted to pick the operating system you want to boot.
If an operating system other than Windows NT is selected, NTLDR loads BOOTSECT.DOS and passes control to it. Otherwise, NTDETECT.COM is loaded and executed.
The execution of NTDETECT.COM can be recognized by the following displayed message:
NTDETECT V4.0 Checking Hardware . . .
NTDETECT is responsible for collecting a list of currently installed components and passing the information back to NTLDR. NTDETECT detects the following devices:
NOTE: If NTDETECT does not detect any required hardware, it won't report any problems here.
After NTDETECT has completed, the screen clears and the following message appears:
OS Loader V4.0 Press spacebar now to invoke Hardware Profile/Last Known Good menu.
The process that occurs after the executing of NTDETECT.COM depends on whether Windows NT has been configured with another Hardware Profile or if the user has pressed the spacebar to load the Last Known Good configuration. If either of these conditions is met, NTLDR displays the Hardware Profile/Configuration Recovery Menu. Otherwise, NTLDR proceeds to load by using the default configuration.
NOTE: If you need to boot Windows NT by using different hardware configurations, then you should create a Hardware Profile for each configuration. A perfect example of this would be for a laptop. One Hardware Profile could be used to boot without a docking station and another for booting with support for the additional docking station hardware.
The Hardware Profile/Configuration Recovery Menu enables you to select the Hardware Profile you want to use or to boot with The Last Known Good Control Set. The Last Known Good Control Set is a saved version of the configuration information used during the last successful boot of Windows NT. Regardless of the choice you make, NTLDR then proceeds to the kernel load phase of the boot process.
Windows NT systems based on Alpha processors follow a slightly different boot process. This RISC boot process consists of the following steps:
2. Execution of OSLOADER
3. Selection of the operating system
4. Loading of the kernel
5. Initialization of the kernel
Because systems based on these processors can vary, the following sections provide a brief overview of how the boot process takes place.
The POST routine on a RISC-based boot process performs much of the same tasks as the POST for x86 systems. The amount of memory is checked, as well as whether or not the needed hardware components are present. After POST is complete, the resident ROM firmware reads the boot precedence table from non-volatile RAM (NVRAM) and then loads and executes OSLOADER.
The RISC-based version of NTLDR is OSLOADER. OSLOADER also performs the functions of NTDETECT.COM and BOOTSECT.DOS. The RISC-based equivalent to the BOOT.INI is the environment variables contained within Non Volatile Random Access Memory (NVRAM).
OSLOADER prompts the user to select an operating system. The following is an example of what might appear on the screen of an Alpha-based computer:
RC Multiboot Alpha AXP Version 3.5-11
Copyright (c) 1993 Microsoft Corporation
Copyright (c) 1993 Digital Equipment Corporation
Boot Menu:
Boot Windows NT Server Version 4.0
Boot an alternate operating system
Run a program
Supplementary menu
Use the arrow keys to select, then press Enter.
Seconds until auto-boot. Select another option to override: 9
After selecting to boot Windows NT, OSLOADER proceeds with the kernel load phase of the boot process.
Operating systems contain a core set of software instructions on which the higher-level functions are based. This core set of code is referred to as the system kernel. The kernel load processes that follow occur on both Intel and RISC-based systems. The first step is the loading, but not initialization, of the kernel (NTOSKRNL.EXE) and the Hardware Abstraction Layer (HAL.DLL). You will see several dots appear at the top of the screen during this process. The hardware information obtained by NTDETECT.COM is passed to NTOSKRNL.EXE. In the case of RISC-based systems, this hardware information is read from NVRAM.
A copy of the system hive, HKEY_LOCAL_MACHINE\SYSTEM, is then loaded into memory. The control set is then loaded from ControlSet00x, where x is the value of either "Default" or "LastKnownGood" in the HKEY_LOCAL_MACHINE\SYSTEM\Select subkey.
If you select any load option other than the Last Known Good Configuration, then the boot loader loads the control set specified by the value of "Default" in the HKEY_LOCAL_MACHINE\SYSTEM\Select subkey. If you select the Last Known Good configuration, the control set specified by the value "LastKnownGood" in HKEY_LOCAL_MACHINE\SYSTEM\Select is loaded. The value "Current" in the Select subkey is then set to the number of the control set loaded.
Next, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services is scanned for drivers that contain a start value of 0. This value, which is normally assigned to low-level hardware device drivers, indicates that the driver should be loaded but not initialized before the kernel. The order in which these drivers are loaded is determined by the drivers Group value. The List value in subkey HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\ServiceGroupOrder contains the order in which these groups will be loaded. The drivers loaded during this phase are loaded by using BIOS INT 13h calls or by the NTBOOTDD.SYS driver. In the case of RISC-based systems, these drivers are loaded by using firmware calls.
After these drivers have been loaded into memory, the boot loader then initializes NTOSKRNL.EXE and passes control to it.
The kernel initialization phase is easily recognized because the screen turns blue and a message similar to the following appears:
Microsoft (R) Windows NT (TM) Version 4.0 (Build 1345) 1 System Processor (32 MB Memory)
After NTOSKRNL.EXE has successfully initialized and has control, it creates the HKEY_LOCAL_MACHINE\HARDWARE key from the information that was passed to it by the boot loader. All the information in this key is created fresh at each system startup.
The HKEY_LOCAL_MACHINE\SYSTEM\Clone control set is then created by the kernel by making a copy of the control set that is pointed to by the value of Current in the HKEY_LOCAL_MACHINE\SYSTEM\Select subkey. The Clone control set is intended to be a copy of the data used to configured the computer and therefore is never modified.
The low-level device drivers that were loaded in the kernel load phase are now initialized, and the Registry is once again searched for device drivers. This time, drivers with a start value of 1 are loaded and initialized. Again, the load order is determined by the Group value of the driver. The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder subkey contains the load order of each group. The drivers loaded during this phase are not loaded by using BIOS or firmware calls like they were in the kernel load phase. Instead, they're loaded by using the device drivers that were previously initialized.
After the device drivers are initialized, the Session Manager (SMSS.EXE) is started. The Session Manager is responsible for starting loading and starting the services, as well as the higher-level subsystems. The Session Manager handles tasks, as defined under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager. Some of the tasks and registry entries for the Session Manager are listed in the following:
The following sections discuss these in more detail.
The BootExecute data item contains a list of commands that Session Manager runs before it loads any services. By default, the only program that is executed is AUTOCHK.EXE. If a Windows NT system was not shut down properly, on the next boot, AUTOCHK.EXE scans the partitions for any problems and attempt to correct them.
The Memory Management Registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Session Manager\Memory Management) contains the information required for the Session Manager to set up the page files required by the Virtual Memory Manager. The Virtual Memory Manager function manages the memory subsystem so that each application can be allocated a non-conflicting block of memory. The following are some sample item settings used by Session Manager:
This specifies the size of the nonpaged pool of memory in bytes. The value 0 specifies to use the default size based on physical memory. The maximum for this value is 80 percent of physical memory.
This specifies the size of the paged pool of memory in bytes. The value 0 specifies to use the default of 32 MB.
This specifies the location and size of each page file. This can contain multiple values.
The DOS Devices key contains a list of devices for which Session Manager creates symbolic links. These links are used to direct certain classes of commands to the correct component in the file system.
MAILSLOT : REG_SZ : \Device\MailSlot
NUL : REG_SZ : \Device\Null
PIPE : REG_SZ : \Device\NamedPipe
PRN : REG_SZ : \DosDevices\LPT1
UNC : REG_SZ : \Device\Mup
Next, the subsystems listed under the Required item of HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems are started. The subsystem listed is CSRSS.EXE, which is the Windows subsystem. This subsystem controls all I/O and video access.
The Windows subsystem starts several other subsystems, such as WINLOGON.EXE. WinLogon is the subsystem that controls the local logon process. WinLogon then starts LSASS.EXE, the Local Security Authority (LSA). The LSA handles all user mode security validations and it must function in order to use the system. At this point, the logon dialog box appears. The logon dialog box is the first line of security--at this point, the user must supply a valid account and password in order to enter the system.
Even though you're prompted with the capability to log on, the system is still in the boot process. The Service Controller, SCREG.EXE, is the next process to be executed. The Service Controller searches the Registry for all services that have a start value of 0x2. The order in which these services are started is controlled by each service's value contained in DependOnGroup and DependOnService. If a service has a DependOn value set, the service is not started until the Group or Service listed has been successfully started.
The final step of the boot process occurs as soon as a user successfully logs on. The Clone control set is then copied to the LastKnownGood control set.
Now that the Windows NT boot process has been examined, troubleshooting boot problems should be much easier. The following sections take a look at some common problems that can occur as well as how to correct these problems.
If the POST routine is unable to locate or recognize the primary hard drive, you might receive the following message:
Non-System disk or disk error Replace and press any key when ready
An incorrect setting in CMOS is a common cause of this problem. If the system's battery becomes low, CMOS might loose setup information. Check your computer's CMOS setup and verify that the correct parameters are set for the hard drive that it installed. If you have an IDE hard drive installed, the CMOS must be set to reflect the correct drive parameters. If you're booting from a hard drive that's connected to an adapter with an on-board BIOS, such as a SCSI adapter, the hard drive type in CMOS is generally set to Not Installed.
The preceding message might also be caused by the following:
You should verify that none of the preceding items are the problem. If you suspect one to be the cause, correct the problem and try to boot the system again.
The MBR is responsible for the following functions:
If the MBR cannot accomplish any of these, an error message appears. But what happens if no error message appears? If the system hangs after POST and does not display an error message, the MBR might be corrupt. To replace the MBR, boot the system from the floppy drive by using DOS 5.0 or greater. Then, issue the following command at the a:\ prompt:
fdisk /mbr
This rewrites the MBR but does not rewrite the partition table. The partition table contains the information for all the partitions located on the hard drive. The following error message indicates that the partition table is corrupt:
Invalid Partition Table
This is a very serious problem! If you have not saved a copy of the MBR (see the later section "Pre-Failure Precautions"), the only way to correct this problem is by using a low-level disk editor and manually re-creating the partition table. Recreating the partition table is a very complex task and beyond the scope of this chapter. If you must undertake this task, check the Windows NT Resource Guide, which goes into great detail on the partition table.
If the MBR cannot locate the active boot partition, you might receive an error such as the following:
NO ROM BASIC SYSTEM HALTED
This error typically is remedied by using FDISK to set the active partition. If the Partition Boot Record needs to be repaired, you can use the Emergency Repair Disk. Initiate Emergency Repair Disk by starting the Windows NT Setup and then selecting Repair when prompted. Only the Inspect boot sector option should be selected.
This process replaces the partition boot sector if it detects that the code in that sector no longer references NTLDR.
Because NTLDR performs many functions, the opportunity arises for many problems to occur. Some common errors and techniques to correct them are examined here. One potential problem is that NTLDR is missing from the active partition. If the active partition is FAT, you might receive the following error:
Couldn't find NTLDR.
Or, if the active partition is NTFS, you might receive the following error:
A kernel file is missing from the disk.
If either of these messages appears, the NTLDR file is missing from the active partition. If you suspect that some of the boot loader files might be missing or corrupt, you can replace them by running the repair process, as previously described. To have Windows NT Setup only check the boot loader files, check the Inspect startup environment option. This checks NTLDR, NTDETECT.COM, and BOOT.INI and repairs any files as necessary.
One useful troubleshooting tool in NTLDR is the capability to display information on the kernel and driver names while they are being loaded. This tool is useful if you suspect that a driver is missing or corrupt. To activate this feature, place the /sos switch on the Windows NT entry in BOOT.INI. Here's an example entry:
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server 4.00" /sos
After activating this option, and after NTDETECT has completed, you see output similar to the following:
multi(0)disk(0)rdisk(0)partition(1)\winnt\System32\ntoskrnl.exe multi(0)disk(0)rdisk(0)partition(1)\winnt\System32\hal.dll multi(0)disk(0)rdisk(0)partition(1)\winnt\system32\config\system multi(0)disk(0)rdisk(0)partition(1)\winnt\system32\c_1252.nls multi(0)disk(0)rdisk(0)partition(1)\winnt\system32\c_437.nls multi(0)disk(0)rdisk(0)partition(1)\winnt\system32\l_intl.nls multi(0)disk(0)rdisk(0)partition(1)\winnt\FONTS\vgaoem.fon multi(0)disk(0)rdisk(0)partition(1)\winnt\System32\Drivers\atapi.sys multi(0)disk(0)rdisk(0)partition(1)\winnt\System32\Disk.sys multi(0)disk(0)rdisk(0)partition(1)\winnt\System32\CLASS2.SYS multi(0)disk(0)rdisk(0)partition(1)\winnt\System32\Ntfs.sys
This output lets you know exactly what drivers are loading and in what order. If the boot process fails during this part of the load process, the output can help identify which driver might be causing the problem.
Another feature of NTLDR is the Last Known Good configuration. This option is very useful if a new driver is installed that causes the system to stop booting. Activating this option starts Windows NT by using the last configuration that was known to have loaded successfully. To boot by using this feature, press the spacebar after the following message is displayed:
Press spacebar now to invoke Hardware Profile/Last Known Good menu.
This message appears right after NTDETECT completes. You only have this option for a few seconds, so make sure you pay close attention. After pressing the spacebar, the Hardware Profile/Last Known Good menu appears. To boot by using the Last Known Good option, press L.
You can take several steps to ensure that you can repair any boot problems. Make sure that you have a current Emergency Repair Disk. This can be created by using the rdisk (Repair Disk) command. Figure 9.2 shows the rdisk utility.
Use the rdisk utility to update the repair information and create an emergency repair disk.
You can create an emergency repair disk by using the following steps:
2. Type rdisk at the prompt, and press Enter.
3. Click Update Repair Info.
4. Select Yes twice.
5. Insert a disk, and click OK.
You should update the repair information and create an emergency repair disk after any system changes are made. Examples of system changes are:
Another useful tool is DiskSave, which is located on the Windows NT Resource CD. By using DiskSave, the MBR and the partition boot sector can be saved or restored. This utility backs up and restores not only the MBR code but also the partition table. If you want to keep all your recovery information in one place, save the MBR and Partition Boot Record on the emergency repair disk.
© Copyright, Macmillan Computer Publishing. All rights reserved.