Overwhelmed - Macrium Reflect

nikki605 · 2026-06-13T10:34:49-0400

Dirtyflash said:
I was tinkering and discovered something that may be obvious to others but was a surprise to me. I never realized I could simply turn off Memory Intergity in Windows Security which then allowed me to switch off Microsoft Vulnerable Driver Blocklist. Off course that come with it's own implications and requires a reboot for it to apply, but seems like an easy way to gain access to browsing saved images. Turning Memory Integrity back on is one click and a reboot which turns on the Microsoft Vulnerable Driver Blocklist on its own and locks it by greying out the switch.

I have rarely needed to mount an image to recover individual files since I have separate data file backups, but I knew this workaround existed if needed (Macrium 8 Free v8.0.7783). Full backup and restore still work fine as long as I keep using the update script @garlin created so my Rescue boot drive stays bootable when MS makes changes.

Steve C · 2026-06-13T11:02:00-0400

garlin said:
I believe most of the v8 users on this thread don't want to upgrade to X. Even if it properly supports CA 2023.

No, I paid the price for X on my imprtant desktop PC but not my less important laptops.

KevTech · 2026-06-13T11:56:01-0400

garlin said:
I believe most of the v8 users on this thread don't want to upgrade to X. Even if it properly supports CA 2023.

But it still does not.

Last WU updated SVN to 9 and I recreated the macrium PE thinking it would pickup the change.

It would not boot as there was a SVN mismatch so got a secure boot violation error.

garlin · 2026-06-13T12:07:10-0400

June 2026 both introduces a new boot manager (SVN 9.0) and a new SkuSiPolicy (3.0.0.15). If you're using SkuSiPolicy, this restricts using the previous winload.efi in the boot.wim, requiring a newer updated image.

Klaver7 · 2026-06-13T12:14:43-0400

Still using Macrium v8.0.7783 Free and with the updated (SVN 9.0) and a new SkuSiPolicy (3.0.0.15), I create a new Bootable PE, like in april also and all work well, boots up fine with c2023.

oreyro · 2026-06-13T12:53:49-0400

garlin said:
June 2026 both introduces a new boot manager (SVN 9.0) and a new SkuSiPolicy (3.0.0.15). If you're using SkuSiPolicy, this restricts using the previous winload.efi in the boot.wim, requiring a newer updated image.

Macrium Reflect + WinPE 26100(2024/12) creates a MacriumResque.iso(BOOT ISO) with bootx64.efi Bootloader(CA2023 certificate) ver. 10.0.26100.30227
WinPE 28000(2025/11) has bootx64.efi bootloader(CA2023 certificate) ver. 10.0.27954.300

Questions:
1. What version of bootx64.efi should you have in order for Macrium BOOT ISO (UEFI CA2023; WinPE) to work with all versions of Windows 10 / 11?
2. Is it enough to replace only the bootx64.efi file in the MacriumResque.iso\EFI\Boot\bootx64.efi folder? ... Or do I need to replace any other files?

MysteryGuy · 2026-06-13T13:50:18-0400

oreyro said:
Macrium Reflect + WinPE 26100(2024/12) creates a MacriumResque.iso(BOOT ISO) with bootx64.efi Bootloader(CA2023 certificate) ver. 10.0.26100.30227
WinPE 28000(2025/11) has bootx64.efi bootloader(CA2023 certificate) ver. 10.0.27954.300

Questions:
1. What version of bootx64.efi should you have in order for Macrium BOOT ISO (UEFI CA2023; WinPE) to work with all versions of Windows 10 / 11?
2. Is it enough to replace only the bootx64.efi file in the MacriumResque.iso\EFI\Boot\bootx64.efi folder? ... Or do I need to replace any other files?

Have you looked at the entry at

How to "fix" Secure Boot violation due to certificate revocations. - (Page 2)

There is an entry from jimrf97 at the end with a .bat file that looks promising and might help.

You run it on your system targeting the USB boot-able drive.

As I understand it, it sounds like the MS changes involve a series of steps over time starting with adding the new certificates to your windows and ultimately (possibly) removing the old certificates from both Windows and the BIOS.

I tried this .bat file a few months back and it seemed to work on a boot-able USB. But I don't think my system was (is?) yet 'all the way through' the complete MS process.

garlin · 2026-06-13T15:22:30-0400

oreyro said:
Macrium Reflect + WinPE 26100(2024/12) creates a MacriumResque.iso(BOOT ISO) with bootx64.efi Bootloader(CA2023 certificate) ver. 10.0.26100.30227
WinPE 28000(2025/11) has bootx64.efi bootloader(CA2023 certificate) ver. 10.0.27954.300

Questions:
1. What version of bootx64.efi should you have in order for Macrium BOOT ISO (UEFI CA2023; WinPE) to work with all versions of Windows 10 / 11?
2. Is it enough to replace only the bootx64.efi file in the MacriumResque.iso\EFI\Boot\bootx64.efi folder? ... Or do I need to replace any other files?

To answer this question, we need to first understand how the boot manager security model works for W10 22H2/W11.

1. Let's assume you have the right signed version of the boot files for your Secure Boot status (CA 2011 vs CA 2023). That's one problem to solve.

2. The next security hurdle is MS created the SVN as a marker to prevent attackers from using an outdated boot manager. SVN works as a second layer of protection. When the signed boot manager runs, it checks its own SVN number (embedded inside the boot file), and compares that SVN against what's stored in the UEFI DBX's variable.

If you have not banned PCA 2011, then there is no SVN present in your UEFI. The PCA 2011 certificate has nothing to do with SVN, but the process which applies the ban on PCA 2011 happens to install a SVN number to the DBX at the same time. You will get a starting value for SVN. And this SVN may be bumped up to a more current (higher) number later in the Secure Boot migration process.

3. The SVN in the boot manager and the SVN in the DBX are supposed to be changed in lockstep. A new boot manager arrives to replace the old one, because MS has closed a known security hole. MS does not want attackers abusing the old boot manager to gain privileged access.

If you regularly install the Monthly Updates, the boot manager and DBX SVN may be simultaneously updated, or it might stay unchanged for a while. The last few instances of a new boot manager happened in Dec 2025 (SVN 7.0), April 2026 (SVN 8.0) and June 2026 (SVN 9.0). There is no pre-determined release schedule, as MS is simply fixing security holes as they're reported.

Because the rule is your boot manager has own a SVN equal or higher than the DBX SVN in order to boot, you can take the latest boot manager file on an updated Windows and use it on any system. A drive which has the June 2026 boot manager could be used on a system which have not received the latest Windows Updates (assuming the Secure Boot cert status is correct).

The boot manager only has one job, check to see if it's eligible to run (not blocked) and then it hands off control to winload.efi (which actually starts up Windows or WinPE/WinRE). It's not the file version of boot manager that's important as much as the SVN for it.

From PowerShell you can run a simple command to determine a boot file's SVN (replace filename with your boot file):

Code:

> Get-SecureBootSVN -BootManagerPath C:\Windows\Boot\EFI_EX\bootmgfw_EX.efi

FirmwareSVN      : 8.0
BootManagerSVN   : 9.0  <-- this
StagedSVN        : 9.0
ComplianceStatus : Not compliant (Firmware does not match boot manager)
BootManagerPath  : C:\Windows\Boot\EFI_EX\bootmgfw_EX.efi

garlin · 2026-06-13T19:12:41-0400

Alv_B said:
FirmwareSVN : 0.0

CA 2011 cert has not been revoked on this PC. It's still optional for now, and MS won't force mandatory revocation until later this year.
Because you don't have CA 2011 copied to the DBX (banned list), you never got a starting SVN installed.

0.0 = SVN enforcement is off. Other Secure Boot enforcements for certs will still apply.

Alv_B said:
BootManagerSVN : 8.0
StagedSVN : 8.0

