Going further deeper, GRUB can be configured to directly run \bootmgr executable file (by using ntldr command instead of default chainloader), entirely bypassing VBR executable code. On a multi-boot system grub.cfg usually includes an entry for Windows, so it's the GRUB (not Windows) MBR which executes BootMgr in VBR (even if it's not on the Active Partition), when Windows entry is selected by user. GRUB and other bootloaders like SYSLINUX can also be written to VBR. It reads its configuration from /grub/grub.cfg (placed in /boot partition, which might be different than Linux installation partition mounted at /) and loads Linux kernel (or shows a selection menu if grub.cfg contains multiple entries). GRUB (popular boot loader in Linux world), for instance, installs itself to MBR which executes the next stage(s) written to few sectors right after MBR. See more details here.īut not all OSes boot alike. By now VBR is large enough to understand filesystem structure, so it executes \bootmgr file (placed in root of the Active Partition), which reads its configuration from BCD file (usually \Boot\BCD) and runs winload.exe (or shows a selection menu if BCD contains multiple entries), which runs Windows kernel.
In case of Windows, executable code in MBR finds Active Partition or Boot Partition (Windows calls it System Partition) in Partition Table (also part of the MBR) and executes that partition's boot sector (VBR) which contains BootMgr code. Isn't MBR the only boot sector Windows uses?ĭepending on the installed bootloader and OS, there might exist more boot sectors on partitions too. MBR is written to the first sector of the disk (even on GPT disks). FixMBR writes "to the system partition" is not correct. MBR is the boot sector we most commonly interact with. Now isn't the MBR just a type of boot sector? So the first sector involved in boot(strapp)ing is called Boot Sector. It happens on all BIOS compatible systems, irrespective of the installed OS. In first (or zero) stage BIOS loads the first sector of selected disk in RAM and starts execution at predefined offset. So the system bootstraps execution process in stages from small-sized code to larger one.
As we know, due to limitations of BIOS firmware (it runs in real-mode and can't access more than 1 MiB of RAM), it cannot load and execute the actual OS (e.g. FixMBR writes Disk's Boot Sector (commonly called MBR), while /FixBoot writes Partition's Boot Sector (commonly called VBR or PBR).Īll this boils down to how Windows boots on BIOS (non-UEFI) systems. This command does create a windows-specific result in that it reminds the hard drive where to find Windows in particular. So this is fixing the next link in the chain of the boot process. fixboot replaces the next part - the entry in the partition table that points to where the actual loadable executable is located for the OS. In essence, this is not necessarily a Windows-specific item. So this exists on any drive that has been formatted and effectively exists to read the next little bit on the hard drive that tells where the/an OS is supposed to be located. fixmbr replaces the information and small executable that reads the partition table to find where the OS may be located.
The two command options effectively fix different links in the boot chain: The MBR is "smaller" in that it is the very first thing on the drive, that then uses the partition table to continue the boot process to a specific OS. It appears that MBR and Partition Table are in the same sector on a drive. Best description I've found of the hard drive configuration for a Windows OS is this one. There are lots of links out there on this topic but they are ambiguous in describing the difference/relationship between the two. This turned out to be a very interesting question.