Windows 11 25H2: SHA-256 TCG replay has zero values for PCR 0–7, causing BitLocker TPM protector error 0x8007000D

Question

Windows 11 25H2: SHA-256 TCG replay has zero values for PCR 0–7, causing BitLocker TPM protector error 0x8007000D

luk4s0102 0

Hello,

we are investigating a reproducible Measured Boot / BitLocker problem on multiple Lenovo ThinkPad X390 Yoga systems.

Environment:

Windows 11 Pro 25H2, build 26200.8875

UEFI Secure Boot enabled

ThinkPad X390 Yoga, Type 20NQ

BIOS N2LETA7W, version 2.07

Nuvoton NPCT75x TPM 2.0

TPM firmware 7.2.2.0

Windows selects SHA-256 for TPM measurements

The TPM is present, enabled, activated, owned, ready, not locked out, and reports that it is ready for storage and attestation.

However, running:

tpmtool comparepcr sha256

shows that the reconstructed TCG values for PCR 0 through PCR 7 are all zero, while the corresponding hardware PCRs contain real non-zero measurements.

Example:

TCG log PCR[00]:

0000000000000000000000000000000000000000000000000000000000000000

Hardware PCR[00]:

5d63abe85068a7738ab533315a09ed6d5150c218a782931a0598fd9821443187

The same condition exists for PCR 1 through PCR 7.

PCR 11 through PCR 14 match correctly, suggesting that later Windows measurements are present while the early UEFI measurements are missing from, or cannot be replayed from, the TCG2 event log.

The current Windows Measured Boot JSON reports:

HealthStatus: Possibly attestable

PcrsMatchTcgLog: False

SecureBootEnabled ValueFromComputer: True

SecureBootEnabled ValueFromTcgLog: False

SoftwarePcrReplayHresult: 0x80070057

HardwarePcrReplayHresult: 0x80280407

BitLocker PCR7 binding status: Binding not possible

When BitLocker attempts to create a TPM protector, both methods fail:

ProtectKeyWithTPM: 0x8007000D / ERROR_INVALID_DATA

ProtectKeyWithTPMAndPin: 0x8007000D / ERROR_INVALID_DATA

Troubleshooting already completed:

Installed the latest official Lenovo BIOS 2.07.

Verified UEFI mode and Secure Boot.

Completed Windows UEFI CA 2023 and DBX servicing.

Verified the Microsoft-signed Windows Boot Manager.

Performed multiple cold boots.

Reinstalled Windows multiple times.

Cleared and reprovisioned the TPM on one affected test system.

Restored the UEFI Secure Boot factory keys.

Repeated tpmtool comparepcr sha256 immediately after restoring the factory keys.

The Secure Boot variables demonstrably returned to their firmware-default state after restoring the factory keys, but the TCG replay remained unchanged: PCR 0–7 were still zero.

On one affected system, older Windows boots previously produced attestable Measured Boot logs of approximately 94–105 KB. The first boots of a newer Windows installation produced logs of only approximately 52 KB and immediately showed the missing early PCR measurements. This occurred before our custom BIOS, TPM, BitLocker or Secure Boot servicing steps.

Questions for Microsoft:

Does this indicate a truncated or malformed firmware TCG2 event log, or could Windows 11 25H2 fail to parse otherwise valid early firmware events?

What do HRESULTs 0x80070057 and 0x80280407 specifically indicate during software and hardware PCR replay?

Is there a known regression involving Windows 11 25H2, the current Windows Boot Manager, or TPMTool when processing TCG2 logs on this platform?

Is BitLocker expected to reject all TPM-based protectors with 0x8007000D when PCR 0, 2, 4 and 7 cannot be reconstructed but PCR 11 matches?

Are there additional Microsoft-supported tracing tools or ETW providers we should collect?

Can this be escalated to the Windows Measured Boot / BitLocker engineering team?

We have the following diagnostic material available privately:

TPM driver ETL trace

tpmtool gatherlogs output

raw TCG Measured Boot logs

Measured Boot JSON reports

complete software and hardware PCR values

Kernel-Boot, TPM-WMI and BitLocker event logs

Secure Boot variable hashes and sizes

For privacy reasons, the full diagnostic archives are not attached publicly. A sanitized tpmtool comparepcr sha256 output can be provided in this thread.

Thank you.Hello,

we are investigating a reproducible Measured Boot / BitLocker problem on multiple Lenovo ThinkPad X390 Yoga systems.

Environment:

Windows 11 Pro 25H2, build 26200.8875

UEFI Secure Boot enabled

ThinkPad X390 Yoga, Type 20NQ

BIOS N2LETA7W, version 2.07

