"The file is corrupted"... yes, but what file is corrupted?

Here are some screenshots of the whole experience (except for the last part where it says it could not do it after prompting me to select a destination disk to recover to).

Right click (right tap?) on the image and select "Open Image in New Tab" to view a larger image.

Is there any place where I can have a look at some kind of log that would indicate what file True Image thinks is corrupted (if any)?

If a backup is successfully validated in True Image, is it corrupted then?...

What version is validated when True Image does this operation? Does it validate the backup as a whole, including the incremental versions, or does it only validate to ensure that the initial full backup is in a good condition? I notice that validation took the same 45 minutes it took to initially create the full backup of this disk.

How does validation work? Does it have to be performed on the original machine that the backup was made of? Does True Image store checksums internally in its TIBX format that it then uses to compare the data on disk against? What kind of error checking and correction is built into the TIBX format?

This is the error I'm getting when the recovery starts: Recover operation failed.

I have found the log. It was too close to my nose! 😋

Apparently, True Image is doing some funny business in the background without asking for my permission or confirmation. (This is in line with what other users have reported on these forums.)

I hate software that assume that the user is clueless and so it decides for them what action to take because in its own mind (mind of its designer) it knows best what's good for the user. True Image appears to fall into that category. For example, from the log I see this.

Operation "Recovery" started.

Fixing operating system bootability.

Failed to detect GRUB activator.

This appears to be related to the issue I currently have with my Windows installation, namely startup issues. I should say "had", before I wiped the disk clean. Or so I thought.

Apparently there is still some leftover from the GRUB bootloader. However the, my startup issue is related to Windows and has nothing to do with GRUB bootloader at all. I have not installed a Linux OS on this PC in years. So the GRUB bootloader that Acronis is picking up on is a blast from a past long gone.

I seem to have disturbed some ghosts by doing a disk wipe of the Samsung internal SSD. I did not do that the previous time when the recovery process completed without errors (but this actually hints at why it was taking 4 hours to finish).

Here is more weird behavior from True Image. It doesn't know what time it is! Notice how it displays my last incremental backup differently in different places. It's one time in the list of backups, it's a different time in the date and time picker dialog box. Moreover, in the same list of backups, it displays the time differently for the same backup, after I reboot the computer and boot right back into Recovery Media to view and attempt to recover from the same backup a second time. The time is shifting by 1 to 2 hours, as if it has time zone problems. Meanwhile, my BIOS/UEFI system time has not changed between reboots.

Acronis... maybe you should focus on getting these things sorted out? Then we can talk about me paying for a subscription plan.

I know this exact issue has existed for ages in the Acronis Recovery Media, going at least as far back as 2017. Maybe no one knows about it, or no one is complaining? I don't know. I just thought I would point it out, for the record. It makes the software look unprofessional and unpolished, and makes me doubt myself when selecting backup to recover from (thankfully I don't have many daily snapshots).

I have uncovered another disturbing behavior...

"Recover operation failed"

Each time this error appears, I get a new partition on the internal Samsung SSD disk I'm trying to recover my system to.

Just curious if the "Track 0" may be problematic. I see it was selected to recover.

I have now examined one of the earlier logs from my last Recovery Media session. Please forgive my misuse of the quote block elements. This forum does not support code block formatting and has horrendous formatting in general. You will find the horizontal scroll bar at the end of this post, so you can scroll side to side and read each line. I have inserted my comments as code comments starting with a # symbol within the pseudo code block below (otherwise it breaks the formatting).

BrunoC wrote:

Just curious if the "Track 0" may be problematic. I see it was selected to recover.

That thought has crossed my mind. I will try to deselect that next time.

On another note, you will also notice that there is more than one recovery partition. I know there was on that disk. I don't know how or why, but I know I see this quite often in later years with Windows 10 installations. I do all my Windows installations on computers I build myself. Even the Windows setup program complains about it when I boot up from a Windows installation media and select a disk that already contains Windows 10. It will give me some Microsoft URL where I can take lessons on how to properly partition a GPT disk. I know there is some Microsoft KB article about this that I don't care to search for now. But I know this article states that the recovery partition goes to the end of the disk, and the special "MSR" (MicroSoft Reserved) partition goes to the beginning (if I recall correctly). The silly thing is, the Windows 10 setup program itself has done the partitioning. I don't care much to do partitioning manually (I used to do that long time ago). So I always only have one recovery partition to begin with after finishing installation. Then somehow Windows messes things up during updates and upgrades and I end up with two recovery partitions, and it's like Windows is accusing me of making this mess when I enter the setup to do a new installation of my system. (Microsoft does not practice what it preaches.)

Deselecting Track 0 did not help. That just makes it ask for me to select a location for the partition.