Windows Update has not installed June 2026 (SVN 9.0). This PC is running April or May 2026.
Since you have a FirmwareSVN of 0.0 (none), your current boot manager (SVN 8.0) is allowed. 8 > 0.

Alv_B said:
I have the certificates in BIOS updated to 2023, I don't know if that has anything to do with it. All this is beyond me.

There are two phases in the CA 2023 migration. Phase 1 is to install CA 2023 certs to allow CA 2011 to be banned, and you need it anyway since the CA 2011 certs are expiring and cannot be used to validate new files. Phase 2 is to ban CA 2011 after support for CA 2023 is added.

Right now, you're in dual mode. Boot manager files using either the old CA 2011 or new CA 2023 are eligible for booting. Your USB drive can use both versions. But after you complete Phase 2, CA 2011 will be banned and your USB drives will have to use only the CA 2023 versions.

You can force CA 2011 revocation now, and not wait for MS. All that means is you will have to replace the boot files on your USB devices afterwards. Windows will take care of the system drive, but it doesn't have responsibility for any USB boot media.

Alv_B · 2026-06-13T19:15:12-0400

When I run your command, here's what I get:

Code:

Get-SecureBootSVN -BootManagerPath C:\Windows\Boot\EFI_E\bootmgfw_EX.efi

FirmwareSVN : 0.0
BootManagerSVN : 8.0
StagedSVN : 8.0
ComplianceStatus : Not compliant (Staged SVN does not match firmware SVN)
BootManagerPath : C:\Windows\Boot\EFI_EX\bootmgfw_EX.efi

The FirmwareSVN version I get is 0.0. What does it mean and what implications does it have? How can it be a version 0.0? I have the certificates in BIOS updated to 2023, I don't know if that has anything to do with it. All this is beyond me.

Dirtyflash · 2026-06-13T20:44:34-0400

Alv_B said:
When I run your command, here's what I get:

Code:

Get-SecureBootSVN -BootManagerPath C:\Windows\Boot\EFI_E\bootmgfw_EX.efi FirmwareSVN : 0.0 BootManagerSVN : 8.0 StagedSVN : 8.0 ComplianceStatus : Not compliant (Staged SVN does not match firmware SVN) BootManagerPath : C:\Windows\Boot\EFI_EX\bootmgfw_EX.efi

The FirmwareSVN version I get is 0.0. What does it mean and what implications does it have? How can it be a version 0.0? I have the certificates in BIOS updated to 2023, I don't know if that has anything to do with it. All this is beyond me.

I think @garlin was suggesting you would need to revoke the 2011 certificate which will in turn update your SVN from 0.0 to a higher number, likely 8.0.

oreyro · 2026-06-14T04:24:41-0400

garlin said:
To answer this question, we need to first understand how the boot manager security model works for W10 22H2/W11.

Thanks for the interesting information, but I'm interested in a PRACTICAL question:
HOW to use MacriumResque.iso (BOOT ISO) to create a backup of all system partitions of ANY Windows 10/11, IF Secure Boot is enabled on the computer?

The computer's BIOS, in the case of a Secure Boot, acts as a "guard", but the BIOS has limited resources, so it can only check
- file name,
- file Certificate number,
- file ver. number.
As far as I understand, the BIOS will check the Certificates (it should be UEFI CA2023) and (possibly) the file ver. numbers (what should be the ver. number?) these files MacriumResque.iso :
1. MacriumResque.iso\efi\boot\bootx64.efi
2. MacriumResque.iso\efi\microsoft\boot\efisys_ex.bin
Why exactly these files(bootx64.efi and efisys_ex.bin) ?
Microsoft has released the Make2023BootableMedia.ps1 script

Updating Windows bootable media to use the PCA2023 signed boot manager - Microsoft Support

support.microsoft.com

