Windows does not start after making a backup.

[Anonymous]

Hello.

I'm not a computer expert, just an amateur. But I've been using Rescuezilla
for years and I love it.

The fact is that I made a copy of my work computer (which belongs to the
company I brought it for) I made a BACKUP And to my surprise, when it
started the computer again...
Windows didn't start. I get a message asking me to reinstall it with the
installation disk.
I repeat: It failed when making the BACKUP, not when restoring it.
It is a Windows 10.
The thing is, I have restored using the Rescuezilla BACKUP and it also
fails the same.
I've searched here and haven't seen any related topics here
https://rescuezilla.com/help.html nor here
https://sourceforge.net/p/rescuezilla/discussion/support/
Apparently there are all the files and folders in the partitions but
Windows does not start.
I have a very old BACKUP of AOEMEI Backuper... with that I can restore it
without problem, but since it is very old it does not solve my problem.
I have tried to repair windows with HBCD, but without success...

I hadn't thought about taking a photo of the screen or copy the exact error
text, but next Monday I can give you the information if you need it.

Can you think of an easy solution?

Sorry if my English is not very correct, I am using Google translator to
help me.

Thank you very much in advance!

[Lukas]

I've encountered a similar problem using rescuezilla cloning a drive.
I had to migrate windows on a machine at work to a bigger ssd. I did it previously on a other pc, where it worked fine, so I wasn't that anxious and started right away.
At the beginning I got a warning message, some partitions could not be found. That didn't bother me, because in worst case, the cloned ssd does not boot and I have to think of something else. I also noticed, the pc before hat 4 partitions to clone, the actual one only two.
After cloning the fresh ssd didn't boot, so I swapped to the old one. But this one did not boot either.
Because lack of time I decided to install a fresh windows and did not think about a way to solve the problem otherwise.

Recentyl I had again a broken/missing boot partition on my private pc. This problem I could solve whith the help of this forum. Maybe this was the solution for my previous problem too?
https://sourceforge.net/p/rescuezilla/discussion/support/thread/5f7488f667/#01b9

[Rescuezilla]

Extremely sorry to hear your experiences here.

Obviously a failed backup should not impact the booting your Windows source disk. I recently actually received a similar report for this: https://sourceforge.net/p/rescuezilla/discussion/support/thread/031dce6400/. I don’t yet know what the root cause is, but clearly there’s a critical severity bug lurking in Rescuezilla v2.4.2 (and likely earlier versions).

The easiest solution to fix the situation is to use Rescuezilla’s file manager to access the files on your source disk’s Windows partition and then copy your files to your external drive. Then restore your very old backup image (the image created by AOEMEI Backup), booting back into Windows then copying your files from your external drive.

Once you've made a backup of the important files, there's something else that is worth doing: I am not familiar with AOEMEI Backuper, but if you can select the partitions to restore, it's worth trying to restore only the first few small partitions using that program. I suggest this can fix any corrupt Windows bootloader without touching your data. But only do so if you’ve made a backup of your files first using the instructions in the paragraph above.

Side note: In a situation like this it’s often useful to create a backup image of the source disk’s Windows partition (which unlike the bootloader should be healthy) just in case you need to recover files in the future. But since the regular backup mode is failing for you, this can unfortunately only be done from the command-line tool ddrescue, which is hard to use.

However, it's still worth trying to create an uncompressed backup image of your final NTFS windows partition (the large partition) using the standard Rescuezilla user-interface. This will be usable by the Rescuezilla image explorer. Again please make sure the compression of the backup is set to 'uncompressed' here.

Finally, could you please upload the clonezilla-img log file from your Rescuezilla backup (or send it to rescuezilla at gmail). I would like to examine it to try and identify the root cause of this clearly critical severity issue.

[Anonymous]

Thank you, I attach the file you requested.

https://we.tl/t-lXJpyc10pr

You've given me good hints and advice. If I manage to fix the problem, I'll let you know.
Tomorrow I'll try it again.
Thank you so much for the help.

[Rescuezilla]

Just as a follow up I should mention that I analyzed your clonezilla-img log file. Interestingly, the backup image looks healthy. All 3 partitions were successfully backed up and I can't immediately see the error message you are referring to.

After performing the file-based backup I described in the previous post, it's probably worth trying to verify your backup using Rescuezilla and then try restoring it with Rescuezilla. It may not work, but it's worth a try. If you try this, please let me know if your backup passes verification and how the restore goes.

Side note: I found the possible root cause of this critical severity bug. The root cause is a bit technical, but basically Rescuezilla is modifying the source disk during backup (and cloning) operations for the NTFS file system used by Windows. I'm working on making sure Rescuezilla no longer modifies the source disk in the future.

[Anonymous]

"it's probably worth trying to verify your backup using Rescuezilla and then try restoring it with Rescuezilla. It may not work, but it's worth a try."
It definitely hasn't worked.
I thought I had explained it in my first message...
It seems like everything goes well with the restore.
But Windows still won't boot.
How can I use "ddrescue" to try to repair it?
Thanks

[Rescuezilla]

Oh sorry, I misread you didn't try a restore.

My recommended suggestion to this critical severity bug in Rescuezilla is to mount the Windows partitions using the file manager (after closing Rescuezilla) and manually copy all your files to an external hard drive. Then restore your AOEMEI backup using AOEMEI. This will get you back to a booting version of Windows with old files. Then manually copy the files back after booting into Rescuezilla or Windows.

The ddrescue option will not be needed here.

[Anonymous]

I have not yet tried what you told me in your last message. But my goal is still to leave my work computer as before, or the closest thing to the "fatal backup." If I copy everything over raw it is very possible that it will give me errors. Even if I delete all the files and documents, and then copy the files from the backup that doesn't start, won't I still have the same problem? Any other advice to leave Windows as similar as possible to the moment I made the last backup with Rescuezilla. Thank you so much.

[Anonymous]

Sorry, I trusted Google Translate too much... Where I wrote "over raw". I meant copying over carelessly, without first deleting the old things that I most likely no longer need.

[Rescuezilla]

I spent 2.5 hours trying to reproduce this issue and find a fix tonight.

The first hour I trying to reproduce the issue you’re seeing by doing hard restarts with a Windows virtual machine, then booting into Rescuezilla, and running the ntfsfix --clear-dirty command which the command the Rescuezilla backup currently uses to modify source partitions.

But despite all the hard reboots, I was only every able to cause windows to boot into a self-resolving filesystem check, which were resolved a single ‘continue’ or ‘repair’ clock. In other words, nothing that persistently broke the booting into Windows.

I reread your clonezilla-img log file, and there is something unique about your Windows disk compared to the environments I have been testing Rescuezilla with. Specifically all three partitions (the boot partition, main filesystem and the “Microsoft reserved partition”) are all using NTFS filesystems. This means ntfsfix --clear-dirty modified all 3 source partitions,

I have two suggestions for you. Both may not work, but are both worth a try:

The first thing I recommend is to download the Clonezilla live ISO environment and to try restoring the image created by Rescuezilla. Clonezilla is programmed differently to Rescuezilla so it may yield different results. For example, I noticed your ‘Microsoft Reserved Partition’ is at the end of the disk and Rescuezilla’s restore expands that final partition slightly. But Clonezilla has a special case to avoid expanding this.

So please try restoring with Clonezilla and rebooting.

If that doesn’t work, I have one final idea. Boot into Rescuezilla, and reconfirm your Windows disk is /dev/sda (either using Rescuezilla’s checkbox on the Backup page to show advanced options, or by opening GParted). Then close all applicatons and open a terminal.

Please run the following 3 commands (pressing Enter after each command)

ntfsfix /dev/sda1
ntfsfix /dev/sda2
ntfsfix /dev/sda3

Please note the final characters of 1, 2 and 3.

From the manual of the ntfsfix program, running the program this way will set a new request for the volume to be checked the next mount. This is different to what Rescuezilla did during the backup, which will clear any existing requests.

And this point it may be worth restarting back into Windows. But alternatively, Please try manually run a filesystem check from Rescuezilla:

fsck /dev/sda1
fsck /dev/sda2
fsck /dev/sda3

After running this, please try rebooting into Windows.

Please note, I’ve written the above instructions without yet having a reproducible test-case to confirm this myself.

I will keep trying to create a reproducible test environment to fix your issue. My next steps is to try and create a three partition NTFS Windows environment.

[Anonymous]

Thank you very much for your time and dedication.
Nothing has worked. I have managed to restore with Clonezilla.
After fighting with their awful menus...
But the result has been the same.
Nothing you've suggested has worked.
Would you consider having me send you the full backup?

[Rescuezilla]

Would you consider having me send you the full backup?

Yes, I would be very happy to work with your full backup to try and resolve this issue.

One secure approach is to upload it to Google Drive, and share the folder with the rescuezilla at gmail email address.

The only downside is your backup folder may be very large, so depending on your internet speed the upload may take a very long time. Also I'm not sure if Google Drive will be able to fit your backup image.

[Anonymous]

What is Rescuezilla's email address? The backup resulting from the original "incident" occupies 61.5Gb... I could try to make a lighter version, (restoring, deleting everything not related to windows or windows installations and configurations), and making a backup again with rescuezilla) but it would no longer be "the original backup". I also have a Mega.nz account with 50Gb... but I think it could cause problems for you, because it may limit the download for you, so I could send it to you via Google Drive with different links.
I'll do whatever you say, you're in charge
Thanks :)

[Rescuezilla]

As mentioned, rescuezilla (at gmail dot com) is the email.

Feel free to use Mega for the bulk of the image, and another website like Google Drive for the rest. Rescuezilla's files are split up by 4GB chunks ending in '.aa', '.ab', '.ac' and so on, so it should be pretty easy to split it up.

