Suggestion: A better way to image Windows system disks
Suggestion: A better way to image Windows system disks
Hi everyone. I've been using the most wonderful Paragon Hard Disk Manager (14 and 15) for a number of years now, and I noticed some time ago that it doesn't quite get disk imaging right on GPT-partitioned Windows drives. Almost, but not quite. The problem lies in the fact that it does not retain the original GPT data (i.e. disk and partition GUIDS, partition names), choosing instead to produce a GPT with new GUIDs, modifying the Windows BCD in the process to make Windows bootable. The problem with this approach is that HDM doesn't seek out and modify other instances of BCD data which could be present on the original disk, pointing to e.g. the Windows Recovery image and/or a manufacturer-specific boot image. As a result these other systems won't boot on the new disk. What's more, HDM will place a generic Windows name as a title for the copied Windows partition in the modified Windows BCD data, naming it simply e.g. Windows 10 whereas it was originally named Windows 10 Pro. It will bloat the original Windows BCD file, leaving the old and invalid BCD data behind. It's a messy (technically: inaccurate) way of restoring a system disk.
This is a somewhat unfortunate situation, as HDM does an excellent job of actually transferring the original partitions, particularly to a smaller disk - a very useful and mostly poorly implemented procedure on other disk imaging software. The automatic resizing option works quite intelligently for instance, producing very rational results. Even the original file system serial numbers are restored. Sweet.
I was able to circumvent the inevitable boot problems caused by the GPT/BCD issue when restoring my original HP Windows system disk by restoring all the BCD files modified by HDM from the original image to their respective partitions/directories and editing the original disk's GPT, including the GPT headers and partition arrays: I took the original GPT and changed only the LBA numbers to their new counterparts, recalculated the new header and partition array CRCs, and pasted these into the primary GPT header. This procedure also produced the secondary GPT header placed at the end of the disk (a copy of the new partition array). I then overwrote the MBR, GPT and secondary GPT header on the target disk with the ones I produced manually, using HDM's disk sector backup/restore function. I did this using a hex editor, a CRC-32 calculator (HashCalc), and about 15 minutes of patience. It's something HDM could perform in a millisecond. I was able to boot Windows, Windows Recovery, as well as the special HP recovery image which is started via Windows Recovery from the target disk after this operation. No need to modify any BCDs, no mess. Everything works as on the original disk (except much, much faster as the new disk is an M.2 SSD vs. the original 2.5" 5,400 rpm drive).
Note that HDM will automatically update the Windows BCD regardless of whether or not the option is selected under Settings when doing a disk restore operation (Settings->Copy and backup options). It does this to make Windows bootable, as it doesn't restore the original GPT data. BCD and GPT data have to match for various systems to boot.
Also note that HDM does not change the partition table in the protective MBR when restoring disk images, putting the end of the legacy partition beyond the disk boundary when restoring to a smaller disk than the original. It's a minor problem that does not affect the GPT boot procedure, and is easily fixed with sgdisk. Technically though this can be considered a bug and I thought I'd mention it here.
Reply With Quote