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,

[Froggie]

Greetings... sorry, just got around to this!  Below are the two relevant EVENTs occurring at the time of the SYSTEM error.  The GUID mentioned is the very same Win11 OS partition that was recovered while running LIVE under Win10.  Since the Win11 OS partition was not locked at the time of the Recovery, the Recovery completed fine under the LIVE Win10 System but threw the errors below.

The Win10 SYSTEM sees the Win11 OS partition but has it unlettered to protect it from any Win10 casual use.  Apparently the restoration of the Win11 OS partition caused Win10 to throw the error below.

I'll be happy to repeat the operation if needed.

Event#98
Volume \\?\Volume{9ff86e28-fea6-4ae3-99ec-1e135ae2fe96} (\Device\HarddiskVolume12) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.

Event#55
A corruption was discovered in the file system structure on volume \\?\Volume{9ff86e28-fea6-4ae3-99ec-1e135ae2fe96}.

The exact nature of the corruption is unknown.  The file system structures need to be scanned and fixed offline.

[Froggie]

I'll be happy to repeat the operation if needed.

This issue is completely repeatable.  I have no idea what HBS is doing to the unlocked Win11 OS partition to cause Win10 to throw this error.

Remember, the error is coming from Win10, not Hasleo... Hasleo completes its operation just fine.

What would you like me to do to help?