I have a fast internet connection, and when I reach the Mega.nz download limits I will pay for an account to download the rest.

[Rescuezilla]

Thanks, I have received your backup image.

I tried to restore your image onto a clean virtual machine, and was able to reproduce your exact error message.

It's super weird because all the partitions can be restored fine, and after being restored, all 3 partitions appear completely healthy.

I spent some time today trying to fix the system, but have so far been unable to.

Based on the error that you mentioned (and I've reproduced), the Windows bootloader can't find the Windows registry file in \Windows\system32\config\system and reports error code 0xc0000017.

I've tried the Windows installation disk repair commands without success (as you have).

I thought the Windows registry files on the filesystem might have become corrupted (I'm not sure how it would get to that state), and tried manually restoring from the Windows registry 'BAK' backup files, but that didn't work. It leads to Windows boot animation to spin forever (which I'm not sure is further into the boot process than instantly reaching that black screen of death)

I've been trying to manually use the Windows installation disk's Command Line to repair the BCD ("Boot Configuration Data"), but it has an error message that it can't identify with Windows. I'm likely doing some thing wrong. I'm certainly not currently an expert in Windows boot repair because Rescuezilla has typically been reliable when doing backup/restore/cloning of Windows environments when evaluating the program with my test suite.

I'll keep debugging this error to try and find a solution.

[Anonymous]

I have had very bad luck. I have use Rescuezillad many times, on my own and other people's computers. And nothing like this had ever happened to me. If you make any progress or can think of something I can try to leave Windows operating as close as possible to the time of the accident, let me know. Thank you.

[Anonymous]

Hello, have you been able to make any progress? the thing that kills me is... the Windows Startup was damaged, making a backup... And that everything seemed to go well... Until I restarted the computer

[Rescuezilla]

I'm still working on this -- I tried for almost 1.5 hours today without any luck.

Since the Windows tools like Bootrec /FixMBR can't detect the OS partition, I tried out AOMEI Partition Assistant's Rebuild MBR feature.

I also tried deploying a copy Windows\system32\config\system registry files from a donor environment to see if the boot progresses further. But it didn't progress further (which is interesting)

I'm still trying to identify if the Windows Registry files on the main partition were some how corrupted, or if the much smaller regions that contains the Windows bootloader happen to not be able to 'see' the partition due to some other reason.

The evidence so far points to the latter, which is somewhat promising.

[Anonymous]

Hello Rescuezilla, my friend. I think I have solved my problem. Not 100% yet. I prefer to warn you, so you don't waste any more time. When I have it working 100% I'll explain how I did it. Thank you!

[Rescuezilla]

Oh that's fantastic to hear!

I spent about 2 hours more on this yesterday but still haven't reached a bootable environment yet.

[Rescuezilla]

Rescuezilla v2.5.1 has now been released: https://github.com/rescuezilla/rescuezilla/releases/latest

It has removed the only known modification of the source disk that Rescuezilla makes backup and clone operations: the usage of ntfsfix --clear-dirty described above. From the Rescuezilla v2.5.1 changelog:

• Stops running the ntfsfix --clear-dirty on NTFS filesystems on the SOURCE DISK during backup and clone operations (#466)
• Running this command (the only command in Rescuezilla that modifies the source disk) appears to be the root cause of a critical severity error that impacted a small number of (hibernated) Windows disks since the command was added in Rescuezilla v2.3 (2021-12-24) where creating a backup image or clone appears to cause some kind of corruption that can break the Windows boot with a Blue Screen of Death, possibly due to corruption in the Windows BCD (Boot Configuration Data)
• However, I still have not been able to reproduce the error in despite many hours of testing
• Removing this command will likely mean more 'hibernated NTFS disk' errors on backup or clone of Windows disks if not booting into Rescuezilla with the 'Restart' Start Menu command -- but removing the apparently dangerous command is obviously worthwhile

Separately, a user on the Sourceforge forum reports they were able to fix the issue using the following instructions:

Correction. the above video solution did work. it just required two restarts after completing the suggested CMD operations from a live booted flashdrive of ventoy 1.0.99 running the latest windows 10 64 bit ISO image 22H2.

I copied the windows ISO to the storage partition on a 64 GB sandisk cruzer USB, that had ventoy 1.0.99 flashed to it.
I plugged in the USB and booted the windows iso via wimboot from the ventoy menu.
I then followed the instructions in the video exactly. Here is the link to the video below once again.
I rebooted twice. My problem was resolved. What a relief.

https://www.youtube.com/watch?v=eHGsI3CUlgs

As noted in the changelog, I haven't been able to reproduce the issue despite many hours of testing.

The source disk is no longer modified by the ntfsfix --clear-dirty during backup and clone operations, which appears to be the only possible root cause.

Therefore, closing this issue now.

[Carlo Bocchetti]

I have a roblem using rescuezilla with Microsoft surface Pro 11 (is a tablet): how to boot if in order to do the back-up?