to update the Bootloader(PCA2011) to (UEFI CA2023) for any Windows 10/11(BOOT ISO) released in 2024/05 - 2026/06
If you apply this script to Windows 11 24H2(BOOT ISO), you will see that it is these Bootloader files(bootx64.efi and efisys_ex.bin) will be replaced and will receive a new (UEFI CA2023) certificate.

garlin · 2026-06-14T04:57:39-0400

The problem is you're asking for any W10/11 computer, and you can't have an universal boot media if Secure Boot is enabled.

Four valid possibilities exist for Secure Boot certs:

1. Secure Boot is disabled. It doesn't matter what you use, any CA 2011 or CA 2023 boot file works.

2. Secure Boot is enabled, but only CA 2011 exists. The PC doesn't have CA 2023 installed, because there is no BIOS update or Windows automatic update available for this unsupported PC. It might be updated by manual intervention, but the user doesn't know how. So it's trapped on CA 2011.

The boot manager must be CA 2011, since Secure Boot only recognizes CA 2011. This is the "unsupported PC".

3. Secure Boot is enabled, both CA 2011 and CA 2023 are installed. CA 2011 has not been revoked yet. Either version of the boot manager works, because both sets of certs are currently trusted. This is where half of the Windows users are today, both sets of certs but revocation has not happened yet.

Eventually MS will force a mandatory revocation, but until then any boot media works.

4. Secure Boot is enabled, both CA 2011 and CA 2023 are installed, but CA 2011 is revoked. Only CA 2023 boot manager that has a higher SVN can be used for the boot media.

In cases 1 & 3, any version of the boot file works.

In case 2, only CA 2011 works.

In case 4, only CA 2023 works.

UEFI only checks that the signing cert of the boot file (bootmgfw.efi or bootx64.efi, if the first filename is missing) is eligible based on the current combination of PK/KEK/DB/DBX certs. That's it, UEFI only cares about the signing cert. It doesn't care about version numbers, sizes, etc.

When the Windows boot manager runs, it will check if SVN is enforced by a DBX SVN entry. The boot manager knows its own SVN number, and compares its value against the DBX SVN. If the DBX SVN is higher than boot manager's version, boot manager voluntarily stops running and throws a security violation error. SVN enforcement is handled by the boot manager, and not by UEFI.

