Cloning XP Drive with Robocopy

[ricardrosen]

I have  an old Core2Duo computer with XP SP3 and last week decided to upgrade the HD to a SSD.

Didn't want to use  imaging software so I just downloaded the latest Windows 11 64bit ISO from Microsoft. Put in on a bootable usb stick and booted the XP computer from it.
In the startup options selected cmd prompt, used diskpart to partition a single  primary 128GB partition (full size of ssd), aligned to 1MB (sector 2048), made active and formatted quick as NTFS. Exited diskpart and then ran bootsect /nt52 D: /mbr (d: is ssd drive letter)

Then ran the following Robocopy command:

Robocopy c:\(source xp drive) d:\(new ssd drive) /E /COPYALL /DCOPY:DATE

Took about 20 minutes to copy all files from old 80GB HD to the new SSD.
I ran a sha-1 hash checker on all files from the hard drive and then on the SSD, all matched, no missing

Took out the old hard drive and booted from new SSD. All working and the XP machine is now much faster.

I'm posting the above because I have read over the years and looked over old posts that mention cloning XP with Robocopy can cause problems. Nothing specific is mentioned though, just not to do it and use cloning software instead. 
So what is the correct way, is the above fine to clone an XP drive to a newer drive or will I get problems in the future.

 

 

[jaclaz]

Robocopy is fine, only the result isn't a "Clone". it is a "Copy".

But it should work fine, the possible issue (that you seemingly did NOT have[1]) is with Disk Signature, clearly the SSD has a different disk signature from the original disk.

XP identifies partitions/volumes (and assigns drive letters to them) through a combination of disk signature+offset to the beginning of the volume stored in the Registry.

Normally you would have to either:
1) restore on the newly initialized SSD the "old" disk signature

OR:

2) delete the related keys under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices (or the whole set of keys under that path)

In case #1 XP would boot exactly as before (no possible issues [2])
In case #2 XP would recreate the proper keys from the disk and partition(s)/volume(s) data (this in some cases may lead to a different drive letter assignment)

 

So, all in all, you were lucky (or your setup was so simple that the failsafe provisions implemented in the OS worked), after all life is good .

Rest assured that in case of multiple disks/multiple volumes/manually assigned drive letters you need one (or both) the above described procedures in order to boot and have the same drive letter assignment as before, not really-really a problem, since the worst that can happen would be a failure to boot, but nothing would be "damaged" and to fix it is just a matter of deleting a couple keys from a booted PE and reboot.

Though in theory the disk signature could be used by any other program, in practice this doesn't happen AFAIK (most probably because the sheer existence of it is not documented by the good MS guys)

Good to know that in your case it wasn't needed.

jaclaz

 

[1] there is a possible explanation, being that you had at first boot only the SSD and only a partition on it, so the XP auto-fixed the Registry, all in all it had an assignment of C: to a disk and volume that was not (anymore) present and the only volume it found was the single one on the SSD, from which it booted, so it had to assign to it drive letter C:, this is very likely a sort of failsafe (not entirely unlike the one in NTLDR that attempts booting from C:1Windows if BOOT.INI is not found.

[2] except in your specific case  , as it would not have worked as you would have had a same disk signature but a wrong volume offset (since you aligned it to 1 MB or 2048 sectors instead of the traditional 63)

Edited January 4, 2023 by jaclaz

[ricardrosen]

5 minutes ago, jaclaz said:

Robocopy is fine, only the result isn't a "Clone". it is a "Copy".

But it should work fine, the possible issue (that you seemingly did NOT have[1]) is with Disk Signature, clearly the SSD has a different disk signature from the original disk.

XP identifies partitions/volumes (and assigns drive letters to them) through a combination of disk signature+offset to the beginning of the volume stored in the Registry.

Normally you would have to either:
1) restore on the newly initialized SSD the "old" disk signature

OR:

2) delete the related keys under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices (or the whole set of keys under that path)

In case #1 XP would boot exactly as before (no possible issues [2])
In case #2 XP would recreate the proper keys from the disk and partition(s)/volume(s) data (this in some cases may lead to a different drive letter assignment)

 

Ah, so I must have got lucky. I now understand that after  Robocopy finished copying I should have:

Opened Regedit, go to HKEY_LOCAL_MACHINE\ - then load the system file hive on the new SSD under windows\system32\config\system 

Give the hive a temporarily name like 'MYSSD'  then go to HKEY_LOCAL_MACHINE\MYSSD\MountedDevices and delete the key HKEY_LOCAL_MACHINE\myssd\MountedDevices\DosDevices\C:

 

One question. Would the above Robocopy command and regedit be enough to make a bootable copy of Windows10/11. I find the charm of having more control over what is copied compared to imaging/cloning software.

 

 

[jaclaz]

31 minutes ago, ricardrosen said:

 

Ah, so I must have got lucky. I now understand that after  Robocopy finished copying I should have:

Opened Regedit, go to HKEY_LOCAL_MACHINE\ - then load the system file hive on the new SSD under windows\system32\config\system 

Give the hive a temporarily name like 'MYSSD'  then go to HKEY_LOCAL_MACHINE\MYSSD\MountedDevices and delete the key HKEY_LOCAL_MACHINE\myssd\MountedDevices\DosDevices\C

 

Yes, or using an offline Registry editor.

But there are TWO keys involved, one is easy (the \DosDevices\C: one), the other one will be something *like* "\??\Volume{317d75f2-eaca-11eb-90ac-806d6172696f}", but it is easily identifiable as it has the same value/contents of the "\DosDevices\C:".

And here you open a (small) can of worms, there is another thing that will change (another reason why it won't be a "clone"), the actual 317d75f2-eaca-11eb-90ac-806d6172696f is a V1 UUID that is generated the fitrst time the XP "sees" (and mounts) the volume, and V1 UUID's are generated from some hardware values (MAC address) and from the current date/time.

This won't prevent the XP with the newly generated keys to work, of course, still you will alter a data point.

29 minutes ago, ricardrosen said:

One question. Would the above Robocopy command and regedit be enough to make a bootable copy of Windows10/11. I find the charm of having more control over what is copied compared to imaging/cloning software.

 

It has to be tested, but I don't think that the disk signature/drive letter assignment or the Registry have changed.

jaclaz

[j7n]

On 1/4/2023 at 8:49 PM, ricardrosen said:

Give the hive a temporarily name like 'MYSSD'  then go to HKEY_LOCAL_MACHINE\MYSSD\MountedDevices

No, you don't want to rename the SYSTEM key. It holds a lot of settings besides drive letters. You would have to open the value for C: and put the new disk identifier and volume start in it, which can be copied from a system where Windows has seen the new disk already. If you clone both disks to have the same identifier (stored in disk sector 0 at 01B8h), and mount them in Windows at the same time, the system will correct one of them to be different.

I think that Windows NT 6 holds the identifier in the BCD data inside the boot menuu. Instead of referring to "disk 0" or "C" it uses the number. For less pain, and avoiding the need to edit the BCD, you should keep the identifier the same and partition start the same. Allocate any extra space to a data partition. The OS doesn't need 128 gigs. You can set it more easily with a BootICE's hex editor than edit the registry. Edits with other programs may not stick.

[jaclaz]

12 hours ago, j7n said:

No, you don't want to rename the SYSTEM key

 

It is NOT renaming it, it is mounting the System file (of the copied system) under a temporary hive in the current Registry (of the PE, or other booted OS) in order to edit values.

It is either that (mount in current registry under  new name) or using an offline registry editor tool.

AFAIK some of the new Windows (I believe since 8 or 8.1, but I may well be wrong and it  is only since 10) do not (anymore) automagically and silently change the Disk Signature, when they detect a "duplicated" disk they put it in "offline" mode.

Only when you manually (why?) put it online again the disk signature will be changed to avoid the collision.

jaclaz

[UCyborg]

There's a decent possibility that cloning Win10/11 with Robocopy won't produce the exact copy, see:

Maybe it'll boot, at least after making sure BCD is in order, but there could be broken parts, at least in UWP land and possibly other places if they're using new NTFS specifics unless they updated Robocopy to be aware of them by now.

[jaclaz]

That is another aspect, the (ab) use of hardlinks in more recent MS operating systems, this has started (AFAIK) with 7.

But on NTFS the problem should only be a lot more space taken on a "flat" (without hard links) filesystem.

For 10 it seems like there is the possibility of a hard link migration store:

https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-hard-link-migration-store

(I have no experience whatsoever with these Scanstate and Loadstate tools, with the /hardlink switch)

jaclaz

[j7n]

A linear sector by sector copy should be the way to go because it is much faster, unless you want to defragment in the process. One reason why I wanted to mount both disks was to use the OS tools to allocate the remaining free space before booting into the cloned system.

[jaclaz]

1 hour ago, j7n said:

A linear sector by sector copy should be the way to go because it is much faster, unless you want to defragment in the process. One reason why I wanted to mount both disks was to use the OS tools to allocate the remaining free space before booting into the cloned system.

Yep, but the "traditional", caveman approach I always used (integral dd copy) is not faster than "specific tools" (that can skip unused sectors) unless the volume is full up to the brim.

Making a backup of first sector (to be later restored or used as source to replicate the disk signature only, that can be done even with grub4dos before booting to windows) takes only a few seconds, costs nothing and allows to gave the two disks mounted at the same time if needed.

jaclaz