Scenario: I did a sector-by-sector backup (using Clonezilla) of my internal SSD containing Windows, and wanted to validate it, by booting from the backup, without removing the internal SSD (laptop is refurbished, but newly bought, don't want to risk breaking it). Then some weird things happened, see below.

Question: What is the reason, for these weird behaviours? In particular, why is it a problem for Windows, to have two disks with identical content, and why does the boot process "jump" to the internal hard disk? But most important: can I assume that my sector-by-sector backup can be used for restore, or would it be useless for some reason? (Assuming the backup disk is not faulty.)

Details that could matter: The SSD had three partitions: 1. 100 MB boot, 2. many gigabytes of Windows system, 3. 2 GB of restore partition. The HDD used for backup is bigger than the SSD, thus it has now some empty space at the end.

Weird behaviour #1: After selecting the externally connected hard-disk during boot-up, Windows started to load, but then it failed with the "inaccessible boot device" error.

Weird behaviour #2: After this, I booted up fine from the internal SSD, and both disks could be seen by Windows. However, the backup disk could not be mounted by Windows, since "it had the same signature as another disk" (unfortunately, I did not make a screenshot, but Device Manager was showing a similar message -- I guess this must be some hash of the entire content?). I guess this is related to #1.

Weird behaviour #3: I managed to boot up either of the copies (I'm not sure which one, see below) in safe mode, which failed, resulting in some log being written (again, foolishly, I did not note the name/path of the logfile, so I'm not sure which this it was, or which file), but I guess this was enough to make the disks different. Now, when trying to boot from the external drive, the boot succeeds (I select the device in the boot menu, Windows loads fine), however, I can see it was loaded from the internal drive (that is mapped to C: and marked as the disk with Windows, based on the make and model of the disks). So the boot process "jumps" from one disk to the other!

My theory is that the original SSD has some kind of ID, and the Windows boot loader uses that ID to find the disk used to boot. Even if the boot loader was started from another disk. Is this the case? If so, this also means, that I can restore the sector-by-sector copy only to the very same SSD from where it came from.

  • Booting from Windows using USB does not work, this is why Microsoft developed "Windows to Go"....docs.microsoft.com/en-us/windows/deployment/planning/… – Moab Feb 4 at 14:49
  • Interesting, I did not know this. Can you provide a link for that? (A quick google search just gives me some step-by-step howtos, how to boot Windows from USB, and they don't mention any special tricks. E.g.: lifewire.com/how-to-boot-from-a-usb-device-2626091) – Attilio Feb 4 at 15:05
  • Also, if booting from USB is not supported, than why does it start at all? – Attilio Feb 4 at 15:06
  • Booting from usb is supported by the bios or UEFI, but that does not mean a full windows operating system was designed to boot from usb, which windows is not. Windows PE was designed to boot from usb but it is a very limited windows operating system. – Moab Feb 4 at 16:43

A disk signature is a unique, identifying number for a hard disk drive or other data storage device, stored as part of the master boot record, and used by the operating system to differentiate between storage devices on your computer. A disk signature consists of 8 alpha-numeric digits from 0 to 9 and from A to F.

When two storage devices have the exact same disk signature, this is called disk signature collision. Windows won't accept two identical disk signatures, the second colliding drive will be turned offline and will not be mounted for use until the collision is fixed.

To fix the disk signature collision error for a non-booted hard drive, turn it back online from within Disk Management and allow Windows to write a new disk signature.

To avoid disk signature collision to start with, do not clone the disk using sector copy, but rather use a disk cloning software that will take care to create a different disk signature.

  • So this means, successfully booting up and writing to the log file did NOT fix the disk signature for sure? – Attilio Feb 4 at 15:07
  • If you had no request from Windows for permission for writing a new signature, then the disk signature was not modified. – harrymc Feb 4 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.