And I still get the message "Recover operation failed".

This is all that Acronis Recovery Media can do for me. This is the result of those small partitions it inserts when the recovery operation starts (and then fails). It introduces the GRUB bootloader ("ubuntu") and the Windows bootloader ("Windows Boot Manager") back into the system on an empty Samsung NVMe disk.

I have now disabled all my SATA ports in UEFI as not to accidentally delete or corrupt something.

In the following screenshots you see me start Acronis Recovery Media from the Kingston USB flash drive in UEFI mode. The log view is empty, there are no warning or info messages. Then I open the "DriveCleanser" and you can see the two partitions that the recovery operation has inserted previously to the Samsung NVMe destination disk.

I select to erase these using the "Fast" method (data destruction algorithm). It takes about 8 minutes. Then the disk becomes "Unallocated" so it's looking clean and good.

Now when I reboot and display the boot menu of my computer I no longer see the "ubuntu" entry (GRUB bootloader), nor the "Windows Boot Manager" (Windows bootloader).

I start Acronis Recovery Media from the Kingston USB flash drive in UEFI mode once more. I select my incremental backup to recover from, I deselect Track 0, specify new locations for the partitions on the destination disk, one after the other.

When loading "Settings of Partition C" to specify its new location, the program displays the message "The file is corrupted". I can specify its location nonetheless and continue.

Once I have finished specifying new locations for all the partitions, I start the recovery operation and it fails, per usual now. The log clearly indicates that "GRUB 2 EFI loader" was detected, that it has been "fixing operating system bootability", and that a "format/resize error" has occurred.

Entering DriveCleanser, I can see that those two partitions I had previously have been inserted once more.

I reboot and display the boot menu of my computer and I can once again see "ubuntu" entry (GRUB bootloader), as well as the "Windows Boot Manager" (Windows bootloader) entry.

Thank you Acronis Recovery Media! Now what?

Samir,

I have followed your posts here and it is apparent to me that you have issues with recovery yes and, you also have issues with your UEFI firmware on your machine.

UEFI booting is much much different than that of MBR booting of days past.  The behavior you are experiencing is a symptom of there being boot entries for Grub2  which loads a Ubuntu disk partition.  This is foreign to True Image in that what you are specifying to recover does not include the Ubuntu partition.

So the situation at hand here is that TI is telling you that your restore is corrupted because it does not match what is present in your UEFI firmware.  This is the result of creating a dual boot UEFI system and then deciding to change that and go to a simple single boot using UEFI.  The issue is your MOBO UEFI firmware, not True Image.

What you need to do to fix the problem is reset your UEFI firmware to default values so that a clean slate is available for adding boot entries for OS installations.  You could try entering the BIOS setup on your machine and selecting the option to Load Default Values or similar.  This will not guarantee that all UEFI values will be reset but, if the UEFI implementation was written well you have a better than average chance of it working.

As for TI adding the partitions to your disk this is an incorrect assumption on your part.  It is the UEFI firmware that holds the Ubuntu entry that you see and cannot get rid of.  That's because the entry does not exist on the disk itself but rather exists in your UEFI firmware.  I would advise you to have a read of the link below so as to further your understanding of the UEFI boot process from a layman's perspective.

UEFI boot

If you wish to avoid this in the future I suggest that you do one of two things.  Either do not setup dual boot on a single disk which I never do because if you do you are going to have issues like you have now.  Instead use independent disks for OS installs and then when you wish to boot a different OS swap out the disks.  Or, learn how to modify your machine UEFI firmware so that you can successfully manage UEFI boot entries using industry standard tools.

Further to Enchantech's comments above, you could also download & use the BOOTICEx64 utility which includes options for looking at and modifying the UEFI entries (separate from doing the same for BCD entries).

BOOTICEx64 is a stand-alone program that doesn't need to be installed and the latest version is version 1.3.4.0 as both 64-bit and 32-bit applications.

See webpage Bootice for one download option.

Enchantech wrote:

Samir,

I have followed your posts here and it is apparent to me that you have issues with recovery yes and, you also have issues with your UEFI firmware on your machine.

In this screenshot of my UEFI interface you can see the key management options I mentioned earlier.

Note that I can clear them and I can save them (to external storage device) for later use. This is just about all that operating systems can access and store in the UEFI firmware. In other words they have no way of storing entire bootloaders within the firmware. I have seen people talk about this as if it's possible, but I think that's just a misconception, I have yet to encounter such a system in the wild.

I doubt operating systems even have the capability to control such memory areas, for example to add boot entries to the firmware or remove entries from the firmware. Such operations would not only be needed during initial operating system installation, but also sometimes during or after a subsequent operating system upgrade, or in case of Linux based OS, when changing the kernel and adding entries for each kernel (the list can get long on Linux based systems).

