/FixMBR
writes Disk's Boot Sector (commonly called MBR
), while /FixBoot
writes Partition's Boot Sector (commonly called VBR
or PBR).
All this boils down to how Windows boots on BIOS (non-UEFI) systems. 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. Windows or Linux kernel). So the system bootstraps execution process in stages from small-sized code to larger one. That's why we have bootloaders.
In first (or zero) stage BIOS loads the first sector of selected disk in RAM and starts execution at predefined offset. It happens on all BIOS compatible systems, irrespective of the installed OS. So the first sector involved in boot(strapp)ing is called Boot Sector.
Now isn't the MBR just a type of boot sector?
Yes. MBR is the boot sector we most commonly interact with. /FixMBR
writes "to the system partition" is not correct. MBR is written to the first sector of the disk (even on GPT disks).
Isn't MBR the only boot sector Windows uses?
No. It also uses VBR/PBR.
Depending on the installed bootloader and OS, there might exist more boot sectors on partitions too. 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. 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. See more details here.
But not all OSes boot alike. 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. 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 and other bootloaders like SYSLINUX can also be written to VBR.
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. 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.
Once you decide to come back to Windows' native booting, run BootRec /FixMBR
, and GRUB is gone. Inversely we can also make Windows' BootMgr chainload GRUB by modifying BCD using third party tools like EasyBCD or BootICE, or using Windows' bcdedit
tool to add a new entry.
Rewriting VBR is usually not needed, except if you accidentally (or intentionally) write e.g. GRUB to VBR of Windows' Active Partition. In this case BootRec /FixBoot
is also required to successfully resume Windows' native boot chain.
Note that both of the above commands just rewrite the executable part of MBR/VBR, other parts are untouched e.g. Partition Table in MBR. Like Partition Table in MBR describes partition layout, BIOS Parameter Block in NTFS VBR describes filesystem layout. /FixBoot
cannot fix problems in BPB.
For instance if you replace the Windows Active Partition, or move the installation to another disk so that the starting sector number of the partition changes, Windows won't boot, even if you fix MBR/VBR and recreate/fix BCD entries (using bcdboot
/bcdedit
, which is also required if the disk identifier/signature changes because that's hard-coded in BCD store entries). In one of the BPB fields the number of first partition sector is hard-coded, which needs to be fixed. You can see details here.
RESOURCES: