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'm having the same issue immediately after rebooting the Windows 11 guest for Patch Tuesday today. Get-Tpm says the same "Structure is wrong size" error. tpm.msc says the TPM is locked. My PIN didn't work upon reboot; after suspending BitLocker, my PIN works once on first boot. This completely breaks my ability to get work done.

 

I am having this same issue. Very frustrating. Hope is fixed soon.

 

I am also seeing this behavior. It was working with the June Windows 11 update (Build 26200.8655) but then broke with the July Windows 11 update (Build 26200.8875). Uninstalling the July update restores TPM functionality on this VM.

Note that this machine is an Intel-based 2019 Mac Pro, not an Apple Silicon based Mac like most or all of the other reports on this thread. Here is some info that may help:

System Details

• Model: 2019 Mac Pro
• MacOS: macOS Tahoe v26.5.2

Software Details

• Parallels Version: 26.4.0 (57513)
• Windows 11 update that broke TPM: 2026-07 Security Update (KB5101650) (26200.8875)
• Latest Windows 11 update where TPM is still working: 2026-06 Security Update (KB5094126) (26200.8655)

 

Quick update: Uninstalling the July update successfully restored Windows Hello and BitLocker functionality, but querying the TPM via PowerShell still returns an error. However, the error is different after the rollback:

• Before rollback: Get-Tpm: TPM 2.0: Structure is wrong size. (0x80280095)
• After rollback: Get-Tpm: A specified output buffer is too small. (0x80284005)

 

Additional update: Looking at Event Viewer in Windows, I see the following error that was logged shortly after the post-update reboot: "Pre-attestation health checks confirm a critical component has failed, and the device is not expected to pass attestation. Please see C:\Windows\Logs\MeasuredBoot\0000000158-0000000000.json for detailed information on what checks were made."

12 seconds later the System Event Log begin being flooded up with continuous TPM errors: "The initialization of the Trusted Platform Module (TPM) failed. The TPM may be in failure mode. To allow diagnosis, contact the TPM manufacturer with the attached information"

Here is the contents of that C:\Windows\Logs\MeasuredBoot\0000000158-0000000000.json file:
{"Version":2,"HealthStatus":"Cannot be attested","Required":[{"Field":"TpmPresent","Value":true,"DesiredValue":true},{"Field":"TpmMeetsMinimumVersion","Value":true,"DesiredValue":true},{"Field":"TpmIsResponsive","Value":true,"DesiredValue":true},{"Field":"EkCertIsAvailable","Value":false,"DesiredValue":true},{"Field":"TcgLogFound","Value":true,"DesiredValue":true}],"Expected":[{"Field":"PcrsMatchTcgLog","Value":true,"DesiredValue":true}],"Informational":[{"Field":"SecureBootEnabled","ValueFromComputer":true,"ValueFromTcgLog":true,"DesiredValue":true,"TcgValueIsVerifiable":true},{"Field":"VirtualSecureMemory","ValueFromComputer":false,"ValueFromTcgLog":false,"DesiredValue":true,"TcgValueIsVerifiable":true},{"Field":"SecureCorePCCompliant","ValueFromComputer":false,"ValueFromTcgLog":false,"DesiredValue":true,"TcgValueIsVerifiable":true},{"Field":"MostRecentBootTcgLogFoundInFileSystem","Value":true,"DesiredValue":true},{"Field":"CurrentTcgLogFoundInFileSystem","Value":true,"DesiredValue":true},{"Field":"EkCertRsa2048IsAvailable","Value":false,"DesiredValue":true},{"Field":"EkCertEccP256IsAvailable","Value":false,"DesiredValue":true},{"Field":"EkCertEccP384IsAvailable","Value":false,"DesiredValue":true},{"Field":"WindowsAikCertRsa2048IsAvailable","Value":false,"DesiredValue":true},{"Field":"WindowsAikCertEccP256IsAvailable","Value":false,"DesiredValue":true},{"Field":"WindowsAikCertEccP384IsAvailable","Value":false,"DesiredValue":true}]}

 

I'm also experiencing the same issue. Broken TPM post July Windows Update on 2 VMs.

 

Hi everybody..
Same exact issue.

 

Hi, I am experiencing the same thing. What is the fix please?

 

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