Windows 11 VM on Parallels has broken virtual TPM.

Is any of this related to me getting a bitlocker error.? I've been unable to launch parallels win11 for over a month. Does Parallel store the bitlocker key somewhere?
 
Adding my case here as it may help narrow down the trigger — my symptoms match
this thread exactly, but the triggering KB is different from KB5101650, which
suggests this isn't tied to a single update but to a broader regression pattern.

ENVIRONMENT
- Parallels Desktop 26 (latest available)
- Intel Mac: MacBook Pro, i9-9980HK, 32GB RAM
- Windows 11 Enterprise, version 25H2 (build 26200)
- VM: UEFI firmware, Secure Boot enabled, TPM Chip 2.0 added

SYMPTOMS (identical to the rest of this thread)
Get-CimInstance -Namespace "root\CIMV2\Security\MicrosoftTpm" -ClassName Win32_Tpm
| Select-Object ManufacturerIdTxt, SpecVersion
→ ManufacturerIdTxt: SLRP (should be PRLS)
→ SpecVersion: Not Supported

Get-Tpm → "TPM 2.0: Structure is wrong size." (0x80280095)
tpmtool getdeviceinformation → same 0x80280095
tpm.msc → "Compatible TPM cannot be found"
Device Manager → TPM device shows up only under Hidden Devices after reset attempts
VBS reports: SecurityServicesConfigured {Credential Guard, HVCI},
SecurityServicesRunning {} — configured but never running
DMA Protection stays Off regardless

TRIGGERING UPDATE (my case)
KB5129195 (Security Update, installed 9/17/2026). NOT KB5101650.

REPRODUCTION (confirmed deterministic across two independent Windows installs)
1. Clean Windows 11 install, TPM Chip added in VM config
→ ManufacturerIdTxt: PRLS, SpecVersion: 2.0, 0, 1.16 (correct)
2. Let Windows Update install the latest cumulative (KB5129195 in my case)
3. Full VM power cycle (Stop/Start, not just Windows restart)
→ ManufacturerIdTxt: SLRP, SpecVersion: Not Supported (broken)
4. wusa /uninstall /kb:5129195, full VM power cycle
→ back to PRLS, correct SpecVersion

This cycle is 100% repeatable. I ran it twice on two separate clean installs
with identical results both times.

WHAT I RULED OUT (so this isn't just stale state)
- Deleted Parallels.vTPM.{UUID} from both System and iCloud Keychain,
recreated TPM Chip device → no change, still SLRP with the KB installed
- Deleted NVRAM.dat, NVRAM.tnvs, and NVRAM.tnvs.old from the .pvm bundle,
let Parallels regenerate them → no change
- Deleted HKLM\SYSTEM\CurrentControlSet\Services\TPM\{ProvisionInfo,WMI,Enum}
and let Windows re-provision from scratch on a full VM restart → registry
values regenerated identically (TaskManufacturerId: 1397510736 / SLRP again)

Since a fully wiped state still reproduces SLRP the moment that specific KB
is present, this points to the emulator binary itself mishandling something
in the TPM2_PT_MANUFACTURER response (byte order, as already noted upthread —
PRLS reversed is SLRP) under whatever code path that KB's cumulative changes
trigger in the guest's TBS stack.

IMPACT
This blocks Secure Boot/TPM/VBS compliance entirely for any org that requires
current cumulative updates as a compliance baseline — updating to stay compliant
breaks the TPM, staying on an older build to keep TPM working fails the baseline
check. No way to satisfy both from the VM side.

Happy to share full diagnostic logs (WindowsUpdateLog, registry exports,
Get-CimInstance output) if useful for triage. Would also appreciate confirmation
whether this is tracked as the same root cause as the KB5101650 reports above,
or a separate regression.
 
You must log in or register to reply here.
Back
Top