recovery experience

This is a report about a somehow successful recovery, but a horror dream kind of.

The final solution was

(this is for GPT disk, not for MBR disk)

After restore, the PC did not boot, I started BuildPE1.5 bootable media again, started command shell, and then.

 diskpart

select disk 0

list partition

select partition 2 (the one marked system)

format fs=fat32 (this erased boot loader and bcd store)

assign letter=s

exit

bcdboot c:\windows /s: s /l de-de /f all   (where de-de is my language code. Substitute yours.)

exit

(and reboot successfully)

what I did as precautions

back up the whole disk, including C: and a data partition e:\ from the BuildPE1.5 bootable media (which was built to include Backupper 3.2, a trip by itself)

extract the data from e:\ from the backup, on a live system, to make sure they can be read.

extract user data (that is desktop), on a BuildPE1.5 bootable media system (because in the live system they are protected).

Copied the .adi files to a second place, just in case during restore they would be overwritten.

We do have recovery CD/DVD, which were created when the HP computer was bought, which are a last measure for factory reset.

what bad happened

at Windows time:

the disk layout was seven partitions: WINRE (original from Win8) SYSTEM (ESP) MSR C: WINRE (extra from Win8.1) E: (our data partition) (HPs Recovery). There are two WINRE, as Win8.1 update creates a new WINRE.

Windows recovery to a system restore point failed.

Windows "create system image" restore failed (the system image was taken a year ago)

said Windows "create system image" erased the data partition e: on the second restore attempt, and failed by itself (such restore never failed before).

Windows boot repair, after restoring C:, did not repair. Windows boot repair did not selfheal between firmware, system (ESP), c:, winre, although all partitions (system c: winre) were perfectly restored.

Windows 8.1 keeps restore points only for two weeks. This would have been enough in this case, if it didn't fail.

at AOMEI time:

AOMEI backup 3.2 disk restore restored partitions 1 thru 4 only. It stopped at the second "winre" partition.

AOMEI backup 3.2 disk restore did not repair the BCD entries or the firmware boot entries (it never adjusts BCD or firmware entries).

AOMEI backup 3.2 partition restore did not restore the GUIDType of the second WINRE (it never restores GUIDTypes). I assigned to correct GUIDType "recovery" instead of "data" to the second WINRE partition after restore (without result, see above, Windows boot repair anyway fails).

AOMEI backup 3.2 partition restore from the BuildPE1.5 bootable media assigned the drive letter of the USB disk to the restored partition (assume USB disk is G:, restore a partition, the partition becomes G: and USB disk is without drive letter).

AOMEI system backup was done, but it included only system (ESP) and c:, and did not include WINRE which it should have done, as the computer is GPT UEFI. Restore was not tried, maybe it would have done BCD repair, but I did not try in this emergency.

what was the issue

a virus had hit the computer and some repair was required.

what was the result

C: and E: are in place and work, maybe the virus still in C: but undetectable.

what is the summary

contents of any partition was always restored correctly from AOMEI.

the windows recovery environments do no longer work, because BCD store is not right, and not repairable by any reasonable tool (bcdedit is too complex).

Without AOMEI, data and OS would have gone, and data would have been lost. An incredible amount of proper knowledge including bcdboot and precautions was required to keep it stable.

It would be great to have a tool that repairs between firmware, system (ESP), BCD, c:, and WINRE, on uefi computers (and on bios computers too).

It seems that Windows boot repair only repairs within C:, doing a dskchk and doing checks within the Windows folder, considering the amount of time spent for repairs.