IBM PC-AT‎ > ‎Windows‎ > ‎Boot Process (detailed)‎ > ‎

Phase 4 - Boot Sector of File System

At this point, the MBR (if a hard disk) or the BIOS (if a floppy disk) has loaded the first 512 bytes (at least) from the start of the partition or (emulated) floppy disk into segment 0x7e0 ??? (unless emulation specified a specific address).  The MBR / BIOS should verify the bytes at offset 510 are the magic value 0x55, 0xAA and halt with an error if not (or perhaps return to Phase 1 to try other devices).  Next the MBR does a far jump or the BIOS does a far call to offset zero of the memory segment.  Generally, all (16-bit) segment registers are set to the same value (the load segment), the DX register contains the device number (128 typical), and all other registers are undefined.
At this point, anything can happen!  It all depends on the code written to the boot sector of the file system (also known as the Volume Boot Record or VBR).  This is normally written only once, when the disk / partition is formatted.  (Contrast with the MBR which is re-written whenever a change is made to an active or primary partion.)  The code here is specific to the file system on the disk / partition.  Below are some examples.
For a FAT file system, the boot sector would check the total sectors in the file system and sectors per cluster to deduce the number of clusters.  Based on that it would calculate the FAT element size (12, 16, or 32 bit); it would multiply that by the number of FATs (and add any hidden sectors) to get the potential start of data.  If it has a hard-coded directory then the number of directory entries is divided (based on sector size) to determine the root directory size.  The root directory size is added to the potential start of data to get the actual start of data (unless the root directory is not fixed, in which case the potential equals the actual).  Next it searches the root directory for a file called IO.SYS or JO.SYS or NTLDR or BOOTMGR or IBMBIO.SYS.  This depends mainly on the operating system used to format the disk... however if you upgrade your operating system this boot sector may be over-written (this is most common with the active partition, which is usally the first partition... non active partitions rarely have their boot sector updated, even when you upgrade your operating system).  Old versions of DOS look for IO.SYS and/or IBMBIO.SYS and if not the verfy first entry in the root directory, and if not marked as hidden + read-only + system, then they cry like a baby.  Windows 9x will look for IO.SYS or JO.SYS but they can be anywhere in the root directory and the file attributes are not important.  See below for cases where it might search for NTLDR or BOOTMGR.
For an NTFS boot sector, the general process follows (this assumes the disk is not encrypted or compressed).  The boot sector code would first check the cluster size and starting cluster of the MFT.  Based on that it gets the starting sector of the MFT.  With that and the MFT entry size, it can begin scanning the file table.  First it checks that $MFT is the first entry and refers to itself.   Next it looks for the root directory and notes its "node value" (MFT index).  Next it looks for a file that is a member of the root directory (per the node value) which is named NTLDR (in Windows NT / 2K / XP) or BOOTMGR (in Windows Vista / 2008 / 7 / 8).
For an Ext2/3 file system, the boot loader typically loads LILO or GRUB (although there are several sources on the web about the file system, I have yet to find a nice web page that explains the boot sector).  These generally load a hard-coded set of sectors, which results in chaos if things change.  That is, the boot sector must be re-written by the software if the target file changes size or location (which is mighty hard to do if the system won't boot).  It's been a while since I compared them and this section is about Windows anyway so no details to find here!
So the above are typical.  You might install Linux to dual-boot your system and find that the boot sector of your NTFS partition is trying to load GRUB... or you might upgrade from Windows 9x to Windows XP and find that your FAT file system is looking for NTLDR... etc.  The important thing is not to run old "restore" / "fix disk" programs on newer systems.  For example, running SCANDISK from Windows 95 can ruin long filenames on Windows 98 / ME (or any later version that uses FAT).  For example, running CHKDSK from Windows XP can ruin volume shadow copy on Windows 7.
DOS and Windows 9X will load IO.SYS and start that ... it is basically the kernel of the DOS, and will not be discussed further, due to major differences with later Windows.  However, some of the later concepts, such as loading a registry hive, starting services, and session manager also apply to these older systems.  I would like to say that at least with Windows 98, perhaps Windows 95 (maybe even DOS 6.22), that the file system boot sector began using LBA exclusively.  The change most likely occurred with Windows '95 OSR2 (i.e., FAT32).

© H2Obsession, 2014