Windows 11 VM on Parallels has broken virtual TPM.

Same for me, Uninstalling KB510650 will bring back up and running TPM. All work security features are back and working (PIN, BL, VPN, etc.).
I guess we need a Hotfix from Parallels for that...
 
Also experiencing this issue both on a personal VM and a work one. Personal I managed to reset my PIN ok on boot when prompted but started getting some authentication issues with some applications. Work enrolled VM was exactly the same as others have reported. Rolling back KB510650 temporarily 'fixed' this, but there are of course a lot of security components to that update that I'd like applied to my machine. Hopeful that Parallels will issue a fix soon. Doesn't appear to affect other VMs on different hardware/platforms or windows running on bare metal.
 
HenriH said:
I can also confirm that uninstalling KB510650 resolves the TPM issue. However I don not think the update is the actual root cause of the problem.
What I see happening when the update is installed is that the TPM Manufacturer Name changes from PLRS to SRLP. For me this points to a Parallels issue that could be fixed with an update.
Click to expand...

This is what I see pre and post:

With KB installed:
- Get-Tpm: 0x80280095, structure is wrong size
- tpm.msc crashed
- Manufacturer: SLRP
- Specification: Unknown
- Microsoft 365 TPM authentication failed

After KB uninstall:
- Microsoft 365 authentication works
- tpm.msc: TPM ready for use
- Manufacturer: PRLS
- Specification: 2.0
- tpmtool and Win32_Tpm return valid information
- Get-Tpm alone still returns 0x80284005 (Get-Tpm : A specified output buffer is too small. (Exception from HRESULT: 0x80284005))
 
I can also confirm that uninstalling KB5101650 resolves the TPM issue, and I'm able to authenticate, although Get-Tpm keeps reporting the error "A specified output buffer is too small. (0x80284005)"

I've paused the automatic updates as much as possible, so hopefully Parallels will release a fix for this issue.
 
I'm seeing what appears to be the exact same issue on a different environment.

Host
  • MacBook Pro (M4 Pro)
  • macOS Tahoe 26.5.1
  • Parallels Desktop 26.4.0 (57513)
Guest
  • Windows 11 ARM
  • Parallels Tools 26.4.0.57513
Symptoms
  • Get-Tpm returns: TPM 2.0: Structure is wrong size. (0x80280095)
  • tpmtool getdeviceinformation returns the same error (0x80280095)
  • Win32_Tpm reports:
    • ManufacturerIdTxt : SLRP
    • SpecVersion : Not Supported
  • Company Portal reports a TPM failure.
  • dsregcmd /status shows:
    • AzureAdJoined : YES
    • AzureAdPrt : YES
    • DeviceAuthStatus : FAILED
  • Browser authentication (Edge/Microsoft 365) works normally.
  • Native Microsoft apps (OneDrive, Office, etc.) fail to authenticate because device-backed authentication is unavailable.
Already tried
  • Rebooting multiple times.
  • Reinstalling Parallels Tools (same version as Desktop).
  • Confirmed the virtual TPM is enabled.
  • Removing Zscaler (not related).
This appears to be a TPM API failure rather than an application-specific issue.

Can someone from Parallels Engineering confirm whether this is being tracked under an internal bug, and whether there is a fix planned for a future build? If so, is there a case number or ETA that affected users can reference?
 
Same situation.
- M2 Max MacBook Pro, macOS 26.5.2 (25F84), Parallels Desktop 26.4.0 (57513)
- Also reproduced by a colleague on M3 Max, same Parallels build

Guest is Windows 11 ARM64, build 26200.8875 after KB5101650. Symptoms match this thread exactly: Get-Tpm → 0x80280095 ("structure is wrong size"), BitLocker auto-suspended, Windows Hello no longer works, and M365 desktop apps fail with 0x80090030. Fortunately, I could still access the system via YubiKey.

Confirmed the root-cause tell noted above: the registry TPM manufacturer decodes to SLRP (0x534C5250), which is PRLS with its bytes reversed -- consistent with the vTPM emulator returning TPM2_PT_MANUFACTURER in little-endian instead of the big-endian the TPM 2.0 spec requires.

Rolling Parallels back to a pre-57507 build restores the TPM; uninstalling KB5101650 also works but isn't viable on MDM-managed machines that re-push the update. A signed hotfix would be hugely appreciated -- is there any ETA?
 
Same issue on Macbook M5 Pro.
After uninstall KB5101650, TPM is recognised and working back.
Even if:
Get-Tpm returns:
Get-Tpm : La taille d'un tampon de sortie spécifié est insuffisante. (Exception de HRESULT : 0x80284005) Au caractère Ligne:1 : 1 + Get-Tpm + ~~~~~~~ + CategoryInfo : NotSpecified: (:) [Get-Tpm], TpmWmiException + FullyQualifiedErrorId : Microsoft.Tpm.Commands.TpmWmiException,Microsoft.Tpm.Commands.GetTpmCommand

Please, Parallel PG team, fix this issue with KB5101650 asap.
 
Same issue here, M4 MacBook Pro's, all latest versions of macOS, Parallels and Windows 11. All our company VM's are MDM mananged and uninstalling a security update is against company policy. So basically we cannot access any work rescources using our VM's. We need an ETA on a possible fix or any update.
 
I have uninstalled KB5101650, but sadly the issue still exists. I have not tried rolling back the version, and might try to do that. A true fix would be good to have, though!
 
Are we sure that this is a Parallels bug? The problem started with a Windows update and ends when that update is uninstalled. It seems more likely to me that Windows is not reading the TPM properly.

With that in mind, I booted my VM to an Ubuntu ISO and took a look at /sys/class/tpm/tpm0/device/modalias and see that that returns the following: acpi:PRLS0000:MSFT0101:. That suggests to me that the byte order is correct in the firmware. That said, I am no TPM expert, so maybe my approach is flawed...
 
Correction to the above, the site converted two characters into an emoji after I hit 'Post Reply'. What cat /sys/class/tpm/tpm0/device/modalias returned was acpi: PRLS0000:MSFT0101:, except without the space between 'acpi:' and 'PRLS000'.
 
Ok, I was able to revert back to the previous version of parallels, get the TPM working again. I updated parallels, still good. (Each time taking a snapshot), updated windows and then it broke. I reverted back to the snapshot, and all good. Updates are paused for now.

It is possible windows changed how it reads the TPM, but still the emulation layer has to present the right data for the read. And if this has not broken TPM reads everywhere (which if it had, MS would have released a Hotfix by now as everywhere would be broken), this leaves it up to Parallels to fix how they present the TPM to the O/S.
 
ChristianP27 said:
Correction to the above, the site converted two characters into an emoji after I hit 'Post Reply'. What cat /sys/class/tpm/tpm0/device/modalias returned was acpi: PRLS0000:MSFT0101:, except without the space between 'acpi:' and 'PRLS000'.
Click to expand...
someone reverted the Parallels version and the issue also went away and no one seems to be reporting the issue in native windows 11 with the update applied that i have seen.
 
I need to correct my earlier conclusion that rolling Parallels back to a pre-57507 build restores the TPM - do not want to send anyone down the Parallels downgrade path.

I reproduced the failure on the same VM across these versions:

Parallels Desktop version TPM2/SSDT comparison
26.0.0 / 57238 Byte-identical
26.3.2 / 57398 Byte-identical
26.4.0 / 57513 Byte-identical
The captured TPM2 and SSDT data remained unchanged across all three tested versions. Windows failed identically on each version while KB5101650 was installed.

Environment and symptoms
  • Windows 11 25H2 ARM64
  • KB5101650
  • OS build 26200.8875
  • Parallels ARM VM
Observed symptoms:
  • Get-Tpm and tpmtool fail with: 0x80280095 - TPM 2.0: Structure is wrong size
  • tpm.msc crashes or unloads
  • Windows Hello and BitLocker functionality is disrupted
  • Windows logs TPM command and initialization failures, including events 17 and 27
Linux validation
I booted the affected VM into an Ubuntu live environment on every tested Parallels version. Linux successfully queried the same vTPM each time:
  • Manufacturer correctly reported as PRLS
  • The TPM was operational
  • The responses observed under Linux were correctly framed
  • There was no indication under Linux that the stored vTPM state was corrupted
