TPM_E_INVALID_PCR_INFO (0x80280010) Fix for BitLocker and Windows Hello

Cause 1: Stale PCR data from a Windows or firmware update (most common)

What's actually happening here is that the TPM holds a set of Platform Configuration Registers (PCRs) that store hashes of boot components. After a BIOS/UEFI update, a Windows feature update, or even a driver change, those hashes change. The TPM still has the old PCR values from before the update, and when BitLocker or Windows Hello tries to validate them, it gets a mismatch — and throws 0x80280010.

This is especially common on Dell and Lenovo machines after a firmware update, but it can happen on any vendor. You'll usually see this error when trying to enable BitLocker, resume a suspended BitLocker drive, or set up Windows Hello PIN/fingerprint.

Fix: Suspend BitLocker, reboot, then resume

The quickest way to clear the stale PCR data is to suspend protection temporarily, reboot, and then resume it. Suspension tells Windows to ignore PCR validation until the next reboot, which forces the TPM to re-measure the new boot components.

1. Open an elevated Command Prompt (Run as administrator).
2. Run manage-bde -protectors -suspend C: (replace C: with your system drive).
3. Reboot the machine.
4. After boot, run manage-bde -protectors -resume C:

If BitLocker isn't the trigger and you're getting this during Windows Hello setup, skip the suspend/resume and try the TPM clear in Cause 2 instead.

Why does this work? The suspend command sets a flag that tells the TPM to skip PCR checks on the next boot, but it doesn't reset the PCRs. The reboot forces the TPM to measure the current boot sequence and store fresh PCR values. The resume then re-enables validation against those new values.

Before doing anything destructive, make sure you have your BitLocker recovery key. If you're not sure where it is, back it up to your Microsoft account or a USB drive. You'll need it if the TPM goes sideways.

Cause 2: TPM firmware bug after a Windows 11 upgrade

Another common trigger is a TPM firmware bug that surfaces right after upgrading to Windows 11, especially on systems with older TPM 2.0 chips from Intel (like the discrete Nuvoton or STMicro chips). These chips sometimes fail to re-read the PCR values correctly after a Secure Boot state change. The TPM itself isn't broken — the firmware just gets confused.

Fix: Update TPM firmware via your OEM

The real fix is to update the TPM firmware. You can't do this from Windows — you need a BIOS/UEFI firmware update from your motherboard or laptop vendor. Here's the drill:

1. Identify your TPM manufacturer: open Device Manager, expand Security devices, and note the TPM model.
2. Go to your OEM's support page (Dell, Lenovo, HP, ASUS, etc.) and check for a recent BIOS update that mentions TPM or PCR fixes.
3. Install the BIOS update following the vendor's instructions. Usually this is done via a USB stick or a Windows-based flasher.
4. After the update, reboot and check if the error persists.

If no BIOS update is available, the alternative is to clear the TPM. This resets the TPM to factory state and clears all keys, including the BitLocker protectors. That's why you need the recovery key — you'll have to re-enable BitLocker afterward.

Clear the TPM (use as last resort)

Clearing the TPM is the nuclear option. It wipes all TPM keys, so BitLocker will require the recovery key on the next boot. Windows Hello will also need to be reconfigured.

1. Press Win + R, type tpm.msc, and hit Enter.
2. In the TPM Management console, click Clear TPM on the right-hand pane.
3. Reboot. The machine will prompt you to confirm the clear during POST.

Only do this if a firmware update isn't available or if the error appears right after a BIOS update that didn't fix it. Clearing TPM is safe — it's designed for this — but it's disruptive.

Cause 3: Corrupted PCR profile from a failed BitLocker key protector

Less common but still out there: a previous BitLocker operation partially wrote a key protector to the TPM, and that corrupted the PCR info. This often happens after a forced shutdown while BitLocker is encrypting or after a failed auto-unlock setup.

The symptom is the same — 0x80280010 when you try to unlock a drive or enable BitLocker — but the root cause is a bad protector entry, not the TPM hardware.

Fix: Remove and re-add the TPM protector

Instead of clearing the whole TPM, you can try removing just the TPM key protector and adding it fresh. This is more surgical and doesn't require a reboot.

1. Open elevated Command Prompt.
2. Run manage-bde -protectors -get C: to list current protectors.
3. Note the numeric ID of the TPM protector (usually starts with {GUID}).
4. Run manage-bde -protectors -delete C: -id {GUID} to remove it.
5. Then run manage-bde -protectors -add C: -tpm to re-add it.

This forces Windows to re-measure the PCRs and create a fresh protector. If the error was caused by a corrupt entry, this fixes it without touching other TPM data.

Why does the re-add work? The add command triggers a full PCR read and stores the current valid values. The old, corrupt protector is gone, so nothing in the TPM references the broken PCR info anymore.

Quick reference table

Start with the suspend/resume — it's non-destructive and fixes most cases. If that doesn't work, check for a BIOS update. Only clear the TPM if you're comfortable re-entering your BitLocker recovery key and redoing Windows Hello. The recovery key is your safety net, so store it before trying anything that touches the TPM.