What I do know is that at least Linux systems can access and manipulate PK and KEK, which may be necessary when installing proprietary device drivers for such exotic things as NVIDIA GeForce graphics cards. Windows can do the same, it just doesn't tell the user about it or let the user control what goes in and out of that memory area. Windows based devices are often prepared with these things from factory when you buy a new Windows PC. Windows is the whole reason why "secure boot" exists to begin with, so it's not a surprise that it too can manipulate these parameters.

Nonetheless, neither Windows nor Linux systems insert their boot entries in the UEFI firmware.

I will attempt to use a WinPE based Acronis Recovery Media instead of Linux based, just to get the GRUB that's on the bootable media out of the way.

In this screenshot, you can see that it talks about arranging the "boot order in BIOS". It should say UEFI, but there may not be any built in logic for checking what system type it's making the Recovery Media for, so it's understandable. But more importantly, it mentions boot order. This is because it's assuming that the user is not in possession of a PC (BIOS or UEFI) that has the "boot menu" option built into it for overriding the default boot order (or the user doesn't know how to access it and so it gives instructions for what it believes is easiest to do).

I will attempt to use a WinPE based Acronis Recovery Media instead of Linux based, just to get the GRUB that's on the bootable media out of the way.

Looks like it knows I'm onto it. It doesn't let me use anything but a Linux based media!

"Unable to lock the disk. Boot your computer from a Linux-based bootable media, and then try again."

Why would it insist on using Linux-based media? My guess is that it's because True Image has seen that something Linux based is broken and it has that need to fix things I haven't asked it to fix.

Next up:

I will have a look at that mechanical disk that I use only for storing photos, that True Image is indicating has a GRUB 2 bootloader on it. If I find GRUB there I will remove it. Then try again.

If that fails, I will do a clean install of Windows 10 and try using the Linux based Acronis Recovery Media again.

If that fails, I will enter the newly installed Windows and install True Image there, and then do the recovery from within Windows. This will work, I am confident. I just want to exhaust all the options first.

Samir, have you tried using BOOTICE to view the actual UEFI entries on your PC?

The images below are from my only dual-boot Windows 10 / Ubuntu system showing how the references to Ubuntu only are stored in the UEFI firmware settings.

The 'unable to lock disk' is not being reported to force anyone to use Linux media but is an indication that ATI has detected that flags are set for the disk indicating that Windows has a lock on it, i.e. when using Windows 'Fast Start' where doing a shutdown only puts the PC into a hybrid sleep state (akin to hibernation).

I always use the WinPE version of ATI rescue media and on the rare occasions I have hit the lock disk issue, the method around this has been either to use the 'Add new disk' tool to wipe the target drive (thus eliminating any flags etc), or else to force a full shutdown before booting from the rescue media.  Pressing / holding a shift key when clicking on Shutdown forces the full shutdown!  Note: just retrying the operation a couple of times after the lock message can often work too!

Returning to the UEFI entries, the only time I have seen an entry for Ubuntu on my main PC was when experimenting with dual-boot which I quickly decided was too much trouble!  The entry remained in the UEFI firmware settings and annoyed me until I discovered that I could use BOOTICE to remove it safely.

The images above are from a dual-boot VMware VM where I have done any further experimenting with UEFI & Ubuntu dual-boot, otherwise I run a separate Ubuntu VM and have at least 2 laptops running dedicated Linux OS.   My main gripe about dual-boot is that Windows tramples all over the boot entries when updates / upgrades are done!

I was examining a system report that Acronis recovery media has collected. Then I came across this odd thing. It's the license.txt file that I get by unzipping the archive.

{
   "Activation" : {
      "DaysLeft" : "UNLIMITED",
      "InstallId" : "",
      "LastError" : 0,
      "State" : "NOT_REQUIRED"
   },
   "DaysLeft" : "EXPIRED",
   "Distributor" : 0,
   "Edition" : 16,
   "Language" : 0,
   "Quota" : 1,
   "SerialNumber" : "*****************************************************-REDACTED-REDACTED",
   "State" : "ACTIVE",
   "Tier" : "PREMIUM",
   "TimeLimited" : false,
   "Type" : "PERPETUAL",
   "Upgrade" : false
}

Why are the days left for activation indicated both as "UNLIMITED" and as "EXPIRED"? Which is it? Also, the state is both "NOT_REQUIRED" and "ACTIVE". That second set of key value pairs looks like some unnecessary appendix.

I have redacted the serial numbers in case I need to keep it private, I don't know what that is really, doesn't look like the product key a.k.a. serial number that I enter when activating True Image.

Well at least they got the license type right, "PERPETUAL"!

Download BOOTICE and remove the entry or entries for Ubuntu/Linux it finds and try your recovery again.  How hard can that be?

