OK, that's it, I'm throwing the book at ya all
From "Microsoft Windows Internals, 4th Edition"
Boot Process
In describing the Windows boot process, we'll start with the installation of Windows and proceed through the execution of boot support files. Device drivers are a crucial part of the boot process, so we'll explain the way that they control the point in the boot process at which they load and initialize. Then we'll describe how the executive subsystems initialize and how the kernel launches the user-mode portion of Windows by starting the Session Manager process (Smss.exe), the Windows subsystem, and the logon process (Winlogon). Along the way, we'll highlight the points at which various text appears on the screen to help you correlate the internal process with what you see when you watch Windows boot.
The early phases of the boot process differ significantly on x86 and x64 systems versus IA64 systems. The next sections describe the portions of the boot process specific to x86 and x64 and follow with a section describing the IA64-specific portions of the boot process.
----
The Windows boot process doesn't begin when you power on your computer or press the reset button. It begins when you install Windows on your computer. At some point during the execution of the Windows Setup program, the system's primary hard disk is prepared with code that takes part in the boot process. Before we get into what this code does, let's look at how and where Windows places the code on a disk. Since the early days of MS-DOS, a standard has existed on x86 systems for the way physical hard disks are divided into volumes. Microsoft operating systems split hard disks into discrete areas known as partitions and use file systems (such as FAT and NTFS) to format each partition into a volume. A hard disk can contain up to four primary partitions. Because this apportioning scheme would limit a disk to four volumes, a special partition type, called an extended partition, further allocates up to four additional partitions within each primary partition. Extended partitions can contain extended partitions, which can contain extended partitions, and so on, making the number of volumes an operating system can place on a disk effectively infinite.
Boot Components:
Component:Master Boot Record (MBR) code
Executes in: 16-bit real mode
Responsibilities:
Reads and loads partition boot sectors.
Component:Boot sector
Executes in: 16-bit real mode
Responsibilities: Reads the root directory to load Ntldr.
Component: ntldr
Executes in:16-bit real mode and 32-bit or 64-bit protected mode; turns on paging
Responsibilities:
Reads Boot.ini, presents boot menu, and loads Ntoskrnl.exe, Bootvid.dll, Hal.dll, and boot-start device drivers. If a 32-bit installation is booted, switches to 32-bit protected mode; if a 64-bit installation is booted, switches to 64-bit long mode.
Component:Ntdetect.com
Executes in:16-bit real mode
Responsibilities:
Performs hardware detection for Ntldr.
Component:Ntbootdd.sys
Executes in: Protected mode
Responsibilities:
Device driver used for disk I/O on SCSI and Advanced Technology Attachment (ATA) systems where the BIOS is not used.
Component:Ntoskrnl.exe
Executes in:Protected mode with paging
Responsibilities:
Initializes executive subsystems and boot and system-start device drivers, prepares the system for running native applications, and runs Smss.exe.
Component:Hal.dll
Executes in:Protected mode with paging
Responsibilities:
Kernel-mode DLL that interfaces Ntoskrnl and drivers to the hardware.
Component:Smss
Executes in:Native application
Responsibilities: Loads Windows subsystem, including Win32k.sys and Csrss.exe, and starts Winlogon process.
Component:Winlogon
Executes in:Native application
Responsibilities: Starts the service control manager (SCM), starts the Local Security Subsystem (LSASS), and presents interactive logon dialog box.
Component:Service control manager (SCM)
Executes in: Native application
Responsibilities: Loads and initializes auto-start device drivers and Windows services.
Physical disks are addressed in units known as sectors. A hard disk sector on an IBM-compatible PC is typically 512 bytes. Utilities that prepare hard disks for the definition of volumes, including the MS-DOS Fdisk utility or the Windows Setup program, write a sector of data called a Master Boot Record (MBR) to the first sector on a hard disk. The MBR includes a fixed amount of space that contains executable instructions (called boot code) and a table (called a partition table) with four entries that define the locations of the primary partitions on the disk. When an IBM-compatible computer boots, the first code it executes is called the BIOS, which is encoded into the computer's ROM. The BIOS selects a boot device, reads that device's MBR into memory, and transfers control to the code in the MBR.
The MBRs written by Microsoft partitioning tools, such as the one integrated into Windows Setup and the Disk Management MMC snap-in, go through a similar process of reading and transferring control. First, an MBR's code scans the primary partition table until it locates a partition containing a flag that signals the partition is bootable. When the MBR finds at least one such flag, it reads the first sector from the flagged partition into memory and transfers control to code within the partition. This type of partition is called a boot partition, and the first sector of such a partition is called a boot sector. The volume defined for the boot partition is called the system volume.
Operating systems generally write boot sectors to disk without a user's involvement. For example, when Windows Setup writes the MBR to a hard disk, it also writes a boot sector to the first bootable partition of the disk. You might have created a MS-DOS boot sector during the installation of MS-DOS, Windows Me, Windows 98, or Windows 95. Windows Setup checks to see whether the boot sector it will overwrite with a Windows boot sector is a valid MS-DOS boot sector. If it is, Windows Setup copies the boot sector's contents to a file named Bootsect.dos in the root directory of the partition.
Before writing to a partition's boot sector, Windows Setup ensures that the partition is formatted with a file system that Windows supports (FAT, FAT32, or NTFS) by formatting the boot partition (and any other partition) with a file system type you specify. If partitions are already formatted, you can instruct Setup to skip this step. After Setup formats the boot partition, Setup copies the files Windows uses to the boot partition (the system volume), including two files that are part of the boot sequence, Ntldr and Ntdetect.com.
Setup must know the partition format before it writes a boot sector because the contents of the boot sector vary depending on the format. For example, if the boot partition is a FAT partition, Windows writes code to the boot sector that understands the FAT file system. But if the partition is in NTFS format, Windows writes NTFS-capable code. The role of the boot-sector code is to give Windows information about the structure and format of a volume and to read in the Ntldr file from the root directory of the volume. Thus, the boot-sector code contains just enough read-only file system code to accomplish this task. After the boot-sector code loads Ntldr into memory, it transfers control to Ntldr's entry point. If the boot-sector code can't find Ntldr in the volume's root directory, it displays the error message "BOOT: Couldn't find NTLDR" if the boot file system is FAT or "NTLDR is missing" if the file system is NTFS.
Ntldr begins its existence while a system is executing in an x86 operating mode called real mode. In real mode, no virtual-to-physical translation of memory addresses occurs, which means that programs that use the memory addresses interpret them as physical addresses and that only the first 1 MB of the computer's physical memory is accessible. Simple MS-DOS programs execute in a real-mode environment. However, the first action Ntldr takes is to switch the system to protected mode. Still no virtual-to-physical translation occurs at this point in the boot process, but a full 32 bits of memory becomes accessible. After the system is in protected mode, Ntldr can access all of physical memory. After creating enough page tables to make memory below 16 MB accessible with paging turned on, Ntldr enables paging. Protected mode with paging enabled is the mode in which Windows executes in normal operation.
After Ntldr enables paging, it is fully operational. However, it still relies on functions supplied by the boot code to access IDE-based system and boot disks as well as the display. The bootcode functions briefly switch off paging and switch the processor back to a mode in which services provided by the BIOS can be executed. If the disk containing the boot volume is SCSIbased and is not accessible using BIOS firmware support, Ntldr loads a file named Ntbootdd.sys and uses it instead of the boot-code functions for disk access. Ntbootdd.sys is a copy of the SCSI miniport driver that Windows uses when its fully operation to access the boot disk. Ntldr next reads the Boot.ini file from the root directory using built-in file system code. Like the boot sector's code, Ntldr contains read-only NTFS and FAT code; unlike the boot sector's code, however, Ntldr's file system code can read subdirectories.
Ntldr next clears the screen. If there is a valid Hiberfil.sys file in the root of the system volume, it shortcuts the boot process by reading the contents of the file into memory and transferring control to code in the kernel that resumes a hibernated system. That code is responsible for restarting drivers that were active when the system was shut down. Hiberfil.sys will be valid only if the last time the computer was shut down it was hibernated.
If there is more than one boot-selection entry in Boot.ini, it presents the user with the boot-selection menu. (If there is only one entry, Ntldr bypasses the menu and proceeds to displaying the startup progress bar.) Selection entries in Boot.ini direct Ntldr to the partition on which the Windows system directory (typically \Windows) of the selected installation resides. This partition might be the same as the boot partition, or it might be another primary partition.
If the Boot.ini entry refers to an MS-DOS installation (that is, by referring to C:\ as the system partition), Ntldr reads the contents of the Bootsect.dos file into memory, switches back to 16-bit real mode, and calls the MBR code in Bootsect.dos. This action causes the Bootsect.dos code to execute as if the MBR had read the code from disk. Code in Bootsect.dos continues an MS-DOS-specific boot, such as is used to boot Microsoft Windows Me, Windows 98, or Windows 95 on a computer on which these operating systems are installed with Windows.
What can we draw from this?
Well, the message "NTLDR is missing" is generated by a either by a working boot sector on the boot drive that cannot actually find NTLDR- or by a corrupt boot sector. Boot sector corruption can look like MBR corruption where the system hangs after BIOS POST at a black screen, or you might see the messages "A disk read error occurred," "NTLDR is missing," or "NTLDR is compressed" displayed in a black screen. This is because The MBR can become corrupt because of hard disk errors, disk corruption as a result of a driver bug while Windows is running, or intentional scrambling as a result of a virus.
the Resolution? Boot into the Recovery Console and execute the fixboot command. This command rewrites the boot sector of the volume that you specify. You should execute the command on both the system and boot volumes if they are different.
Therefore
my advice is to do the following:
1.Download
rc.iso and burn it to a CD. (do not burn it as a data file, burn it as an image.)
2. Set boot order to boot from the CD-ROM first
3. boot from the Disc.
4. type fixmbr and press enter. If it says that it doesn't recognize the MBR, you've struck gold- this means your MBR was corrupt. Allow it to write a fresh MBR in it's place, and then reboot.
