Shielded VM Creation Failed using SCVMM and also using Powershell

Hello Faizan,

Sorry to hear you've been stuck on this for so long. Shielded VM provisioning failures can be difficult to troubleshoot because guest console access and diagnostic information are restricted.

I can't determine the exact cause from the errors provided, but one detail stands out: the VM appears to reach the Windows boot process before encountering a REGISTRY_ERROR BSOD.

Also, IsHostGuarded = True indicates that the host has successfully attested, but it does not prove that the guest image, answer file, or subsequent key-release and provisioning operations are working correctly.

I would start with a quick isolation test, then look at the Windows image and its preparation, and only then move on to the shielding configuration.

1. Test using the EncryptionSupported policy

Create a test VM using shielding data configured with the EncryptionSupported policy instead of Shielded. This provides access to the VM console and allows easier guest-level troubleshooting.

• If the VM provisions successfully with EncryptionSupported but fails with Shielded, investigate the shielding policy, protection configuration, and associated certificates.
• If it still encounters the same BSOD with EncryptionSupported, concentrate on the Windows image, template preparation, and answer file rather than assuming the issue is caused by HGS.

2. Check the health of the original Windows Server 2022 image

Boot a backup copy of the original VHDX made before Sysprep, or the original VM, as a normal Generation 2 VM. Do not boot the generalized copy intended for template protection, because booting it can invalidate the prepared image state.

Run the following commands from an elevated Command Prompt:

DISM /Online /Cleanup-Image /RestoreHealth

sfc /scannow

Also check the Windows System event log for disk, NTFS, or storage-related errors. If the source image already has registry or system-file corruption, resolve that before preparing the template.

3. Verify the Sysprep and template preparation process

Once the source image is healthy, prepare it using:

sysprep.exe /generalize /oobe /shutdown

After Sysprep shuts down the VM, do not boot that installation again before protecting the template disk. Keep a separate backup of the original VHDX.

Also verify that the template is a Generation 2-compatible GPT disk with the required EFI and Windows partitions. The disk should be Basic, and the Windows partition should use NTFS.

4. Validate the Unattend.xml file and specialization values

Because the failure occurs during provisioning and specialization, the answer file is an important area to investigate. Check:

• Windows product key and substitution values.
• Administrator password and other required specialization settings.
• Custom scripts or commands run during the specialize pass.
• SCVMM substitution values such as @ComputerName@ and @ProductKey@.

If you deploy through SCVMM, verify that these values are populated correctly during deployment.

If you deploy through PowerShell with New-ShieldedVM, the @ComputerName@ placeholder is set automatically from the -Name parameter (non-alphanumeric characters are removed from the VM name). Other placeholders must be supplied with -SpecializationValues.

For example:

$specializationValues = @{

    "@ProductKey@" = "YOUR-PRODUCT-KEY"

}

New-ShieldedVM `

    -Name "TestVM01" `

    -TemplateDiskPath "C:\Templates\Server2022.vhdx" `

    -ShieldingDataFilePath "C:\Shielding\Test.pdk" `

    -SpecializationValues $specializationValues `

    -Wait

The paths and values above are illustrative. If your answer file has no custom placeholders, you can omit -SpecializationValues. A required placeholder that isn't replaced can remain as literal text in the answer file and cause specialization to fail.

As an additional test, generate a minimal answer file with New-ShieldingDataAnswerFile (administrator password and computer name only, DHCP networking, no domain join or custom scripts), create new shielding data with it, and redeploy.

If that succeeds, add your original settings back gradually until you find the one that breaks it.

5. Compare fresh patched and unpatched Windows Server 2022 templates

If the previous tests don't identify the problem, prepare two templates and run each through the same Sysprep, Template Disk Wizard, shielding data, and deployment process:

• Template A: Fresh Windows Server 2022 from the original installation media, without cumulative updates.
• Template B: Fresh Windows Server 2022 with the latest updates installed.

If A provisions and B fails, investigate the installed cumulative updates and the guest/host patch-level compatibility. If both fail, investigate the common provisioning environment and configuration.

6. Examine the host-side event logs and Windows Setup logs

On the Hyper-V host, check:

• Event Viewer → Applications and Services Logs → Microsoft → Windows → Hyper-V-Worker.
• Microsoft-Windows-HostGuardianService-Client/Admin.
• Hyper-V-Shielded-VM-Provisioning, if available on your Windows Server build.

Look for events recorded at the exact time of the failed deployment. They may identify which provisioning operation failed, which the generic Major Failure message doesn't.

If the EncryptionSupported test VM boots far enough, also inspect:

C:\Windows\Panther\setuperr.log

C:\Windows\Panther\setupact.log

C:\Windows\Panther\UnattendGC\setupact.log

Look for the first actual failure during the specialize pass. These logs may not exist if Windows crashes before reaching that stage. In that case, rely on the host-side events and the minimal answer-file test.

The REGISTRY_ERROR BSOD and ErrorCode0: 0xF don't identify the failing component on their own, so the first detailed error in the logs matters most.

My recommendation: Start with the EncryptionSupported test, then check the original VHDX for corruption. Next, validate Sysprep and the answer file, and finally compare fresh patched and unpatched templates. This should help isolate the failure without rebuilding the entire HGS environment.