BOOTICE is not able to detect anything.

This is because I have wiped the disk clean (with DiskCleanser/DriveCleanser). I bet if I let Acronis Recovery Media fail the recovery once, and then return to BOOTICE, it will display the "ubuntu" entry. This is because Acronis inserts those two small partitions.

Also, Ubuntu live system with Gparted has no knowledge of a GRUB bootloader on any of the disks.

Okay, so presently you have UEFI flash drive boot device.  You also have USB and HDD with Active flags set by the firmware as devices to look for boot loaders.

Your screenshots show several other disks attached to your motherboard.  So here's another approach.  Disconnect all disks that are not involved in the recovery process.  This should leave the boot media disk, the backup storage disk holding the file you wish to recover, and the unallocated target disk.

Boot your machine using the boot media.  Once it loads and boots successfully remove the media from the PC, it is not needed any longer as all necessary components are now loaded in ram.

Attempt to perform the recovery.  If by some chance Grub is present on any other disks on your machine it will not be seen by TI thus, this will prove if in fact TI is restoring these unwanted partitions that you claim it is or not.

I have already done something like that the previous day, I disabled the SATA port 1, 2, and 3 on the motherboard as not to accidentally delete something in places I don't want to. This is effectively the same as physically removing cables.

In fact, I have just done the same right now, with that Linux based Kingston USB flash drive with Acronis Recovery Media on. I wanted to shift away from WinPE and use Linux based recovery media, because I suspect that it's this version of recovery media that has issues (more so and more often than WinPE based media).

I have placed a bet above, and sure enough, I was proven right. By using the Linux based recovery media I have successfully inserted those two small partitions again, and more importantly BOOTICE was able to detect them. But it was no longer able to detect the "ubuntu" entry after I wiped the disk in DriveCleanser. (I have been using "DriveCleanser and "DiskCleanser interchangably, correct term is DriveCleanser.) BOOTICE was still able to detect "Windows Boot Manager" and even delete it. I didn't try deleting the "ubuntu" entry as I'm sure it would have done the same for that one. Why it was still able to detect "Windows Boot Manager" then? I suspect this is because the Samsung NVMe (target disk) was still displaying as "Unallocated" rather than "Not Initialized" meaning that not everything has been deleted off of it otherwise BOOTICE would not have seen anything there, just like it did not see the first time I entered that program with a clean slate (previously wiped target disk).

I will post some screenshots soon, that's easier to understand I think.

Maybe I should not have selected to wipe just the two small partitions that Acronis inserts (recovers), but the entire disk, so that it would appear Not Initialized. Maybe then BOOTICE would not see any of the boot entries, including "Windows Boot Manager".

Note that the "Boot disk" for both "Windows Boot Manager" and for "ubuntu" is clearly "Samsung SSD 970 EVO Plus" which is my intended target disk that keep wiping clean and keep failing to recover my backup to. It's not some one off HDD on the system, like the Acronis logs and system report make it look like (talking about having detected GRUB 2 EFI loader on an old HDD that I use purely for storage).

I will do the following test next.

1. Reproduce the two small partitions once more using the Linux based recovery media by allowing Acronis to fail its recovery job (partial success).

2. Reboot and switch to a WinPE based recovery media with BOOTICE on, and have BOOTICE delete the "ubuntu" and "Windows Boot Manager" entries.

3. Reboot once more and switch to the Linux based recovery media again, and have Acronis attempt another recovery job, this time there is no chance of there even existing any boot variable/reference within the UEFI firmware and I would have done it your way (as opposed to just wiping the disk).

I expect point 1 to succeed, point 2 to succeed and point 3 to fail.

Samir wrote:

I will do the following test next.

1. Reproduce the two small partitions once more using the Linux based recovery media by allowing Acronis to fail its recovery job (partial success).

2. Reboot and switch to a WinPE based recovery media with BOOTICE on, and have BOOTICE delete the "ubuntu" and "Windows Boot Manager" entries.

3. Reboot once more and switch to the Linux based recovery media again, and have Acronis attempt another recovery job, this time there is no chance of there even existing any boot variable/reference within the UEFI firmware and I would have done it your way (as opposed to just wiping the disk).

I expect point 1 to succeed, point 2 to succeed and point 3 to fail.

