Multi-BOOT Partition Anomaly

[Froggie]

Greetings... strange phenomena today.

I run a multi-BOOT System (Win10, Win11, Linux) and my main backup configuration is Disk-based rather than System-based, including the normal System partitions to recover the Win10 System (that's where I run the imaging from) plus the Win11 OS partition... 5-partitions in total).

Today I decided to restore just my Win11 OS partition from Win10.  Since the Win11 partition was not active at this time, I expected to be able to do this without any required reBOOT into the Emergency Disk.  It did exactly that but at the end of the process, while in HBS, the LIVE Win10 System shot up a disk error (Restart to repair drive errors!) that would require a checkdisk on the next reBOOT.  I reBOOTed the System and the Checkdsk ran on Win10 for a while and finished, no major issues.  ReBOOTed into Win10, all OK... reBOOTed in Win11 and the restoration was fine.

Anybody have any ideas what may have happened and why?  Normally, recovering a non-Active partition on the same disk that holds the LIVE OS is never an issue.

[admin]

@Froggie,

It is indeed quite rare to suddenly get a disk error prompt while Windows 10 is running, at least I have never encountered it myself. Are you sure the prompt was indicating a file system error on the current C: drive? Could it have been a file system error on the newly restored Windows 11 volume instead?

In principle, HBS writes data blocks directly to the target partition through the underlying disk driver, and it does not touch the current system partition. Moreover, Windows itself protects the running system partition and does not allow other programs to write to critical system files arbitrarily. So from both a permission and operational object perspective, it should not trigger a "repair disk" error on Windows 10 itself.

Given that the restoration ultimately succeeded and both systems are running fine, it is most likely not a serious issue. However, if you want to get to the bottom of it, the most straightforward approach is to check the Event Viewer logs around the time of the restoration. Look for error events from disk, ntfs, or volmgr sources, along with specific error codes, that might provide some clues.

Have a nice day!

Best regards,