Yesterday, I got on the phone with Jim Thomas and Anna Pankratova of Paragon Software, to dig a bit more deeply into the issues inherent in creating images for GPT boot drives on Windows 8 (and 8.1) UEFI systems. Thanks to their explanations, and a Paragon white paper they pointed me to (“Significant Booting Challenges on EFI Systems when Upgrading to Windows 8“) I now understand that when the Windows Boot Manager sets up a boot volume in a UEFI-GPT environment, it creates a unique ID for that volume that incorporates the following data that is then stored in EFI NVRAM (firmware, basically) as part of the boot-up configuration:
1. A GUID that maps to Boot Configuration Data (BCD), and contains unique data about a specific Windows installation on a specific host device (HD or SSD)
2. An ID for the storage device upon which the volume resides that includes the SATA port number to which the drive is attached
When you move a boot device to a different SATA port, the device ID is no longer correct, and the Windows Boot Manager will not boot from wherever that drive may actually be attached (essentially, it’s looking for that device only on its original port address). This explains why you see an entry in the UEFI BIOS under boot control for “Windows Boot Manager,” rather than a specific drive name or ID. This drove me wild in trying to change boot order to fix my problems, until I understood that “you can’t get there from here” is a natural consequence of this kind of boot organization and structure. Changing this requires editing BCD data, and may be accomplished at the command line when booting from Windows PE but is neither easy nor terribly straightforward (see the Windows and GPT FAQ on MSDN for more information).
When you migrate an image from one drive to another drive, be it HD or SSD, the GUID information that corresponds to BCD data for Windows boot-up stored in the EFI NVRAM cannot match the BCD information on the new target drive, because it incorporates device identifiers from the old device while the target drive incorporates different device identifier data from the new one. The Windows Boot Manager keeps looking for the old drive, even if you plug the new one into the same SATA port that the old one previously occupied. The boot record in Windows Boot Manager needs to be changed to fix this problem.
The brute force method for making such changes is simply to reinstall Windows to the new target drive. This creates a whole new (and correct) set of BCD information that points the Windows Boot Manager where you want it to go. But this technique requires a new OS install, a complete set of updates to make that OS current, then installation of whatever applications are needed to create the desired user configuration. A search on “BCD edit to change boot drive” reveals that partition labeling (using Diskpart or some equivalent partition management tool) is important, as is the bcdedit command line utility. Those interested in following this route are advised to check into Bo Yans’ very nice Visual BCD Editor instead, because it makes working with boot configuration data so much easier, and shields users from all the tricksy details of using bcdedit at the command line.
The Paragon tool knows how to create the proper BCD entries to make the Windows Boot Manager keep working after a drive swap.
I have now confirmed that the latest version of the $20 Migrate OS to SSD 3.0 utility from Paragon Software automates this task completely, and does a bang-up job of addressing potential partition alignment issues on SSDs that might affect IO performance on Windows OSes in certain situations. I actually prefer to think of this as a more general-purpose tool for migrating a UEFI-GPT Windows boot image from one drive to another, in fact, because the tool works well with HD or SSD drives as either source or target for such moves. To my way of thinking, $20 is a small price to pay for a quick, easy, and painless move from an old Windows 8 UEFI-GPT drive to a new one. Note: you must still retarget the new boot drive at the BIOS/UEFI level when you reboot from the replacement drive, but selecting “Windows Boot Manager” will indeed behave as you expect (and want) it to. If you try it for yourself, I think you’ll concur.