Windows 11 VM on Parallels has broken virtual TPM. VM UUID: {40f22b78-fa73-4112-9312-509c3f17bc8f} Inside Windows: Get-Tpm returns: TPM 2.0: Structure is wrong size. HRESULT 0x80280095 tpm.msc crashes at: Microsoft.SnapIns.TrustedPlatformModule.TrustedPlatformModuleWmi.WmiGetLockoutHealTime TPM manufacturer shown as: SLRP Manufacturer version: 0.0.0.1 Specification version: Unknown Tried: - Remove/add TPM chip from VM hardware - Boot without TPM: Get-Tpm correctly shows TpmPresent False - Delete/regenerate System Keychain entry: Parallels.vTPM.{40f22b78-fa73-4112-9312-509c3f17bc8f} - New Keychain entry was created with timestamp 20260608143234Z - Move out NVRAM.dat and NVRAM.tnvs - NVRAM.dat and NVRAM.tnvs were regenerated with current timestamps - find inside .pvm shows only: NVRAM.dat NVRAM.tnvs - BitLocker Protection Off, Key Protectors None Found Problem persists: Get-Tpm still returns TPM 2.0: Structure is wrong size. Microsoft 365 desktop apps fail with: Device TPM problem / 0x80090030 Outlook Web works correctly.
I am also having the same issue, I wonder if there will be a fix anytime soon. I have tried all the above steps also. This happened after removing bitlocker, to allow the secure boot cert updates as prompted.
I just encountered the same issue. Performed the steps and now I am receiving the same error: "TPM 2.0: Structure is wrong size. (Exception from HRESULT: 0x80280095)"
Posting the above for visibility -- I've done significantly deeper diagnostics on this same failure and want to share findings that may help Parallels engineering identify the root cause. Environment: Apple Silicon MacBook (M5), Parallels Desktop 26.3.3 (57507), Windows 11 ARM64. Failure signature matches this thread exactly: Get-Tpm → 0x80280095 TPM 2.0: Structure is wrong size tpmtool getdeviceinformation → fails with same error Win32_Tpm → ManufacturerIdTxt: SLRP, SpecVersion: Not Supported M365 desktop apps → 0x80090030, Outlook Web works fine All standard workarounds attempted and failed: Reinstalled both 26.3.2 (57398) and 26.3.3 (57507) Deleted and recreated NVRAM files Copied known-good NVRAM from a working backup -- no change Cloned VM to a fresh UUID with a brand new vTPM Keychain item -- no change Cleared TPM from VM firmware (TCG2 setup) -- no change Deleted Windows TPM WMI and ProvisionInfo registry keys -- Windows re-read SLRP from the vTPM emulator at next boot, confirming this is a live emulator issue, not stale registry cache BitLocker was fully off before any of the above Key finding -- Keychain comparison between working and broken Mac: I have an older backup copy of the same VM from an M1 Mac where the TPM works correctly (tpmtool succeeds, ManufacturerIdTxt: PRLS, SpecVersion: 2.0, 0, 1.16). I compared the Parallels.vTPM.{UUID} Keychain item between both machines using security find-generic-password. The password hash, creation timestamp, and modification timestamp are byte-for-byte identical on both machines. The Keychain item is not the variable. Key finding -- brand new VM also fails: A freshly created VM on this Mac also fails TPM queries with 0x80284005 (output buffer too small). This confirms the issue is not specific to migrated or cert-updated VMs -- the vTPM emulator itself is broken on this host. Key finding -- byte order reversal: The SLRP manufacturer string is PRLS with its bytes reversed. In hex: PRLS = 0x50524C53 (big-endian), SLRP = 0x534C5250 (little-endian). The vTPM emulator appears to be returning TPM2_PT_MANUFACTURER in native little-endian byte order instead of the big-endian format the TPM 2.0 spec requires. This causes Windows tpm.sys to parse the capability response structure as malformed, which cascades into the Structure is wrong size error and SpecVersion: Not Supported. Conclusion: Every accessible persistent state variable (config, NVRAM, Keychain, VM UUID, Windows registry cache) has been ruled out. The ACPI layer correctly exposes PRLS0000 on all affected machines. The failure is in the Parallels vTPM emulator binary itself -- specifically in how it serializes TPM2 capability response structures, likely a regression introduced in 26.3.3 (57507) that may be specific to M5 Apple Silicon or the new Secure Boot cert update code path. Ask for Parallels engineering: Can you confirm whether a hidden vTPM state file exists beyond config.pvs, NVRAM, and the Keychain item? And is there an ETA for a hotfix that addresses the SLRP byte-order regression? Happy to share full diagnostic output if it helps.