I also installed KB5101650 on a physical Windows ARM64 device. Its TPM remained queryable through Get-Tpm after installation. This suggests the problem is not a universal failure of TPM support on Windows ARM64, although that comparison does not exercise the Parallels virtual TPM path.

Results
  • Parallels 26.0.0 / 57238 with KB installed: fails
  • Parallels 26.3.2 / 57398 with KB installed: fails
  • Parallels 26.4.0 / 57513 with KB installed: fails
  • Uninstalling KB5101650: restores TPM functionality
  • Installing KB5101650 again: returns the failure
Across all three tested Parallels versions, the failure occurred only while KB5101650 was installed, and uninstalling the KB restored TPM functionality.
Seems to establish KB5101650 as the trigger for an incompatibility between Windows and the Parallels vTPM path. It does not yet establish whether Microsoft or Parallels must provide the compatibility fix.

For now, the practical workaround is to uninstall KB5101650 and pause quality updates. Downgrading to the tested Parallels versions did not help, so I have returned to Parallels 26.4.0 / 57513.
 
JeffA13 said:
I need to correct my earlier conclusion that rolling Parallels back to a pre-57507 build restores the TPM - do not want to send anyone down the Parallels downgrade path.

I reproduced the failure on the same VM across these versions:

Parallels Desktop version TPM2/SSDT comparison
26.0.0 / 57238 Byte-identical
26.3.2 / 57398 Byte-identical
26.4.0 / 57513 Byte-identical
The captured TPM2 and SSDT data remained unchanged across all three tested versions. Windows failed identically on each version while KB5101650 was installed.

Environment and symptoms
  • Windows 11 25H2 ARM64
  • KB5101650
  • OS build 26200.8875
  • Parallels ARM VM
Observed symptoms:
  • Get-Tpm and tpmtool fail with: 0x80280095 - TPM 2.0: Structure is wrong size
  • tpm.msc crashes or unloads
  • Windows Hello and BitLocker functionality is disrupted
  • Windows logs TPM command and initialization failures, including events 17 and 27
Linux validation
I booted the affected VM into an Ubuntu live environment on every tested Parallels version. Linux successfully queried the same vTPM each time:
  • Manufacturer correctly reported as PRLS
  • The TPM was operational
  • The responses observed under Linux were correctly framed
  • There was no indication under Linux that the stored vTPM state was corrupted
I also installed KB5101650 on a physical Windows ARM64 device. Its TPM remained queryable through Get-Tpm after installation. This suggests the problem is not a universal failure of TPM support on Windows ARM64, although that comparison does not exercise the Parallels virtual TPM path.

Results
  • Parallels 26.0.0 / 57238 with KB installed: fails
  • Parallels 26.3.2 / 57398 with KB installed: fails
  • Parallels 26.4.0 / 57513 with KB installed: fails
  • Uninstalling KB5101650: restores TPM functionality
  • Installing KB5101650 again: returns the failure
Across all three tested Parallels versions, the failure occurred only while KB5101650 was installed, and uninstalling the KB restored TPM functionality.
Seems to establish KB5101650 as the trigger for an incompatibility between Windows and the Parallels vTPM path. It does not yet establish whether Microsoft or Parallels must provide the compatibility fix.

For now, the practical workaround is to uninstall KB5101650 and pause quality updates. Downgrading to the tested Parallels versions did not help, so I have returned to Parallels 26.4.0 / 57513.
Click to expand...

Awesome, thanks for this thorough testing. Now we just need a fix... :)
 
The KB5101650 update contains a bug that also occurs on standalone (DELL) computers, among other things. This is not a Parallels problem, but a bug in KB5101650 that causes hardware and software to be suddenly accessed differently, resulting in a TPM error. On DELL computers is strickly advice don't install this update, it result in TPM problems,
 
I am also having the same issue.

I work off the VM on a day-to-day basis.

I have tried the same fixes as mentioned earlier and still get the TPM size error.

I tried a fresh VM multiple times but kept encountering issues.

Ended up setting a test machine on VMware, and I'm not having the same issue even with KB5101650 installed.
 
KB5101650 - breaks my Install too on Parallels - PIN does not work after reboot.
After reverting the update - I am able to use the PIN feature - and do not get the error code "0x80280101".

I suspect this is a problem for Parallels and some DELL hardware.
 
You must log in or register to reply here.
Back
Top