Everything went down as hypothesized. With exception for point 2 because while BOOTICE was able to remove the "ubuntu" and the "Windows Boot Manager" entries, the changes it made did not persist between reboots. This tool does apply the changes you make automatically, yes? There is no save button of any sort? None that I could see anyway. I'm just checking to be sure I used it correctly. After all, the message when you delete an entry does say "saved successfully" each time you delete an entry. I'm doubting myself for no good reason (I can't help it).

Why these things keep crawling back up is because of what I have stated above in response to Steve, namely that these entries are cleared from UEFI when the system recognizes that the corresponding bootloader and EFI file is gone, which naturally happens when you wipe a disk of all its contents (including partition tables, flags, loader, etc.). Since I did not want to delete any of the things that Acronis was putting back in place (the two small partitions) as it kept failing to recover my backups using the Linux based recovery media, UEFI kept recognizing them and adding them back in as boot entries/variables.

Perhaps... and this is a very likely perhaps... perhaps this BOOTICE tool is more true to its cause and operates differently when you run it from within a full instance of Windows, rather than the limited WinPE I was running it from. I have done my share of experimenting for now. I am currently in process of recovering my backup, using WinPE recovery media. That's right, this is no longer an issue of mine. I will post some screenshots soon.

You can see here that I am using WinPE based recovery media.

You can also see that the destination disk contains the two small partitions that I keep telling you Acronis itself is putting back in before it reports that the recovery operation has failed (see my old screenshots). It only happens when using the Linux based recovery media.

You can also see that I am using the "Add New Disk Wizard" this time round for wiping the disk. This however has nothing to do with the successful outcome of my late recovery operation. I might as well have used the DriveCleanser (which I mistakenly kept referring to as DiskCleanser above). I could have also used the Windows 10 installation media (WinPE) and the Miscrosoft DiskPart tool to do the same, as I did initially (but then booted into Linux based Acronis recovery media which proved to be a mistake).

The time zone was wrong as usual. But this time one of the last two incremental backups was shifted over to previous date, so not only time but also the date was wrong. I still knew that I wanted to select the very last backup. But Acronis is not making this easy when they can't figure out how to display the time zones correctly. Of course, this is inherently a Linux vs. Windows problem and how these two dispaly time differently. But even within the context of Linux alone, the time keeps chaning and shifting. They need to fix this.

Once it had locked down all the partitions and began to analyze C partition, I knew I was set. This would not fail. Sure enough, no error about corrupted file appeared. It then asked me to select a destination disk. I selected the Samsung NVMe as intended.

The Summary view looked no different from what I have seen before when running the Linux based recovery media. For the C partition for example it reports the file system copy and merge operation as "NTFS, None -> NTFS". Does anyone know what "None" means? Shouldn't this say "NTFS -> NTFS" or in other words "copying NTFS to NTFS"? I don't understand the "None" reference. At first I thought the Linux based recovery media was not able to recognize the NTFS filesystem. But here I see that the WinPE based recovery media behaves the same way. Anyway...

I opted to recover files with their original security settings and the recovery operation was soon under way. When I saw that more than 1 minute had past and no error was being reported, I knew this would go well.

It is still going as I type this. Estimated time to finish was 1 hour and 30 minutes. It's well past 50% mark and a little over an hour has elapsed. This is fast! Relatively speaking of course. I mean it's much faster than the 4 to 5 hours it took me to the same recovery operation using a Linux based Acronis recovery media. (Yes, I have recovered this exact backup once before on this exact PC that it originated on, without ever having to mess around with UEFI boot entries and whatnot. The only difference now is that I had used DiskPart to wipe the target disk prior to starting the process with the Linux based recovery media.)

Done! Everything is recovered and I am back in Windows. It looks and works just as I left it. Operation started 19:34 and ended 20:52. It took 1 hour and 18 minutes, less than what was estimated. This is in contrast to the 4 to 5 hours it took me to do the same operation using the Linux based Acronis recovery media last time.

So then, how come that Linux based Acronis recovery media is reporting these bizarre errors about my backup file being corrupted? When WinPE based Acronis recovery media does the same job without a single complaint, and it does it in half the time?

The only thing corrupted here is Acronis software.

"The file is corrupted"

I suspect this message is a reference to a disk drive. After all, devices are files in a Linux system.

The error most likely comes up as a result of True Image (or Recovery Media rather) attempting to "fix" something it saw as broken on the source disk in my backup file, something it has no knowledge of how to fix. I say let it hang loose and don't try to fix it unless you're told to, that's the kind of software I prefer. I think I know my own computer and software better than some automated Acronis magic script.

For the record, this is what my UEFI boot entries look like, now that my system has been recovered to a working state.

As you can see, I still have that "ubuntu" entry. Surprise, surprise! Well, not really. For my computer, this is normal. This is some old leftover from a previous installation of Ubuntu.

I know what you're thinking. It should not be there. But why not? It doesn't hurt anybody. I just have to turn my head and not look at it. When I need to use the F8 boot menu to override the boot priority list, I just need to remember to keep away from "ubuntu" entry. Nothing will happen even if I do select it, the computer will not explode, it will just drop me to the GRUB command shell and nothing more.

I will probably clean this up at some point. But for now, I will leave it alone, and the Linux based Acronis recovery media needs to be taught to do the same. It's unlikely I will ever again use Linux based Acronis recovery media, I'm just stating the obvious, for the sake of humanity Acronis needs to get to grips with its Linux based recovery media for the people that do use it (and it is the default when creating recovery media using the "Simple" option in the "Rescue Media Builder" tool in True Image).

Solution

Make sure you create a WinPE based Acronis Recovery Media.

Samir,

I see you have it sorted, that's good.

I lost internet today for several hours hence my late response.

I myself have not used the BOOTICE app however, I trusted that the product must work given Steve Smith's experience.  It appears that it only removes the entry from Windows Boot Manager however and not from the EFI Firmware itself.

The native industry standard tool to remove entries from EFI firmware is the BCDEdit tool.  It is a straight forward process to remove leftover entries from VRAM using bcdedit.  Before following the steps below however, I strongly encourage that you backup the boot entries found by bcdedit by using an elevated (admin) command prompt and issuing the following command:

• bcdedit /export c:\bcdbackup 

Next you must assemble a list of boot option entries stored in the UEFI VRAM firmware to generate such a list use the following command:

• bcdedit /enum firmware

The command above will display all entries in UEFI firmware from previous boots officially named the BCD store.  Included in each entry listed is the "description" or name of the entry such as Unbuntu.  The other necessary item in the list necessary for entry removal is the boot entry {identifier} alphanumeric value string which would be something like this:

• {802d5e32-0784-11da-bd33-000476eba25f}

The command to remove leftover boot entries from VRAM then is as follows:

• bcdedit /delete {identifier} where {identifier} is the alphanumeric value string

The reason you see boot entries in your bios Boot Priority list is that they exist in VRAM and your bios can display them.

Enchantech wrote:

I myself have not used the BOOTICE app however, I trusted that the product must work given Steve Smith's experience.  It appears that it only removes the entry from Windows Boot Manager however and not from the EFI Firmware itself.

Bob, in my experience BOOTICE does correctly edit the EFI firmware entries and has a separate tab for working with the Windows Boot Manager.  It certainly did so for my own laptop which had a 'leftover' Ubuntu entry from testing with dual-boot a while back then ditching it for using VMware VM's instead.  Bobbo put me on to using BOOTICE a couple of years back when working with creating a multiboot USB HDD.

Steve,

Curious, I thought you would only recommend something that you had confidence in.  I did download and tried it out on my main PC.  I found that after I removed entries for HDD and USB that they returned.  Using bcdedit cleared them both however, on cold startup the HDD entry returned.  Not ever having run dual OS's on this machine I could not test that aspect however I have done the same on other machines that fit that criteria always with success using bcdedit.

It really depends on how the firmware is written and how the user has previously booted the PC.  What I find troubling is that in Samir's case the Linux media by default was finding both Windows Boot Manager and Ubuntu and then applying both to the disk.  Acronis has all but left the Linux variant behind and in this case they obviously should have done so already. 

I'm sorry to disapprove, but these "boot entries" have little to nothing to do with BIOS firmware or UEFI firmware. This kind of boot menu exists outside the scope of a normal bootloader and its boot menu. They stand above all of that. I tried to get that point across previously by talking about different kinds of boot menus (where I blabbed about the GRUB menu).

Even on an old PC from late 1990s that sports an old "legacy" BIOS system, its boot menu (if it has one) doesn't exist within the scope of the bootloader that's starting up the installed operating system. The BIOS system of such a PC simply scans all the available disk drives and the first 512 bytes (track 0) on each and every one of them in order to locate a disk drive it can boot from, hence the term "bootable". This is most likely to be the disk drive that contains an operating system, and yes, the first primary partition must have the "active" flag set for the BIOS to easily locate it. The bootloader then takes control of the hardware, and in turn it leaves over control to a larger operating system.

I am not an expert, not a BIOS/UEFI engineer, but let's just say I know how a PC starts.

As for Acronis' inability or failure to perform such a critical task as recovering the user's system from a backup file, and calling it unhealthy or "corrupted", just because Acronis is trying to be smart about the recovery process and wants to perform things it was never tasked with, as if I said "oh by the way, while at it, try to fix my ugly looking and broken disk layout and UEFI boot entries"... well... for one, that has nothing to do with how my UEFI is set up, that's just Acronis being dumb about what recovery means. Recovery means "give back my data, and don't give a damn about the rest". If I want to do THAT kind of recovery (startup repair, etc.), I know where to go and what to do.

Samir,

You are mistaken in your position on UEFI not being firmware based.  It is in fact based on firmware and is code in VRAM.  This information is all over the internet.  A short primer is linked below:

https://www.howtogeek.com/56958/htg-explains-how-uefi-will-replace-the-…

You are mistaken in your position on UEFI not being firmware based.  It is in fact based on firmware and is code in VRAM.  This information is all over the internet.  A short primer is linked below:

https://www.howtogeek.com/56958/htg-explains-how-uefi-will-replace-the-…

Please quote me on that. I did not say what you're suggesting. EFI or UEFI is a relatively old Intel initiative for creating a modern day firmware standard for PC (x86) computers and replacing the old (IBM) BIOS. I know what it is. Find me a reference to this "VRAM" you keep mentioning.

Bob, in my experience BOOTICE does correctly edit the EFI firmware entries and has a separate tab for working with the Windows Boot Manager.  It certainly did so for my own laptop which had a 'leftover' Ubuntu entry from testing with dual-boot a while back then ditching it for using VMware VM's instead.  Bobbo put me on to using BOOTICE a couple of years back when working with creating a multiboot USB HDD.

Steve, did you run BOOTICE from within your Windows installation? Or did you run it in WinPE like I did above? I would expect different outcomes from running the same software within different environments (even if it's a self-contained Win32). I believe this clever little program was designed with Windows users in mind. Even if it does not require installation (Win32 PE or Portable Executable). In other words, I may have used it in a context it was never designed for (I could not help it since I had no Windows installed on my PC).

Sorry Samir but we must agree to disagree on this point.

Samir, I ran BOOTICE from within Windows on the most recent occasions I have used it but I do have it on my WinPE media to be used in that environment if needed.

When I used it to remove Ubuntu from my own UEFI listing, this was done from Windows.

Sorry Samir but we must agree to disagree on this point.

I no longer know what the point is, but that's OK.

It's pointless to argue without a point (pun). I think I have made my points clear enough.

Samir, I ran BOOTICE from within Windows on the most recent occasions I have used it but I do have it on my WinPE media to be used in that environment if needed.

When I used it to remove Ubuntu from my own UEFI listing, this was done from Windows.

Thanks for your input Steve!

That does support my hypothesis, namely that BOOTICE will stand a better chance at removing these UEFI/EFI boot entries (vars) if the program is run from within a proper Windows OS rather than this limited WinPE live system.

I will not be testing my hypothesis anytime soon, maybe another time.

I think the best you can do with BOOTICE inside a WinPE session is to manipulate the BCD and thereby the boot entries that Windows Boot Manager is responsible for. Remember that Windows Boot Manager has its own boot menu, and that it's unrelated to the UEFI boot menu where you can press a button (F8 in my case) to override the default boot priority of your UEFI or your BIOS (both UEFI and BIOS of recent decade have this). Note that I have not tested this part of BOOTICE. It may not be possible for it to access the System Reserved partition of the offline Windows system, in which case it may prove useless at even manipulating the BCD. It may or may not... it's best to test it to be sure, if you want to rely upon this tool.

If I'm not mistaken you also have access to such tools as BCDEdit from within WinPE, in which case you might as well use that instead. But it's certainly nice to have a bit of GUI for ease of use. So it's a good alternative, but only for BCD I'm afraid, and maybe some few sophisticated extras like modifying MBR, exporting/importing boot sectors, etc.

At its core, BOOTICE is just a tool. People can make tools for all kind of things. Sometimes they reinvent the wheel just for the sake of making a name for themselves. They start off with an idea (editing BCD) for which there already exists a tool that supports the idea (BCDEdit), then they start tacking on extras like this whole UEFI section in BOOTICE, and to finish it off they also add exporter and importer for the boot sector. (This is akin with what Acronis is currently doing with True Image by tacking on Cyber Protection and whatnot.)

I can make a simple Windows program that will simulate removal of stars from the sky with the click of a button, one by one (obviously you don't want to remove all the stars at once). That doesn't make it real, however realistic it may look.

I will not go as far as calling the UEFI section of BOOTICE a hoax... but it certainly doesn't seem to do what it portrays to do. At least it doesn't work in WinPE, and not on my computer anyway.

Also... this whole idea feels backwards.

You don't use a tool named A to modify a property B in location C when its true location is D. In reality, this just means that BOOTICE can read your UEFI current boot entries (boot variable). As I have stated previously, these are just references or pointers to the disk locations where you have your bootloaders stored. It's no wonder that BOOTICE appears to fail to remove them, because as soon as you reboot the computer, your UEFI firmware automatically scans your disks anew and adds these variables back in to its internal boot priority override menu (F8 boot menu). This is done so by design.

If you really want to tackle these unneeded boot entries you see coming from your UEFI firmware, you have to do it at source, namely by modifying the bootloader and its configuration (GRUB config in case of Linux and BCD in case of newer Windows systems). The reason why BOOTICE is actually more successful when running from within a proper Windows installation, is actually by it calling BCDEdit or similar in the background, and modifying BCD.

Samir,

I do not wish to argue this point and have not done so even now.  If you take it that way my apologies.

The point is that the UEFI specification does not support your position.  Many users will agree with you that boot information is on a physical disk especially those who are big Linux users.  The point remains the same however, UEFI specification does not support that position.

The only place in my posts that is technically incorrect is my reference to VRAM, it should be NVRAM as in programmable chips found on motherboards.  The bios chips of old are no more.  They have been replaced by UEFI firmware chips with backward compatibility for Legacy/CSM support (MBR/BIOS Boot).

Below is a Wikipedia snip-it taken directly from the UEFI specification describing the boot sequence. The variables discussed below are in fact the boot priority entries you see in bios setup screens and one time boot menus.

UEFI booting

Unlike the legacy PC BIOS, UEFI does not rely on boot sectors, defining instead a boot manager as part of the UEFI specification. When a computer is powered on, the boot manager checks the boot configuration and based on its settings, then executes the specified OS boot loader or operating system kernel (usually boot loader[53]). The boot configuration is defined by variables stored in NVRAM, including variables that indicate the file system paths to OS loaders or OS kernels.

OS boot loaders can be automatically detected by UEFI, which enables easy booting from removable devices such as USB flash drives. This automated detection relies on standardized file paths to the OS boot loader, with the path varying depending on the computer architecture. The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is \efi\boot\bootx64.efi,[30] and \efi\boot\bootaa64.efi on ARM64 architecture.

 

Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting. Despite the fact that the UEFI specification requires GPT partition tables to be fully supported,[30] some UEFI firmware implementations immediately switch to the BIOS-based CSM booting depending on the type of boot disk's partition table, effectively preventing UEFI booting to be performed from EFI System Partition on MBR-partitioned disks.[43] Such a boot scheme is commonly called UEFI-MBR.

It is also common for a boot manager to have a textual user interface so the user can select the desired OS (or setup utility) from a list of available boot options.

Sorry you need to rant about who's right, wrong or otherwise.  Further, I do not need to prove you wrong, that has nothing to do with it.  In fact I do not need to do anything actually.  I simply desire to present the facts as they are.

I do not understand how you get to the point of the UEFI standard not being followed, can you clarify for me?

The bios chips of old are no more.  They have been replaced by UEFI firmware chips with backward compatibility for Legacy/CSM support (MBR/BIOS Boot).

How old? Is this a reference to the "Nonvolatile BIOS memory" above or to the "NVRAM"? I mean my motherboards with BIOS from year 2010 had 8 Mbit chips on them, "Dual-BIOS" even on Gigabyte branded boards (one for backup). I'm pretty sure those were Flash chips (ROM with NVRAM).

Version 2.0 of the UEFI specification was released on 31 January 2006. It added cryptography and security. Version 2.1 of the UEFI specification was released on 7 January 2007. It added network authentication and the user interface architecture ('Human Interface Infrastructure' in UEFI).

The latest UEFI specification, version 2.9, was published in March 2021.

The cryptogoaphy and security reference above relates to Secure Boot which is the real driver behind the UEFI spec.  The release of Version 2.0 of the spec January 31 2006 ushered in UEFI and adoption followed January 7 2007.

"Unlike the legacy PC BIOS, UEFI does not rely on boot sectors, defining instead a boot manager as part of the UEFI specification."

Where is this boot manager stored then?

The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is \efi\boot\bootx64.efi, and \efi\boot\bootaa64.efi on ARM64 architecture.

"The boot configuration is defined by variables stored in NVRAM, including variables that indicate the file system paths to OS loaders or OS kernels."

In other words, boot configuration is stored in NVRAM, and it's more than just path variables that indicate the location of OS bootloaders. I wonder then, what other kind of variables does a typical boot configuration hold? How are these boot configurations set from the beginning?

Since you asked what other kinds of variables does a typical configuration hold?  This is what MS has to say about that.

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/overv…

You will see reference to Bootcfg which is/was used to edit boot.ini files.  The BCD store as a UEFI application has replaced the boot.ini making it essentially obsolete along with Bootcfg which is now replaced by bcdedit.

"It is also common for a boot manager to have a textual user interface so the user can select the desired OS (or setup utility) from a list of available boot options."

This is the F8 boot menu I have in my photos above? Yes?

Yes, it also is what populates the boot priority section of the UEFI GUI interface (another UEFI application) that you posted earlier.  UEFI firmware stores the BCD store, the UEFI GUI interface, and other variables as specified by the OEM including PXE boot on most recent main stream desktop PC's.