Assume that you have a working Windows-based virtual machine (VM), and you attach another disk that has the same disk identifier as the original boot disk. The attached disk is a copy of the original template from which the current virtual machine was deployed.
In this scenario, the VM fails to boot and returns the following error:
*** Fatal Error 0x00000001 :
(0x000000000000000F, 0x0000000000000000, 0x0000000000000000,
Stop 0x7B (parameter 1, parameter 2, parameter 3, parameter 4)
For each VHDX added to a virtual machine, an EFI boot entry is created. These entries are of the form “\AcpiEx_....\....\scsi(0,0)” for the first VHDX, “\Acpi..\scsi(0,1)” for the second VHDX, and so on.
When the VM is turned on, the UEFI BIOS iterates through the list of boot entries until it finds a disk with an EFI partition, and then it runs \EFI\bootx64.efi. This is the Boot Manager. It searches the same EFI partition for the BCD store. The BCD store contains the location for winload.efi (the Windows Loader), which is stored in the OS partition under \Windows\system32\winload.efi.
That BCD entry that points to WINLOAD cannot have any references to the physical bus or LUN, because Windows must still be able to boot if the hard disk is plugged into a different bus or port. The BCD entry uses the disk signature to uniquely identify the disk that contains the OS partition. Therefore, if you have two different disks with identical disk signatures, this triggers a conflict by which unique identifiers are associated with the device.
WINLOAD has to load NTOSKRNL.EXE, the system hive and boot drivers, and to do that, WINLOAD must also figure out the boot partition. Because WINLOAD uses the same heuristic as BOOTMGR, it's extremely likely that NTOSKRNL (the system hive and boot drivers) is loaded from the same partition that WINLOAD was loaded from.
After WINLOAD runs, NT Kernel is initialized, and it too must figure out the location of the boot drive. NTOSKRNL uses a completely different heuristic to figure this out. If there are two disks with the same signature, there's no guarantee that NTOSKRNL will choose the same OS disk that BOOTMGR or WINLOAD chose.
The scenario specified in the "Symptoms" section is unsupported. A duplicate hard disk that has the same identifier should not be attached to the same controller when booting up the VM. Attaching the VHDX on a running system does not cause this problem because the disk ID is changed when PARTMGR detects a conflict.
For more information, see the following: