Imagine I am working with some old OS installer that thinks that my drive uses first 512 bytes for managing partitions, and it writes to it its data. Can this corrupt my system in such a way that UEFI firmware will not run boot loaders of OS that are UEFI-compatable and have been previously installed to the drive, or will firmware be able to see, once again, previously allocated GPT partitions on reboot?


Overwriting the MBR should never completely brick a regular PC, whether it's "BIOS" or "UEFI"... It may or may not make the OS unbootable, but it will not affect the pre-OS firmware and you'll still be able to boot from some other media and recreate the MBR (or at least reinstall the OS).

That aside, old programs should not cause problems for EFI systems because the 'GPT' partition table (used on most EFI disks) actually starts at the second sector – it reserves the first sector for a so-called "protective MBR", which is there specifically to remain compatible with BIOS systems and MBR tools.

Traditional MBR serves two purposes: the first 440 bytes are used for the BIOS-style "stage 1" bootloader; the remaining 72 bytes are used for the partition table.

The "protective MBR" on GPT-partitioned disks still retains the same format, except it always holds one very large "protective" partition. Your old MBR partitioning tools won't think the disk is empty; they will actually see one giant partition that covers the entire disk, and no decent tool will go as far as automatically deleting actual partitions even if they're of unknown type.

Windows XP 'Disk Management' showing the protective partition

(However, if you do delete it and create new partitions, this can confuse the firmware because now the disk has two partition tables holding different information.)

Meanwhile, tools which overwrite the bootloader area will have no effect on EFI boot process, because the EFI firmware directly looks for a specific file in a specific partition – it doesn't use the old bootcode location for anything.

| improve this answer | |
  • Small correction to that. If your system isn't pure UEFI, but UEFI with CSM (or "legacy support" as some vendors call it), it may still do an old-style MBR boot in stead of a real UEFI boot. In that case the normal problems associated with overwriting the MBR still apply. – Tonny Mar 23 at 11:47
  • Yeah, but in that case the disk will almost always have a "regular" MBR partition table as well, so the problem as described in OP's post will not exist in the first place. (Although mixing BIOS+GPT or EFI+MBR for internal OS disks is technically possible, it's very rarely useful and not something you'll see on a typical Windows system.) – user1686 Mar 23 at 11:49
  • I've seen a couple of systems with a CSM boot from the Legacy MBR partition in the GPT calling the NTLoader which then loaded Windows 7. In all cases these where factory installed PC's (cheap label supermarket brand) that had Win7 installed on a single NTFS partition on a GPT disk with CSM boot. There was a EFI folder but that didn't contain valid bootfiles for this PC. The Windows 10 Inplace Upgrade completely borked these trying to upgrade the EFI bootloader. Fresh Windows 10 install with EFi only worked just fine. Whatever the vendor posesed to sell them like that... – Tonny Mar 23 at 12:03
  • Whether the protective MBR covers the entire disk or not depends on the size of the disk. If the size of the disk exceeds the maximum partition size representable using the legacy 32-bit LBA entries in the MBR partition table, the recorded size of this partition is clipped at the maximum, and the rest of the disk is ignored. – fpmurphy Mar 23 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.