| The term boot comes from the word bootstrap and describes the method by which the PC becomes operational. Just as you pull on a large boot by the small strap attached to the back, a PC loads a large operating system by first loading a small program that can then pull the operating system into memory. The chain of events begins with the application of power and finally results in a fully functional computer system with software loaded and running. Each event is triggered by the event before it and initiates the event after it. Tracing the system boot process might help you find the location of a problem if you examine the error messages the system displays when the problem occurs. If you see an error message that is displayed by only a particular program, you can be sure the program in question was at least loaded and partially running. Combine this information with the knowledge of the boot sequence, and you can at least tell how far the system's startup procedure had progressed before the problem occurred. You usually should look at whichever files or disk areas were being accessed during the failure in the boot process. Error messages displayed during the boot process and those displayed during normal system operation can be hard to decipher. However, the first step in decoding an error message is knowing where the message came fromwhich program actually generated or displayed it. The following programs are capable of displaying error messages during the boot process: OS Independent: OS Dependent System files Device drivers (loaded through CONFIG.SYS or the Win Registry SYSTEM.DAT) Programs run by AUTOEXEC.BAT, the Windows Startup group, and the Registry
The first portion of the startup sequence is operating system independent, which means these steps are the same for all PCs no matter which operating system is installed. The latter portion of the boot sequence is operating system dependent, which means those steps can vary depending on which operating system is installed or being loaded. The following sections examine both the operating-system-independent startup sequence and the operating-system-dependent startup process for various operating systems. These sections provide a detailed account of many of the error messages that might occur during the boot process. The Boot Process: Operating System Independent If you have a problem with your system during startup and can determine where in this sequence of events your system has stalled, you know which events have occurred and probably can eliminate each of them as a cause of the problem. The following steps occur in a typical system startup regardless of which operating system you are loading: 1. | You switch on electrical power to the system.
| 2. | The power supply performs a self-test (known as the POST). When all voltages and current levels are acceptable, the supply indicates that the power is stable and sends the Power_Good signal to the motherboard. The time from switch-on to Power_Good is normally between .1 and .5 seconds.
| | | 3. | The microprocessor timer chip receives the Power_Good signal, which causes it to stop generating a reset signal to the microprocessor.
| See "The Power_Good Signal," p. 1146. |
| 4. | The microprocessor begins executing the ROM BIOS code, starting at memory address FFFF:0000. Because this location is only 16 bytes from the very end of the available ROM space, it contains a JMP (jump) instruction to the actual ROM BIOS starting address.
| See "Motherboard BIOS," p. 416. |
| 5. | The ROM BIOS performs a test of the central hardware to verify basic system functionality. Any errors that occur are indicated by audio "beep" codes because the video system has not yet been initialized. If the BIOS is Plug and Play (PnP), the following steps are executed; if not, skip to step 10.
| 6. | The Plug and Play BIOS checks nonvolatile random access memory (RAM) for input/output (I/O) port addresses, interrupt request lines (IRQs), direct memory access (DMA) channels, and other settings necessary to configure PnP devices on the computer.
| 7. | All Plug and Play devices found by the Plug and Play BIOS are disabled to eliminate potential conflicts.
| 8. | A map of used and unused resources is created.
| 9. | The Plug and Play devices are configured and reenabled, one at a time. If your computer does not have a Plug and Play BIOS, PnP devices are initialized using their default settings. These devices can be reconfigured dynamically when Windows starts. At that point, Windows queries the Plug and Play BIOS for device information and then queries each Plug and Play device for its configuration.
| 10. | The BIOS performs a video ROM scan of memory locations C000:0000C780:0000 looking for video adapter ROM BIOS programs contained on a video adapter found either on a card plugged into a slot or integrated into the motherboard. If the scan locates a video ROM BIOS, it is tested by a checksum procedure. If the video BIOS passes the checksum test, the ROM is executed; then the video ROM code initializes the video adapter and a cursor appears onscreen. If the checksum test fails, the following message appears:
C000 ROM Error
| 11. | If the BIOS finds no video adapter ROM, it uses the motherboard ROM video drivers to initialize the video display hardware, and a cursor appears onscreen.
| 12. | The motherboard ROM BIOS scans memory locations C800:0000DF80:0000 in 2KB increments for any other ROMs located on any other adapter cards (such as SCSI adapters). If any ROMs are found, they are checksum-tested and executed. These adapter ROMs can alter existing BIOS routines and establish new ones.
| 13. | Failure of a checksum test for any of these ROM modules causes this message to appear:
XXXX ROM Error
where the address XXXX indicates the segment address of the failed ROM module.
| 14. | The ROM BIOS checks the word value at memory location 0000:0472 to see whether this start is a cold start or a warm start. A word value of 1234h in this location is a flag that indicates a warm start, which causes the BIOS to skip the memory test portion of the POST. Any other word value in this location indicates a cold start, and the BIOS performs the full POST procedure. Some system BIOSs let you control various aspects of the POST procedure, making it possible to skip the memory test, for example, which can be lengthy on a system with a lot of RAM.
| 15. | If this is a cold start, the full POST executes; if this is a warm start, a mini-POST executes, minus the RAM test. Any errors found during the POST are reported by a combination of audio and displayed error messages. Successful completion of the POST is indicated by a single beep (with the exception of some Compaq computers, which beep twice).
| | | 16. | The ROM BIOS searches for a boot record at cylinder 0, head 0, sector 1 (the very first sector) on the default boot drive. At one time, the default boot drive was always the first floppy disk, or A: drive. However, the BIOSs on today's systems often enable you to select the default boot device and the order in which the BIOS will look for other devices to boot from if necessary, using a floppy disk, hard disk, or even a CD-ROM drive in any order you choose. This sector is loaded into memory at 0000:7C00 and tested.
If a disk is in the drive but the sector can't be read, or if no disk is present, the BIOS continues with step 19.
Booting from CD-ROM or Floppy If you do want to boot from a CD-ROM, be sure the CD-ROM drive is listed before the hard disk in the boot devices menu in your BIOS setup. To ensure that you can boot from an emergency CD or floppy disk, I recommend setting the CD-ROM as the first and the floppy drive as the second boot device. A hard disk containing your operating system should be the third device in the boot device list. This enables you to always be ready for an emergency. So long as you do not start up the system with a floppy or bootable CD loaded, the BIOS bypasses both the CD and floppy disk drives and boots from the hard drive. Note that not all operating system CDs are bootable. Windows 95 CDs are not bootable; however, with Windows 98/Me, Microsoft made the operating system CD bootable, but only for OEM (original equipment manufacturer) versions. This does not extend to retail versions of these Windows CDs. Windows NT 4.0 and later, including Windows 2000 and XP, are shipped on bootable CDs, including all OEM, retail, and upgrade versions. Refer to Chapter 11, "Optical Storage," for information on how to make a bootable CD. |
| 17. | If you are booting from a floppy disk and the first byte of the volume boot record is less than 06h, or if the first byte is greater than or equal to 06h and the first nine words contain the same data pattern, this error message appears and the system stops: 602-Diskette Boot Record Error
| 18. | If the volume boot record can't find or load the system files, or if a problem was encountered loading them, one of the following messages appears:
Non-System disk or disk error Replace and strike any key when ready Non-System disk or disk error Replace and press any key when ready Invalid system disk_ Replace the disk, and then press any key Disk Boot failure Disk I/O Error
All these messages originate in the volume boot record (VBR) and relate to VBR or system file problems.
| 19. | If no boot record can be read from drive A: (such as when no disk is in the drive), the BIOS then looks for a master boot record (MBR) at cylinder 0, head 0, sector 1 (the very first sector) of the first hard disk. If this sector is found, it is loaded into memory address 0000:7C00 and tested for a signature.
| | | 20. | If the last two (signature) bytes of the MBR are not equal to 55AAh, software interrupt 18h (Int 18h) is invoked on most systems. This causes the BIOS to display an error message that can vary for different BIOS manufacturers, but which is often similar to one of the following messages, depending on which BIOS you have:
IBM BIOS:
The IBM Personal Computer Basic_ Version C1.10 Copyright IBM Corp 1981 62940 Bytes free_ Ok_
Most IBM computers since 1987 display a strange character graphic depicting the front of a floppy drive, a 3 1/2" disk, and arrows prompting you to insert a disk in the drive and press the F1 key to proceed.
AMI BIOS:
NO ROM BASIC - SYSTEM HALTED
Compaq BIOS:
Non-System disk or disk error replace and strike any key when ready
AwardBIOS:
DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER
PhoenixBIOS:
No boot device available - strike F1 to retry boot, F2 for setup utility
or
No boot sector on fixed disk - strike F1 to retry boot, F2 for setup utility
Although the messages vary from BIOS to BIOS, the cause for each relates to specific bytes in the MBR, which is the first sector of a hard disk at the physical location cylinder 0, head 0, sector 1.
The problem involves a disk that either has never been partitioned or has had the Master Boot Sector corrupted. During the boot process, the BIOS checks the last two bytes in the MBR (first sector of the drive) for a signature value of 55AAh. If the last two bytes are not 55AAh, an Interrupt 18h is invoked, which calls the subroutine that displays one of the error messages just shown, which basically instructs the user to insert a bootable floppy to proceed.
The MBR (including the signature bytes) is written to the hard disk by the FDISK, Disk Management, or DISKPART programs. Immediately after a hard disk is low-level formatted, all the sectors are initialized with a pattern of bytes, and the first sector does not contain the 55AAh signature. In other words, these ROM error messages are exactly what you see if you attempt to boot from a hard disk that has been freshly low-level formatted but has not yet been partitioned or if the MBR has been corrupted such that the signature bytes were overwritten.
| 21. | The MBR searches its built-in partition table entries for a boot indicator byte marking an active partition entry.
| 22. | If none of the partitions are marked active (bootable), the BIOS invokes software interrupt 18h, which displays an error message (refer to step 20).
| 23. | If any boot indicator byte in the MBR partition table is invalid, or if more than one indicates an active partition, the following message is displayed and the system stops:
Invalid partition table
| 24. | If an active partition is found in the MBR, the partition boot record from the active partition is loaded and tested.
| | | 25. | If the partition boot record can't be read successfully from the active partition within five retries because of read errors, the following message is displayed and the system stops:
Error loading operating system
| 26. | The hard disk's partition boot record is tested for a signature. If it does not contain a valid signature of 55AAh as the last two bytes in the sector, the following message is displayed and the system stops:
Missing operating system
| 27. | The volume boot record is executed as a program. This program looks for and loads the operating system kernel or system files. If the volume boot record can't find or load the system files, or if a problem was encountered loading them, one of the following messages appears:
Non-System disk or disk error Replace and strike any key when ready Non-System disk or disk error Replace and press any key when ready Invalid system disk_ Replace the disk, and then press any key Disk Boot failure Disk I/O Error
All these messages originate in the volume boot record (VBR) and relate to VBR or system file problems.
|
From this point forward, what happens depends on which operating system you have. The operating-system-dependent boot procedures are discussed in the next several sections. The DOS Boot Process The initial system file (called IO.SYS or IBMBIO.COM) is executed. The initialization code in IO.SYS/IBMBIO.COM copies itself into the highest region of contiguous DOS memory and transfers control to the copy. The initialization code copy then relocates MSDOS.SYS over the portion of IO.SYS in low memory that contains the initialization code because the initialization code no longer needs to be in that location. The initialization code executes MSDOS.SYS (or IBMDOS.COM), which initializes the base device drivers, determines equipment status, resets the disk system, resets and initializes attached devices, and sets the system default parameters. The full DOS file system is active, and control is returned to the IO.SYS initialization code. The IO.SYS initialization code reads the CONFIG.SYS file multiple times. When loading CONFIG.SYS, the DEVICE statements are first processed in the order in which they appear. Any device driver files named in those DEVICE statements are loaded and executed. Then, any INSTALL statements are processed in the order in which they appear; the programs named are loaded and executed. The SHELL statement is processed and loads the specified command processor with the specified parameters. If the CONFIG.SYS file contains no SHELL statement, the default \COMMAND.COM processor is loaded with default parameters. Loading the command processor overwrites the initialization code in memory (because the job of the initialization code is finished). During the final reads of CONFIG.SYS, all the remaining statements are read and processed in a predetermined order. Thus, the order of appearance for statements other than DEVICE, INSTALL, and SHELL in CONFIG.SYS is of no significance. If AUTOEXEC.BAT is present, COMMAND.COM loads and runs AUTOEXEC.BAT. After the commands in AUTOEXEC.BAT have been executed, the DOS prompt appears (unless AUTOEXEC.BAT calls an application program or shell of some kind, in which case the user might operate the system without ever seeing a DOS prompt). If no AUTOEXEC.BAT file is present, COMMAND.COM executes the internal DATE and TIME commands, displays a copyright message, and displays the DOS prompt.
Some minor variations from this scenario are possible, such as those introduced by other ROM programs in the various adapters that might be plugged into an expansion slot. Also, depending on the exact ROM BIOS programs involved, some of the error messages and sequences can vary. Generally, however, a computer follows this chain of events while "coming to life." You can modify the system startup procedures by altering the CONFIG.SYS and AUTOEXEC.BAT files. These files control the configuration of DOS and allow special startup programs to be executed every time the system starts. The Windows 9x/Me Boot Process Knowing exactly how Windows 9x and Millennium Edition (Me) load and start can be helpful when troubleshooting startup problems. The Windows 9x boot process can be broken into three phases: The IO.SYS file is loaded and run. (Windows 9x's IO.SYS combines the functions of DOS's IO.SYS and MSDOS.SYS.) Real-mode configuration takes place. The WIN.COM file is loaded and run.
Phase 1Loading and Running the IO.SYS File The initialization code initializes the base device drivers, determines equipment status, resets the disk system, resets and initializes attached devices, and sets the system default parameters. The file system is activated, and control is returned to the IO.SYS initialization code. The Starting Windows message is displayed for <n> seconds, or until you press a Windows function key. The amount of time the message is displayed is determined by the BootDelay=<n> line in the MSDOS.SYS file; the default is 2 seconds. The IO.SYS initialization code reads the MSDOS.SYS configuration file. If you have multiple hardware profiles, you receive the following message and must choose a hardware configuration to use: Windows cannot determine what configuration your computer is in. The LOGO.SYS file is loaded and displays a startup image onscreen. If the DRVSPACE.INI or DBLSPACE.INI file exists, it is loaded into memory. IO.SYS also automatically loads HIMEM.SYS, IFSHLP.SYS, and SETVER.EXE. The IO.SYS file checks the system Registry files (SYSTEM.DAT and USER.DAT) for valid data. IO.SYS opens the SYSTEM.DAT file. If the SYSTEM.DAT file is not found, the SYSTEM.DA0 file is used for startup. If Windows 9x/Me starts successfully, the SYSTEM.DA0 file is copied to the SYSTEM.DAT file. The DBLBUFF.SYS file is loaded if the DoubleBuffer=1 is in the MSDOS.SYS file or if double buffering is enabled under the following Registry key: HKLM\System\CurrentControlSet\Control\WinBoot\DoubleBuffer Note Windows 9x Setup automatically enables double buffering if it detects that it is required.
If you have multiple hardware profiles, the hardware profile you chose is loaded from the Registry. In Windows 9x/Me, the system looks in the Registry's Hkey_Local_Machine\System\CurrentControlSet key to load the device drivers and other parameters specified there before executing the CONFIG.SYS file.
Phase 2Real-Mode Configuration Some older hardware devices and programs require that drivers or files be loaded in real mode (16-bit mode) for them to work properly. To ensure backward compatibility, Windows 9x processes the CONFIG.SYS and AUTOEXEC.BAT files if they exist: The CONFIG.SYS file is read if it exists, and the statements within are processed, including the loading of drivers into memory. If the CONFIG.SYS file does not exist, the IO.SYS file loads the following required drivers: IFSHLP.SYS HIMEM.SYS SETVER.EXE IO.SYS obtains the location of these files from the WinBootDir= line of the MSDOS.SYS file and must be on the hard disk. Windows reserves all global upper memory blocks (UMBs) for Windows 9x operating system use or for expanded memory support using the Expanded Memory Specification (EMS). The AUTOEXEC.BAT file is processed if present, and any terminate-and-stay resident (TSR) programs listed within are loaded into memory.
Phase 3Loading and Running the WIN.COM File The WIN.COM file is loaded and run. The WIN.COM file accesses the VMM32.VXD file. If enough RAM is available, the VMM32.VXD file loads into memory; otherwise, it is accessed from the hard disk (resulting in a slower startup time). The real-mode virtual device driver loader checks for duplicate virtual device drivers (VxDs) in the WINDOWS\SYSTEM\VMM32 folder and the VMM32.VXD file. If a VxD exists in both the WINDOWS\SYSTEM\VMM32 folder and the VMM32.VXD file, the duplicate VxD is "marked" in the VMM32.VXD file so that it is not loaded. VxDs not already loaded by the VMM32.VXD file are loaded from the [386 Enh] section of the WINDOWS\SYSTEM.INI file. Required VxDs Some VxDs are required for Windows to run properly. These required VxDs are loaded automatically and do not require a Registry entry. Windows 9x requires the following VxDs: BIOSXLAT | CONFIGMG | DYNAPAGE | DOSMGR | EBIOS | IFSMGR | INT13 | IOS | PAGESWAP | SHELL | V86MMGR | VCD | VCACHE | VCOMM | VCOND | VDD | VDMAD | VFAT*VKD | VMCPD | VPICD | VTD | VTDAPI | VWIN32 | VXDLDR |
|
The real-mode virtual device driver loader checks that all required VxDs loaded successfully. If not, it attempts to load the drivers again. After the real-mode virtual device driver loading is logged, driver initialization occurs. If any VxDs require real-mode initialization, they begin their processes in real mode. VMM32 switches the computer's processor from real mode to protected mode. A three-phase VxD initialization process occurs in which the drivers are loaded according to their InitDevice instead of the order in which they are loaded into memory. After all the VxDs are loaded, the KRNL32.DLL, GDI.EXE, USER.EXE, and EXPLORER.EXE (the default Windows 9x GUI shell) files are loaded. If a network is specified, load the network environment and multiuser profiles. The user is prompted to log on to the installed network. Windows 9x/Me enables multiple users to save their custom desktop settings. When a user logs on to Windows, her desktop settings are loaded from the Registry. If the user does not log on, the desktop configuration uses a default desktop. Programs in the StartUp group and the RunOnce Registry key are run during the last phase of the startup process. After each program in the RunOnce Registry key is started, the program is removed from the key.
Windows NT/2000/XP Startup When you start a Windows NT, 2000, or XP system (which are all based on the same set of integral code), the boot process is different from that of a DOS or Windows 9x/Me system. Instead of the IO.SYS and MSDOS.SYS files used by 9x/Me, Windows NT/2000/XP use an OS loader program called Ntldr. The basic Windows NT/2000/XP startup process is described in the following step-by-step procedures: 1. | The partition boot sector loads Ntldr (NT Loader). It then switches the processor to protected mode, starts the file system, and reads the contents of Boot.ini. The information in Boot.ini determines the startup options and initial boot menu selections (dual-booting, for example). If dual-booting is enabled, and a non-NT/2000/XP OS is chosen, Bootsec.dos is loaded. If SCSI drives are present, Ntbootdd.sys is loaded, which contains the SCSI boot drivers.
| 2. | Ntdetect.com gathers hardware configuration data and passes this information to Ntldr. If more than one hardware profile exists, Windows uses the correct one for the current configuration. If the ROM BIOS is ACPI compliant, Windows uses ACPI to enumerate and initialize devices.
| 3. | The kernel loads. Ntldr passes information collected by NTDetect.com to Ntoskrnl.exe. Ntoskrnl then loads the kernel, Hardware Abstraction Layer (Hal.dll), and Registry information. An indicator near the bottom of the screen details progress.
| 4. | Drivers load and the user logs on. Networking-related components (for example, TCP/IP) load simultaneously with other services and the Begin Logon prompt appears onscreen. After a user logs on successfully, Windows updates the Last Known Good Configuration information to reflect the current configuration state.
| 5. | Plug and Play detects and configures new devices. If new devices are detected, they are assigned resources. Windows extracts the necessary driver files from Driver.cab. If the driver files are not found, the user is prompted to provide them. Device detection occurs simultaneously with the operating system logon process.
|
The following files are processed during Windows NT/2000/XP startup: Ntldr Boot.ini Bootsect.dos (multiple-boot systems only) Ntbootdd.sys (loaded only for SCSI drives) Ntdetect.com Ntoskrnl.exe Hal.dll Files in systemroot\System32\Config (Registry) Files in systemroot\System32\Drivers (drivers)
Note If you see error messages during startup or your system doesn't start properly, restart the system, press the F8 key (Windows 2000/XP only) to open the startup menu, and select Enable Boot Logging to create a file called Ntbtlog.txt. This file records events during startup and can help you determine which files or processes are not loading correctly.
|
