Windows 11 VM cannot read its virtual disk after upgrading to macOS 27 (BlockIo read error at sector 0)

[ParallelsU1615]

Subject: Windows 11 VM cannot read its virtual disk after upgrading to macOS 27 (BlockIo read error at sector 0)

SUMMARY
After upgrading macOS from 26.6.2 to macOS 27 on 23 September 2026, my Windows 11 (ARM) VM no longer boots. The VM starts and reaches the UEFI firmware, but it cannot read anything from its virtual hard disk. The disk file itself appears intact.

ENVIRONMENT
- Mac: Apple Silicon
- macOS: 27 (upgraded from 26.6.2 on 23 Sep 2026)
- Parallels Desktop: 27.0.1 (58670)
- VM: Windows 11 ARM, 8192 MB RAM, UEFI, TPM chip present (TPM data encrypted, password in macOS Keychain)
- VM location: ~/Parallels/Windows 11.pvm (internal drive, not iCloud or external storage)
- VM encryption: off

TIMELINE
- 23 Sep, 21:33: last write to the .hds data file
- 23 Sep, approx. 22:00: macOS upgrade finished and Mac restarted (last console login 22:01). The VM was likely running or being suspended when the upgrade started.
- 24 Sep, morning: VM no longer boots

SYMPTOMS
1. On start, the VM goes straight to the UEFI firmware setup screen instead of booting Windows.
2. Boot Manager lists "Windows Boot Manager" (HD(2,GPT,2146506A-C32E-4F4B-A578-892922367440,0x96800,0x96000)/\EFI\Microsoft\Boot\bootmgfw.efi) and "UEFI Shell". Selecting Windows Boot Manager flashes and returns to the menu.
3. In the UEFI Shell, the mapping table shows only BLK0 (the SATA disk) and BLK1. There are no partition BLK entries and no FS0. "map -r" gives the same result.
4. "dblk blk0 0 1" returns: dblk: Read file error - 'BlockIo'. The VM cannot read even sector 0 of its disk.

TROUBLESHOOTING DONE
- Disabled Secure Boot with the boot flag vm.efi.secureboot=0 (per KB 131131). The firmware confirms Secure Boot is disabled, but the problem persists, so Secure Boot is not the cause. The TPM chip has NOT been removed.
- "Select boot device on startup" was found ticked in Boot Order. This explains why the firmware menu appears, but not the read failure.
- Verified the disk package ~/Parallels/Windows 11.pvm/harddisk.hdd contains:
- DiskDescriptor.xml (rewritten 24 Sep 09:13) and DiskDescriptor.xml.Backup (24 Sep 09:09). These are identical (diff shows no difference).
- harddisk.hdd (0 bytes)
- harddisk.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds, 79,602,647,040 bytes, last modified 23 Sep 21:33
- harddisk.hdd.drh (22 Sep 18:08)
- The DiskDescriptor.xml GUID and File entries match the .hds filename. ParentGUID is all zeros (no snapshot chain).
- The .hds header is intact: it starts with the "WithoutFreeSpace" signature and describes a 256 GB virtual disk. The 4 bytes at offset 0x2C read "pd17". Please check whether this indicates the image was not closed cleanly.
- Permissions: my user has Read & Write, file not locked. The only extended attribute is com.apple.provenance (no quarantine).
- In the VM folder, the {e8b4bac2-...}.mem file is 0 bytes and the .mem.sh file is 67.1 MB, suggesting an interrupted suspend during the macOS upgrade.
- parallels.log shows no disk-related errors. Only OpenGL, BattWatcher and MonitorArm messages, plus "[AHCI: ] [SATA0] controller reset" at each start.

REQUEST
Please help me get the VM to read its disk again without losing data. I have a backup copy of the .pvm.

 

[NyitraiZ]

Hi, i had the same issue. Here is how i fixed it:
# Recovering a Windows 11 VM in Parallels Desktop on Apple Silicon

## Environment

- Apple Mac with M3 Pro
- Parallels Desktop 27
- Windows 11 ARM
- BitLocker enabled
- Existing Windows installation contained important applications and
files

## Problem

The existing Windows 11 virtual machine stopped booting and opened the
UEFI Boot Manager instead.

`Windows Boot Manager` was visible, but selecting it immediately
returned to the Boot Manager.

The goal was to recover the **existing Windows installation with all
applications, settings, and files intact**, rather than reinstall
Windows.

------------------------------------------------------------------------

## Solution Overview

The Windows virtual disk itself was healthy. The problem was associated
with the original Parallels VM configuration/virtual hardware.

The successful solution was to:

1. Create a fresh Windows 11 ARM VM.
2. Attach the original Windows virtual disk to it.
3. Unlock the old disk using the BitLocker recovery key.
4. Repair its EFI boot files.
5. Use the fresh VM configuration to boot the original Windows disk.
6. Remove the temporary fresh Windows disk.
7. Rebind BitLocker to the new virtual TPM.

This preserved the original Windows installation, applications,
settings, and files.

------------------------------------------------------------------------

## 1. Preserve the Original VM

Before making changes, create a complete Finder copy of the original:

`Windows 11.pvm`

Keep this backup untouched during recovery.

------------------------------------------------------------------------

## 2. Verify the Original Virtual Disk

The original Windows disk was located inside the original `.pvm`
package:

`Windows 11-0.hdd`

Verify the disk using Parallels' command-line tool:

``` bash
prl_disk_tool check --hdd "/Users/<username>/Parallels/Windows 11.pvm/Windows 11-0.hdd"
```

A successful result finishes with:

``` text
Operation progress 100 %
```

with no disk errors.

------------------------------------------------------------------------

## 3. Create a Fresh Windows 11 ARM VM

Create a new Windows 11 VM using Parallels:

**File → New → Get Windows 11 from Microsoft**

Allow Parallels to install Windows 11 ARM normally.

Confirm that the new VM boots successfully.

This provides a known-good Parallels VM configuration, UEFI environment,
and virtual TPM.

------------------------------------------------------------------------

## 4. Attach the Original Windows Disk as a Secondary Disk

Shut down the new VM.

Open:

**Configure → Hardware → + → Hard Disk → Existing image file**

Select the original:

`Windows 11.pvm/Windows 11-0.hdd`

Start the new Windows VM.

The old disk should now appear in **Disk Management** as an additional
disk containing:

- EFI System Partition
- BitLocker-encrypted Windows partition
- Recovery partition(s)

Do **not** initialize or format the disk.

------------------------------------------------------------------------

## 5. Unlock the Original Windows Partition

Open **Command Prompt as Administrator**.

Check the volumes:

``` cmd
manage-bde -status
```

Assuming the old Windows partition appears as `F:`, unlock it using the
existing 48-digit BitLocker recovery key:

``` cmd
manage-bde -unlock F: -RecoveryPassword YOUR-48-DIGIT-RECOVERY-KEY
```

Verify the Windows installation:

``` cmd
dir F:\Windows
```

The original Windows directory should be accessible.

------------------------------------------------------------------------

## 6. Rebuild the EFI Boot Files

Open an Administrator Command Prompt:

``` cmd
diskpart
```

Identify the old disk:

``` cmd
list disk
select disk 1
list partition
```

Identify the small **System / EFI partition** on the old disk.

For example, if it is Partition 2:

``` cmd
select partition 2
assign letter=S
exit
```

Verify it:

``` cmd
dir S:\EFI
```

Then rebuild the Windows boot files:

``` cmd
bcdboot F:\Windows /s S: /f UEFI
```

The expected result is:

``` text
Boot files successfully created.
```

Shut down Windows.

------------------------------------------------------------------------

## 7. Boot the Original Disk Using the Fresh VM Configuration

Use the fresh, working VM configuration and attach the recovered
original Windows disk as a boot disk.

The working configuration used:

`IDE 0:0`

Keep the fresh VM's:

- UEFI configuration
- Secure Boot configuration
- TPM chip
- other virtual hardware configuration

Start the VM from the **original Windows disk**.

Because the disk was previously associated with another virtual TPM,
Windows should display the **BitLocker Recovery** screen.

Enter the existing 48-digit recovery key.

Windows should now boot into the **original installation**, including
the original:

- applications
- user profile
- files
- Windows configuration
- application settings

Allow **Parallels Tools** to update if prompted.

------------------------------------------------------------------------

## 8. Remove the Temporary Fresh Windows Disk

Once the original Windows installation successfully boots using the new
VM configuration, shut Windows down.

In:

**Parallels → Configure → Hardware**

remove the temporary fresh Windows disk from the VM.

Choose:

**Remove from virtual machine / Keep file**

Do **not** delete it yet.

Leave only the recovered original Windows disk attached.

Confirm that it remains at:

`IDE 0:0`

Also keep:

- TPM enabled
- Secure Boot enabled
- Hard Disk first in Boot Order

Boot Windows again using the BitLocker recovery key if requested.

------------------------------------------------------------------------

## 9. Prepare BitLocker for the New Virtual TPM

Check BitLocker:

``` cmd
manage-bde -status C:
```

The disk should still be:

- 100% encrypted
- unlocked
- protected by a Numerical Password / recovery key

Temporarily suspend BitLocker:

``` cmd
manage-bde -protectors -disable C:
```

Restart Windows once:

``` cmd
shutdown /r /t 0
```

This allows Windows and the new virtual TPM to establish a clean
measured-boot state using the final single-disk VM configuration.

------------------------------------------------------------------------

## 10. Verify TPM and PCR7 Binding

After Windows starts, open an Administrator Command Prompt:

``` cmd
tpmtool getdeviceinformation
```

Verify:

``` text
TPM Present: True
TPM Version: 2.0
Is Initialized: True
Ready For Storage: True
Bitlocker PCR7 Binding State: Binding Possible
```

The important result is:

``` text
Bitlocker PCR7 Binding State: Binding Possible
```

------------------------------------------------------------------------

## 11. Create a New TPM Protector

The old TPM protector belonged to the previous VM's virtual TPM.

Keep the existing **Numerical Password** recovery protector, but create
a TPM protector associated with the new VM.

Add the TPM protector:

``` cmd
manage-bde -protectors -add C: -TPM
```

Verify:

``` cmd
manage-bde -protectors -get C:
```

The drive should now have:

``` text
TPM
Numerical Password
```

The Numerical Password should be retained as the emergency BitLocker
recovery mechanism.

------------------------------------------------------------------------

## 12. Re-enable BitLocker

Enable the protectors:

``` cmd
manage-bde -protectors -enable C:
```

Verify:

``` cmd
manage-bde -status C:
```

The expected state is:

``` text
Protection Status: Protection On
Lock Status: Unlocked
```

Restart Windows:

``` cmd
shutdown /r /t 0
```

Windows should now boot normally **without requesting the BitLocker
recovery key**.

------------------------------------------------------------------------

# Final Result

The original Windows 11 installation was recovered without reinstalling
Windows.

The final configuration consists of:

- Fresh Parallels VM configuration
- Original Windows virtual disk
- Original Windows installation
- Original applications and files
- Secure Boot enabled
- New virtual TPM
- BitLocker rebound to the new TPM
- Existing BitLocker Numerical Password retained as recovery
protection

The original broken `.pvm` and its backup should be retained temporarily
until the recovered VM has been tested thoroughly.

Once the recovered VM has been stable for several days, create a **new
backup of the working `.pvm`** before deleting the old VM or any unused
virtual disks.