Azure VM won't boot: missing disk encryption key in Key Vault

Quick answer for advanced users

Use the Azure CLI to create a new VM with the OS disk attached as a data disk, mount it, edit the registry to add the missing BitLocker key protector, then re-create the VM. If the key is simply missing from the vault, re-upload it.

Why this happens

Azure Disk Encryption uses BitLocker on Windows VMs (or DM-Crypt on Linux) and stores the encryption keys in your Azure Key Vault. If that key gets deleted—maybe someone cleaned up the vault, a policy expired, or a backup restore didn't include the vault—the VM can't decrypt the boot volume on next startup. You'll see a boot loop, a recovery screen asking for the BitLocker recovery key, or a blue screen with error 0xC0000001. The VM won't come up online, and boot diagnostics will show it stuck at "Getting Windows ready" or a black screen.

I've seen this most often after a failed Key Vault soft-delete recovery or when someone accidentally purges a key believing it's no longer needed. It's also common in automated deployment pipelines where the vault gets recreated but the key isn't migrated.

Step-by-step fix

1. Stop the broken VM. In the Azure portal, go to your VM, click Stop, and wait until it shows as Stopped (deallocated).
2. Copy the OS disk. In the portal, open the VM's disks, find the OS disk, and click Create snapshot. Name it something like broken-os-disk-snap. Once the snapshot is ready (usually 2-3 minutes), click on it and select Create disk. Use the same region and resource group as the original VM.
3. Create a repair VM. Deploy a new Windows VM (same size, same region) using a standard image. I usually pick Windows Server 2019 Datacenter. Keep it simple—no extra disks needed.
4. Attach the copied disk to the repair VM. In the repair VM's Disks blade, click Attach existing disks. Select the disk you created from the snapshot. After attaching, you should see it under the repair VM's disks with LUN 0.
5. Connect to the repair VM via RDP. Open Remote Desktop, log in with the admin credentials you set during deployment. Inside the VM, open Disk Management (right-click Start, choose Disk Management). You should see the attached disk as offline. Right-click the disk (usually Disk 1) and choose Online. It will show a healthy partition.
6. Check the registry for encryption status. Open Regedit. Select the HKEY_LOCAL_MACHINE hive, then click File > Load Hive. Browse to the attached OS disk's Windows\System32\config\SYSTEM file. Name the hive BROKEN. Navigate to HKEY_LOCAL_MACHINE\BROKEN\ControlSet001\Services\DiskEncryption. If this key exists, the disk was encrypted. If not, the issue might be something else—check boot logs instead.
7. Inject the missing key. You need the BitLocker recovery key. Go to the Azure portal, open the Key Vault, find the secret with the VM's name, and copy the recovery key (it's a 48-digit number). Back on the repair VM, open an elevated command prompt and run:

   manage-bde -unlock E: -RecoveryPassword YOUR-48-DIGIT-KEY

   Replace E: with the drive letter of the attached OS disk (usually D: or E:). If this succeeds, run:

   manage-bde -protectors -get E:

   You'll see the existing key protectors. If the Key Vault key protector is missing (you'll see only a TPM protector), you need to add it:

   manage-bde -protectors -add E: -TPM

   This re-adds the TPM protector so the VM can boot without the recovery key. Optionally, you can also re-add the Key Vault protector using manage-bde -protectors -add E: -RecoveryPassword and then upload that password back to the vault.
8. Unload the hive. In Regedit, select the BROKEN hive and click File > Unload Hive. This writes changes back to the SYSTEM file.
9. Detach and recreate the VM. In the Azure portal, stop the repair VM, detach the repaired disk from it (Disks blade, click the disk, then Detach). Now go to the original VM's resource group, delete the original OS disk (you have the snapshot), and create a new disk from the snapshot you just repaired? No—actually you need to create a new VM using the repaired disk as the OS disk. Easiest way: Go to the repaired disk, click Create VM. Azure will pre-fill name, size, etc. Use a new name (e.g., myvm-repaired).
10. Test boot. Start the new VM. If all went well, it boots normally. If you still see a recovery screen, you may need to complete the BitLocker recovery by typing the recovery key when prompted, then the TPM protector will kick in for future boots.

Alternative fixes if the main one fails

Option 1: Re-upload the key to the vault. If the key was deleted but you have a backup, go to Key Vault > Keys > Generate/Import. Upload the existing key. Then use Azure CLI to force re-encryption:

az vm encryption enable --resource-group MyGroup --name MyVM --disk-encryption-keyvault MyVault --key-encryption-key MyKey

This works only if the VM can boot to safe mode—if it can't, skip this.

Option 2: Use Azure Site Recovery. If the VM is critical and you're short on time, fail over to a replicated copy in a different region. This bypasses the issue entirely but costs more. Only do this if you already have ASR configured.

Option 3: Decrypt and re-encrypt. Attach the disk to a repair VM as above, then run manage-bde -off E: to decrypt it fully. This removes all encryption. Detach, create a new VM from that disk, then re-enable Azure Disk Encryption manually. This is a nuclear option—you lose the protection until re-encryption completes.

Prevention tip

Set up Key Vault soft-delete and purge protection. That way, even if someone deletes a key, it stays in a recoverable state for 90 days. Also, export the BitLocker recovery keys to a secure backup location (like a separate vault or Azure Backup) before enabling encryption. I've seen teams script this using Azure CLI to dump keys to a storage account automatically:

az keyvault secret list --vault-name MyVault --query "[?contains(name,'BitLocker')].{Name:name,Value:value}" --output tsv > recovery-keys-backup.txt

Do this weekly. It takes 10 seconds and saves hours of panic.