A boot file can only be signed by one cert (not technically true, but for our discussion we'll assume that for simplicity). This signing cert can be CA 2011, CA 2023, or even a 3rd-party cert someone has created (like for Linux).

\Windows\Boot\EFI -> boot files signed by CA 2011
\Windows\Boot\EFI_EX -> boot files signed by CA 2011

The two parallel sets of boot files are identical programs, except for their signing certs. Whether you use the Make2023BootableMedia.ps1, my script, someone else's script or manual copying, doesn't really matter if you follow the rules.

If you have a WinPE based media, you need to copy EFI\bootmgfw.efi (2011) or EFI_EX\bootmgfw_EX.efi (2023) -> \EFI\Boot\bootx64.efi

If you have a WinRE based media, you need to copy the same file to \EFI\Microsoft\Boot\bootmgfw.efi. In reality, you shouldn't just copy a few files. There are more files that matter for WinRE, but it's safer to use the bcdboot command, since it was created for this role.

Here's my script which performs a check of the current system, and decides whether to replace the boot files on the USB media.

oreyro · 2026-06-14T05:53:50-0400

garlin said:
In case 2, only CA 2011 works.In case 4, only CA 2023 works.

Ok..
Comparison:
which files of the old loader (PCA 2011) are replaced by files of the new loader (UEFI CA 2023) in ISO Windows and ISO Macrium

(1) ISO-Windows 11 24H2 (the official MS script was used to update the bootloader)
Windows.iso\efi\boot\bootx64.efi
Windows.iso\efi\microsoft\boot\efisys_ex.bin
***
(2) ISO-Macrium 10.0.8750 (used to create ISO(UEFI CA2023) pe11Dec24x64x.zip)
MacriumResque.iso\EFI\Boot\bootx64.efi
MacriumResque.iso\EFI\Microsoft\Boot\bootmgfw.efi
MacriumResque.iso\Boot\efisys_noprompt.bin
MacriumResque.iso\Boot\efisys_prompt.bin
***
PS
result:
The "Windows" Bootloader and the "MacriumResque" Bootloader are working correctly, but they use different boot scripts...
... or Bootloader "MacriumResque" is not working properly.

man00 · 2026-06-14T12:30:30-0400

garlin said:
The problem is you're asking for any W10/11 computer, and you can't have an universal boot media if Secure Boot is enabled.

Four valid possibilities exist for Secure Boot certs:

1. Secure Boot is disabled. It doesn't matter what you use, any CA 2011 or CA 2023 boot file works.

2. Secure Boot is enabled, but only CA 2011 exists. The PC doesn't have CA 2023 installed, because there is no BIOS update or Windows automatic update available for this unsupported PC. It might be updated by manual intervention, but the user doesn't know how. So it's trapped on CA 2011.

The boot manager must be CA 2011, since Secure Boot only recognizes CA 2011. This is the "unsupported PC".

3. Secure Boot is enabled, both CA 2011 and CA 2023 are installed. CA 2011 has not been revoked yet. Either version of the boot manager works, because both sets of certs are currently trusted. This is where half of the Windows users are today, both sets of certs but revocation has not happened yet.

Eventually MS will force a mandatory revocation, but until then any boot media works.

4. Secure Boot is enabled, both CA 2011 and CA 2023 are installed, but CA 2011 is revoked. Only CA 2023 boot manager that has a higher SVN can be used for the boot media.

In cases 1 & 3, any version of the boot file works.
In case 2, only CA 2011 works.
In case 4, only CA 2023 works.

UEFI only checks that the signing cert of the boot file (bootmgfw.efi or bootx64.efi, if the first filename is missing) is eligible based on the current combination of PK/KEK/DB/DBX certs. That's it, UEFI only cares about the signing cert. It doesn't care about version numbers, sizes, etc.

When the Windows boot manager runs, it will check if SVN is enforced by a DBX SVN entry. The boot manager knows its own SVN number, and compares its value against the DBX SVN. If the DBX SVN is higher than boot manager's version, boot manager voluntarily stops running and throws a security violation error. SVN enforcement is handled by the boot manager, and not by UEFI.

A boot file can only be signed by one cert (not technically true, but for our discussion we'll assume that for simplicity). This signing cert can be CA 2011, CA 2023, or even a 3rd-party cert someone has created (like for Linux).

\Windows\Boot\EFI -> boot files signed by CA 2011
\Windows\Boot\EFI_EX -> boot files signed by CA 2011

The two parallel sets of boot files are identical programs, except for their signing certs. Whether you use the Make2023BootableMedia.ps1, my script, someone else's script or manual copying, doesn't really matter if you follow the rules.

If you have a WinPE based media, you need to copy EFI\bootmgfw.efi (2011) or EFI_EX\bootmgfw_EX.efi (2023) -> \EFI\Boot\bootx64.efi

If you have a WinRE based media, you need to copy the same file to \EFI\Microsoft\Boot\bootmgfw.efi. In reality, you shouldn't just copy a few files. There are more files that matter for WinRE, but it's safer to use the bcdboot command, since it was created for this role.

Here's my script which performs a check of the current system, and decides whether to replace the boot files on the USB media.

That zip file won't open and Windows Security deletes it

garlin · 2026-06-14T12:35:41-0400

Rename this file, by removing the .txt extension. There's no tricky security hack, it's all reading and copying files.

Overwhelmed - Macrium Reflect

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Member

My Computer

Member

My Computer

New member

My Computer

Well-known member

My Computer

Well-known member

My Computer

New member

My Computer

Well-known member

My Computer

Member

My Computer

Well-known member

Attachments

My Computer

Member

My Computer

Well-known member

My Computer

Well-known member

Attachments

My Computer

Similar threads