Nuvoton NPCT75x TPM 2.0

TPM firmware 7.2.2.0

Windows selects SHA-256 for TPM measurements

The TPM is present, enabled, activated, owned, ready, not locked out, and reports that it is ready for storage and attestation.

However, running:

tpmtool comparepcr sha256

shows that the reconstructed TCG values for PCR 0 through PCR 7 are all zero, while the corresponding hardware PCRs contain real non-zero measurements.

Example:

TCG log PCR[00]:

0000000000000000000000000000000000000000000000000000000000000000

Hardware PCR[00]:

5d63abe85068a7738ab533315a09ed6d5150c218a782931a0598fd9821443187

The same condition exists for PCR 1 through PCR 7.

PCR 11 through PCR 14 match correctly, suggesting that later Windows measurements are present while the early UEFI measurements are missing from, or cannot be replayed from, the TCG2 event log.

The current Windows Measured Boot JSON reports:

HealthStatus: Possibly attestable

PcrsMatchTcgLog: False

SecureBootEnabled ValueFromComputer: True

SecureBootEnabled ValueFromTcgLog: False

SoftwarePcrReplayHresult: 0x80070057

HardwarePcrReplayHresult: 0x80280407

BitLocker PCR7 binding status: Binding not possible

When BitLocker attempts to create a TPM protector, both methods fail:

ProtectKeyWithTPM: 0x8007000D / ERROR_INVALID_DATA

ProtectKeyWithTPMAndPin: 0x8007000D / ERROR_INVALID_DATA

Troubleshooting already completed:

Installed the latest official Lenovo BIOS 2.07.

Verified UEFI mode and Secure Boot.

Completed Windows UEFI CA 2023 and DBX servicing.

Verified the Microsoft-signed Windows Boot Manager.

Performed multiple cold boots.

Reinstalled Windows multiple times.

Cleared and reprovisioned the TPM on one affected test system.

Restored the UEFI Secure Boot factory keys.

Repeated tpmtool comparepcr sha256 immediately after restoring the factory keys.

The Secure Boot variables demonstrably returned to their firmware-default state after restoring the factory keys, but the TCG replay remained unchanged: PCR 0–7 were still zero.

On one affected system, older Windows boots previously produced attestable Measured Boot logs of approximately 94–105 KB. The first boots of a newer Windows installation produced logs of only approximately 52 KB and immediately showed the missing early PCR measurements. This occurred before our custom BIOS, TPM, BitLocker or Secure Boot servicing steps.

Questions for Microsoft:

Does this indicate a truncated or malformed firmware TCG2 event log, or could Windows 11 25H2 fail to parse otherwise valid early firmware events?

What do HRESULTs 0x80070057 and 0x80280407 specifically indicate during software and hardware PCR replay?

Is there a known regression involving Windows 11 25H2, the current Windows Boot Manager, or TPMTool when processing TCG2 logs on this platform?

Is BitLocker expected to reject all TPM-based protectors with 0x8007000D when PCR 0, 2, 4 and 7 cannot be reconstructed but PCR 11 matches?

Are there additional Microsoft-supported tracing tools or ETW providers we should collect?

Can this be escalated to the Windows Measured Boot / BitLocker engineering team?

We have the following diagnostic material available privately:

TPM driver ETL trace

tpmtool gatherlogs output

raw TCG Measured Boot logs

Measured Boot JSON reports

complete software and hardware PCR values

Kernel-Boot, TPM-WMI and BitLocker event logs

Secure Boot variable hashes and sizes

For privacy reasons, the full diagnostic archives are not attached publicly. A sanitized tpmtool comparepcr sha256 output can be provided in this thread.

Thank you.

0 comments

1 answer

Your answer

Answer 1

Hello @luk4s0102

Thanks for providing the detailed diagnostics. Based on the evidence you've collected, I don't think additional TPM clearing, Windows reinstallations, or Secure Boot key resets are likely to add much at this point.

The key observation is:

TCG replay PCR 0–7 = all zero

Hardware PCR 0–7 = populated

PCR 11–14 = replay correctly

PcrsMatchTcgLog = False

That is not the expected state of a valid Measured Boot replay.

Microsoft describes Measured Boot as recording measurements into TPM PCRs while corresponding measurements are recorded in the TCG/Windows Boot Configuration Log. The event log is then replayed to reconstruct the expected PCR state and compare it with the TPM's actual PCR values.

1. Firmware TCG2 log vs. Windows parsing

Your results are consistent with either:

the firmware isn't supplying the early SHA-256 measurements correctly in the TCG2 event log, or
the events are present but Windows 11 25H2 is failing to parse/replay them correctly.

