Seen this Bitlocker Warning with beta 26220.9022 and any VM?

This has happened in two separate Parallels Windows VMs on two different MacBook Pros....After updating each Windows 11 Insider Beta VM to build 26220.9022, I noticed the C: drive showed a yellow BitLocker warning icon in File Explorer. Investigating further, I found that BitLocker protection had been left in a suspended state after the update. However, when I attempted to Resume Protection from Control Panel, it failed with “TPM 2.0: Commands not being accepted because of a TPM failure.”








I did quite a bit of troubleshooting. The VM is running under Parallels Desktop 26.4 on macOS 26.6, and it’s a long-lived VM that has been migrated across several Apple Silicon Macs. The VM still boots and shuts down normally, has never prompted for the BitLocker recovery key, and Device Manager shows Trusted Platform Module 2.0 with no errors.

Executing the command manage-bde -status reports the drive is still 100% encrypted with Protection Off, while manage-bde -protectors -get C: successfully lists both the TPM protector and the recovery password protector, suggesting the BitLocker metadata is intact.

The TPM diagnostics are where things fail. Get-Tpm and tpmtool getdeviceinformation both return 0x80280095 (“TPM 2.0: Structure is wrong size”), while attempting to re-enable BitLocker from the command line with manage-bde -protectors -enable C: returns 0x80280101 (“TPM 2.0: Commands not being accepted because of a TPM failure”). Every operation that actually communicates with the TPM fails, while everything related to BitLocker metadata appears healthy. Normal operation on both VMs has not resulted in any errors or problems.

Based on the timing and the diagnostics, this looks less like BitLocker corruption and more like a TPM communication issue introduced with 26220.9022, possibly specific to virtual TPMs in Parallels. I’ve already submitted a detailed report through the Microsoft Feedback Hub. I’m curious whether anyone else running Insider builds in Parallels, Hyper-V, VMware, or other virtual environments has seen similar TPM errors after updating to this build.

Clearing your TPM may help resolved the problem.

Thanks @FreeBooter, that didn't work, it doesn't give me the option to clear it as it does not see it:




Yet Device Manager reports it's present with no errors, and even reports its settings were migrated from the prior OS version, and the TPM was started:



And Parallels sees the TPM 2.0 chip too:



So all and all it's very confused...

A "tmp failure" usually refers to a Trusted Platform Module (TPM) hardware or driver error on a computer.

Update your computer BIOS firmware from computer manufacturer support site.

@FreeBooter there is no BIOS firmware - this is a Parallels VM running on a Mac. everything is latest version (MacOS 26.6, Parallels 26.4.0, Windows 11 26220.9022 beta which is when it broke.

Update: I may have found a workaround that restores BitLocker protection, although it doesn’t appear to resolve the underlying TPM issue. I booted into Safe Mode using bcdedit /set {current} safeboot minimal. In Safe Mode, Get-Tpm still failed with the same 0x80280095 (“TPM 2.0: Structure is wrong size”) error, so there was no improvement in TPM communication. However, when I ran manage-bde -protectors -enable C:, it succeeded. Previously, this command had failed with 0x80280101 (“TPM 2.0: Commands not being accepted because of a TPM failure”).

After removing the Safe Mode setting (bcdedit /deletevalue {current} safeboot) and rebooting normally, the yellow BitLocker warning icon disappeared from the C: drive. manage-bde -status now reports Protection Status: Protection On, the drive remains 100% encrypted, and both the TPM and recovery key protectors are present. In other words, the BitLocker issue appears to be resolved.

Interestingly, the TPM management interface still appears to be broken. Even though BitLocker is now fully operational again, Get-Tpm continues to fail with 0x80280095 (“TPM 2.0: Structure is wrong size”), so whatever is causing the TPM API problem remains. At least in my case, Safe Mode seems to restore BitLocker protection without fixing the underlying TPM communication issue.

I repeated the exact same Safe Mode procedure on a second, completely independent Windows 11 Insider Beta VM running under Parallels Desktop on a different Mac (M4). It behaved identically. Since the same behavior occurs on two separate VMs on different Macs, this appears less likely to be VM-specific corruption and more likely to be a Windows Insider TPM regression or an interaction with Parallels’ virtual TPM implementation.

For reference, this is Windows 11 Insider Beta build 26220.9022 VM running under Parallels Desktop 26.4 on macOS 26.6. I also submitted a detailed bug report through the Feedback Hub. If anyone else running Insider builds in Parallels, Hyper-V, VMware, or another virtual environment is seeing the same issue, I’d be interested to know whether this Safe Mode workaround restores BitLocker for you as well.

That is weird indeed since you get mixed reports.

That might just be the case here: the guest OS is Beta. Parallels stable is tested against stable OSes usually. It happens on other hypervisors and other platforms as well.

If you don't have any blocking issues and all runs smoothly, you might just need to ride this one out till the next update.

I am glad you posted @Hopachi it reminded me to check this with 26220.9202 which came out yesterday! My results (I updated my MS Feedback too):

The TPM problem appears to be improved, although it is not completely fixed.

Get-Tpm still fails, but interestingly the error has changed. Instead of the previous 0x80280095 (“Structure is wrong size”), I now get:

A specified output buffer is too small. (Exception from HRESULT: 0x80284005)

On the other hand, tpmtool getdeviceinformation now runs successfully. It reports TPM Present: True, TPM Version: 2.0, Manufacturer ID: PRLS, Initialized: True, Ready For Storage: True, and BitLocker PCR7 Binding State: Bound.

BitLocker itself also looks completely normal. manage-bde -status reports the C: drive 100% encrypted, Protection Status On, and Lock Status Unlocked. manage-bde -protectors -get C: shows the TPM protector present and using PCR 7 and 11, along with the recovery-password protector.

Also, the yellow warning triangle that I previously saw on the C: drive is still not present.

So 26220.9202 appears to be a definite improvement. The TPM is being recognized and queried successfully by tpmtool, and BitLocker protection appears healthy. The remaining problem seems to be specifically with Get-Tpm/the PowerShell TPM interface, which now fails with 0x80284005 instead of the previous 0x80280095 error.