Windows 11 VM on Parallels has broken virtual TPM.

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.

 

Hello @ImraanN,

I too am experiencing the same/similar issues on my M2 MacBook Pro and this breaks Windows Hello on the recent Parallels version (Pro Edition, Version 26.4.0 (57513)). Much like @ChristopherB6, I see the TPM report the manufacturer name as SLRP.

Windows Defender's "Security processor details" claims "There is no TPM available. Please check your BIOS settings" (Device Manager shows "Trusted Platform Module 2.0" under "Security devices"). All Specification details on this screen is empty.

Running Get-TPM reports "Get-TPM : TPM 2.0: Structure is wrong size. (Exception from HRESULT: 0x80280095)".

Happy to provide additional details if useful.

Kind regards,

Andrew

 

If your Windows 11 VM in Parallels reports a broken virtual TPM (Trusted Platform Module), it usually means the virtual TPM data has become corrupted, its encryption keys no longer match, or the VM was moved/restored in a way that invalidated the TPM state.

 

I'm experiencing the same issue. Brokent TPM post windows update.

 

I'm also experiencing this issue on M3 MacBook Pro as per others on this thread.

 

I am also experiencing this problem. M1 Max MacBook Pro as per others in the thread.

 

Also having this issue, work stoppage for me.

 

On 26.4.0 installed Microsofts latest update today on Win 11 VM and it Broke TPM. Organization requires and if I don't meet requirements it forces logout in 10m.
Not good...not good at all.

 

Anyone getting responses from Parallels on this issue? Like others, I'm stuck...

 

I'm in the same boat after updating a couple updates from Windows today. I opened a support case and the chat bot replied back to check for Parallel updates that will resolve this issue.
This is my ticket id: 5773722

 

Quick update...I got hold of a Parallels tech on the phone, and this is what worked for *ME* (may not work for you):

Shut down the Win 11 VM
Remove the TPM chip in Parallels config for that VM
Restart Windows
Open Outlook...and suddenly I can "see" my emails from today (yay!!!)
Shut down the VM
Re-add the TPM chip
Restart the VM

Worked for me...I am back in action...hope it works for others.

 

That d

I did that but it still shows the TPM chip in the not ready state, so I have to authenticate with Smart Card or Yubikey for everything I do, I went the nuclear route and spun up a new VM on a different hypervisor.

 

That didn't work for me either.

 

TLDR; The MS update today was KB510650. Uninstalling the update got me back to working. But work will force it at some point.
After the update installed and I rebooted, it was like my work account lost contact with the VM. Had to reauthenticate which was not working correctly. Kept asking me for my PIN but it was failing. Rebooted a second time and got in and it readded my work account to VM, so it was like I was adding a new device. Kept getting Windows Hello errors and this machine does not meet work requirements. Turns out TPM failed, and of course could not enable encryption. Therefore BitLocker was turned off. Same thing after multiple reboots until I uninstalled the update.