Tbsi_Get_TCG_Log_Ex obtains the Windows Boot Configuration Log/TCG log supplied through the platform. Microsoft documents that modern logs use TCG_PCR_EVENT2, where each event contains one or more algorithm-specific digests such as SHA-256.

Because your hardware PCRs contain valid non-zero SHA-256 values, the TPM clearly received measurements. The problem is that Windows cannot reconstruct those measurements from the event log.

The fact that PCR 11–14 replay correctly while PCR 0–7 don't is particularly important because it argues against a general TPM failure.

2. The HRESULTs

0x80070057 maps to: E_INVALIDARG / ERROR_INVALID_PARAMETER

In this context, I would interpret SoftwarePcrReplayHresult: 0x80070057 as evidence that Windows' software replay encountered data it couldn't process successfully. However, I wouldn't infer the exact malformed structure from that HRESULT alone.

Similarly, I wouldn't try to assign a definitive firmware defect based solely on 0x80280407 without Microsoft internal symbols/documentation for that particular replay path.

The raw event log is more valuable than either HRESULT for determining the root cause.

3. The change in log size is significant

This part of your testing is especially interesting:

Previous attestable logs: ~94–105 KB
Current failing logs: ~52 KB

together with the observation that the older boots were attestable while the newer installation immediately produced the smaller logs.

That doesn't prove Windows truncated the log, but it's strong enough that I would compare a known-good and failing log event-by-event.

Microsoft provides TBSLogGenerator.exe and PCPTool.exe specifically for decoding Measured Boot logs and tracking PCR changes.

I would compare:

EV_EFI_VARIABLE_DRIVER_CONFIG

EV_EFI_VARIABLE_BOOT

EV_EFI_BOOT_SERVICES_APPLICATION

EV_SEPARATOR

and other PCR 0/1/2/4/7 measurements between a known-good log and the current failing log.

If those early events are physically absent from the raw TCG log, that points strongly toward the firmware/UEFI TCG2 log producer.

If they're present with valid SHA-256 digests but Windows' replay still produces zero PCR values, that would point much more strongly toward a Windows parsing/replay regression.

4. BitLocker behavior

The BitLocker failure is consistent with the replay problem.

BitLocker relies on PCR measurements to establish that the boot environment is trustworthy. Microsoft specifically notes that changes or inconsistencies in PCR measurements can affect BitLocker and cause recovery or other protector-related problems.

With:

PcrsMatchTcgLog = False

PCR7 binding = Binding not possible

and Windows unable to reconstruct the early boot measurements, I wouldn't consider 0x8007000D / ERROR_INVALID_DATA from ProtectKeyWithTPM surprising.

I also wouldn't recommend trying to bypass the validation or force-create the TPM protector. That would treat the symptom rather than determine why the measured-boot evidence is invalid.

One test would be especially valuable

If possible, take one affected X390 Yoga and boot a known earlier Windows build that previously produced valid Measured Boot results, while keeping BIOS version, TPM firmware, Secure Boot keys. BIOS settings, and hardware unchanged.

Then compare tpmtool comparepcr sha256 and the raw Measured Boot log between the two Windows builds.

If the older Windows build reconstructs PCR 0–7 correctly while 25H2 doesn't on identical firmware/hardware, that would be very strong evidence of a Windows-side regression.

Conversely, if the older Windows installation now exhibits the same zero-PCR replay, the evidence would shift toward firmware/UEFI behavior.

6. I think escalation is justified

Given that you've already reproduced this across multiple identical systems and collected: TPM ETL traces, tpmtool gatherlogs, raw TCG logs, Measured Boot JSON, hardware and software PCR values, Kernel-Boot logs, TPM-WMI logs, BitLocker logs, and Secure Boot variable information

I think you've reached the point where this warrants review by the Windows Measured Boot / TPM / BitLocker engineering team rather than repeating standard TPM troubleshooting.

I would include a known-good and failing raw TCG log pair, if available, with the escalation. That comparison should help determine whether the early firmware measurements disappeared from the log or Windows stopped interpreting them correctly.

I wouldn't post those diagnostic archives publicly. A Microsoft moderator/support engineer can request them through an appropriate private support channel.

I also couldn't find a currently documented Windows 11 25H2 known issue specifically matching SHA-256 PCR 0–7 replaying as zero on the ThinkPad X390 Yoga/Nuvoton NPCT75x combination, so I wouldn't classify this as a confirmed Windows 25H2 regression yet.

Based on the evidence presented, however, a firmware TCG2 logging problem or Windows TCG2 parsing/replay regression are both credible possibilities, and the known-good versus failing raw-log comparison should be the next useful discriminator.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.