Tech Discussion: Inability to Modify Secure Boot and Boot Order After System Restore

[admin]

Hello everyone,

Today we encountered a case and would like to share it for discussion.

A user reported that after restoring a system partition using Hasleo Backup Suite, Windows failed to boot normally. When attempting to recover from a USB drive, the user found that Secure Boot could not be disabled in the BIOS, and the boot order reset to default after every reboot. The user insisted that the software had corrupted the ESP partition during the restore process, causing these issues.

Our technical analysis is as follows:

1. Secure Boot and the boot order are UEFI firmware settings stored in the motherboard's NVRAM, not on the hard disk.
   
2. During restoration, Hasleo Backup Suite only modifies data on the disk's ESP (EFI System Partition), Windows partition, and recovery partition; it does not change any firmware settings.
   
3. The ESP only stores boot loader files. Modifying or corrupting the ESP only affects the system boot process, it does not affect the ability to modify BIOS settings.
   

Based on the above, we believe this issue is more likely caused by a firmware bug or hardware failure rather than by the software operation.

We would like to ask: Have any of you encountered similar situations where BIOS settings appear "locked" in your maintenance work? We welcome your insights and experience.

Best regards,

[n8chavez]

I have not encountered any such situation. But, now that I know what I'm looking for, I will test thoroughly tomorrow and report back. Not quite the same, but if I manually select another uefi partition, that partition will become the default selection until I manually change it back. This is not reset after every reboot, nor is this an HBS issue. This happens independent of any imaging application.

[al3x]

Hi,

there seems to be a new UEFI behavior for very new OEM builds. I've never seen this before but here a user wrote about this:
https://www.reddit.com/r/MiniPCs/comment...cht/?tl=en

Untitled
.theme-light,:root{--rem360:22.5rem;--rem320:20rem;--rem192:12rem;--rem144:9rem;--r…

Basically, according to the user, MS seems to force Secure Boot to be on in "PreInstall" mode until a signed OS was fully booted for the first time. After that, all UEFI settings were accessible.

I don't know if that's what's happening here after the HBS restore, maybe the firmware settings automatically roll back as a security feature? Never seen or heard something like that, though.

[admin]

I have not encountered any such situation.  But, now that I know what I'm looking for, I will test thoroughly tomorrow and report back.  Not quite the same, but if I manually select another uefi partition, that partition will become the default selection until I manually change it back.  This is not reset after every reboot, nor is this an HBS issue.  This happens independent of any imaging application.

The user said that after the restore, he cannot change Secure Boot and boot order settings in the BIOS. That seems a bit different from your situation. We've never encountered this before.

[admin]

@al3x,

Thanks for sharing that information, that's an interesting theory about the "PreInstall" mode on newer UEFI systems.

However, in this particular case, I don't think that's what's happening. The user has been using Hasleo Backup Suite for quite some time and has already performed backup operations before. So this definitely isn't the first boot of a signed OS, the system has been up and running normally for a while.

If this actually turns out to be some new "security feature" from Microsoft that locks down UEFI settings until a signed OS completes its first boot, then I honestly have to say Microsoft really loves to make things unnecessarily complicated.

That said, I still lean toward this being a firmware bug or a hardware issue rather than something caused by the restore operation or some exotic UEFI lockdown mechanism.

Has anyone else here actually encountered this "PreInstall" mode behavior on a system that wasn't brand new out of the box? Would be curious to know.

Best regards,

[garioch7]

@admin,

As you know, I only do weekly Disk/Partition backups of all partitions.  My venerable 2019 Dell XPS 8930 SE was manually updated by to the 2023 certificates about a month ago, and the last HBS ED created a couple of weeks ago, without incident, and the HBS backup ran and checked without incident.

I have not seen any reports of this in the Forums that I haunt.

I will be interested in finding out what caused the problem for the user.  Sorry that I cannot be of more help.

Have a great day.

Regards,
Phil

[AdvancedSetup]

I am with you @Admin

The imaging process cannot alter the firmware BIOS

Perhaps the user may not have fully understood how to use the feature as some motherboards are very flaky on how they change things.

Some motherboards also have settings that do reset on reboot as they're temporary on purpose but those are often for over-clocking and not wanting to lock in a value that's bad.

[rogerrabbit]

Hi,
by hazard I did a restore yesterday. So I tested immediately after having read your thread.
I had no problem to change my boot order, nor disabling secure boot (and re-enabling it afterwards).
Windows version: 11 25 H 26200.8737; Motherboard: Gigabyte H610M H V2 DDR4; BIOS: American Megatrends F34
Regards Roger

[admin]

Thank you all for your replies and attention!

This issue is indeed extremely rare. Over the years, Hasleo Backup Suite has served a large number of users, and this is the very first case of its kind we have ever encountered. Therefore, we are more inclined to believe that the problem stems from the user's motherboard firmware, rather than being caused by the software operation.

I would especially like to thank @AdvancedSetup for your support. Receiving recognition and encouragement from an expert like you is a great motivation for me, and it further strengthens my confidence in our technical assessment.

As for this user, he has explicitly stated that he no longer trusts Hasleo and insists that the issue is software‑related. To be honest, I've recently been frustrated by a few users with a similar attitude,  no matter how we explain the technical principles, they simply refuse to listen. We respect every user's choice, but facing such communication deadlocks is indeed disheartening.

Nevertheless, we will always remain committed to providing professional technical support and high‑quality products and services. Once again, thank you all for your participation and valuable feedback!

Feel free to continue the discussion and share your thoughts.

Best regards,