FVE_E_NO_BOOTSECTOR_METRIC (0x80310004): BitLocker MBR Fix

You click "Turn on BitLocker," and Windows immediately slaps you with FVE_E_NO_BOOTSECTOR_METRIC (0x80310004). The message is maddeningly vague: "The master boot record (MBR) is not TPM-aware." I know this error is infuriating, especially when you're trying to encrypt a laptop before it leaves the office. This tripped me up the first time too — back when I was rolling out BitLocker to 400 machines and a batch of older Dells refused to cooperate.

The short version: BitLocker needs the boot sector to include a specific measurement hook that the TPM can read at startup. If your disk is using a plain old MBR layout — the kind that legacy BIOS systems use — that hook isn't there. No hook, no TPM seal, no encryption. The error is Windows being honest for once.

Below are the three causes I've run into most often, in order of how frequently they show up.

Cause 1: The disk is MBR instead of GPT (most common)

This is the big one. Nearly every 0x80310004 I've seen comes down to a disk that's still partitioned as MBR. Windows installed on legacy BIOS hardware defaults to MBR, and BitLocker on those systems wants the newer GPT layout with a proper EFI system partition. GPT gives the TPM a known place to look for boot measurements. MBR doesn't.

You can confirm the layout in seconds. Open an elevated Command Prompt and run:

diskpart
list disk
select disk 0
detail disk

Look for a line that says Partition Style: MBR. If that's what you see, you've found your culprit.

The real fix: convert MBR to GPT

You have two options and only one of them is safe without a backup.

Option A — Windows built-in MBR2GPT tool (Windows 10 1703 and later). This is the clean way. It converts the disk in place without data loss if you meet the requirements: no more than three partitions, and enough free space on the disk for the EFI and MSR partitions.

mbr2gpt /validate /disk:0 /allowFullOS
mbr2gpt /convert /disk:0 /allowFullOS

Run validate first. If it passes, convert. Then reboot into your BIOS/UEFI and switch the boot mode from Legacy/CSM to UEFI. Do not skip that step — the machine won't boot otherwise.

Option B — back up and rebuild. If validate fails, skip the conversion. Back up your data, wipe the disk, and reinstall Windows with UEFI boot enabled from the start. It's slower but it works every time, and I'd rather you spend two hours than four days recovering from a botched conversion.

If you're on a machine that simply can't do UEFI (some pre-2012 hardware), you're stuck. BitLocker with TPM won't work on that box. Use BitLocker with a startup PIN and a USB key instead, or accept that the hardware is past its encryption-friendly life.

Cause 2: You're booting via legacy BIOS or CSM

Sometimes the disk is already GPT and you still get 0x80310004. That usually means the firmware is still set to boot in Legacy or CSM mode, even though the disk could support UEFI. The TPM can't measure the boot path the way BitLocker expects, so it refuses to seal.

I've seen this after IT clones a UEFI image onto hardware where someone forgot to flip the BIOS setting. Everything looks right in Windows, but the firmware is running in the wrong mode.

The fix

1. Reboot and enter BIOS/UEFI setup (usually F2, F10, Del, or Esc — depends on the vendor).
2. Find the boot mode setting. On Dell it's under Boot Sequence → Boot List Option. On HP it's under Boot Options → Legacy Support. On Lenovo it's Startup → UEFI/Legacy Boot.
3. Set it to UEFI Only and disable CSM/Legacy Support.
4. Save and exit.

If Windows won't boot after this, your disk is still MBR — go back to Cause 1 and convert it first. The firmware change only works if the disk layout matches.

Cause 3: A corrupt or missing boot sector measurement

Less common, but it happens. The disk is GPT, UEFI is on, and BitLocker still fails. In that case the EFI system partition may be missing its boot files, or the BCD store is damaged. The TPM has nothing valid to measure.

This shows up most often after a failed Windows update, a bad clone operation, or a third-party partition tool that rewrote the boot sector without warning.

The fix: rebuild the boot files

Boot from Windows installation media (a USB made with the Media Creation Tool works). At the setup screen, hit Shift + F10 to open a command prompt. Then:

diskpart
list volume
select volume 3
assign letter=S
exit
bcdboot C:\Windows /s S: /f UEFI

Replace S with whatever letter you assigned to the EFI system partition — it's usually the small FAT32 volume around 100–260 MB. The /f UEFI flag forces the correct boot files. Reboot and try BitLocker again.

If bcdboot throws errors, run chkdsk C: /f /r first. A failing drive will keep producing this error no matter how many times you rebuild the boot sector. Check the SMART status too — I've had two drives that looked fine on the surface but were quietly degrading and shredding their own boot records.

Quick reference

One last thing worth saying: back up before you touch any of this. MBR2GPT is safe when the validation passes, and bcdboot is low-risk, but boot sector work is boot sector work. A 20-minute backup beats a weekend of data recovery.