Cannot boot into a USB installer because of a Security Violation

T

tired-it

Member
It looks like the UEFI security fixes that I have been reading about were in May Cumulative update because I seemingly cannot get a test image to boot on a PC now.

For more context, I have a Windows 11 23H2 test image that had April's cumulative updates. It installed fine on a test PC and I allowed Windows Update to install the May cumulative update. Wanting to skip the lengthy installation time, I wanted to update the test image to include May's updates. Everything about the image was the same except for the updates. The image was copied onto a USB using Rufus as usual.

The following error pops when trying to boot into the USB:

[Fail] Load Failure: [26] Security Violation

I noticed that NTLite suggested I update the bootloader and integrate the cumulative update to the "boot.wim 2. Microsoft Windows Setup" file. I followed those suggestions, or at least I think I did so correctly. Any ideas on how to get a bootable image?
 
Yes, that is the new normal that will happen more and more with an older ISO, however there should be a solution.
More info here.

Basically once your machine was tagged to ignore older boot managers, it requires the image to be updated.
Maybe the updating process is not perfect, as I haven't gotten any feedback so far.
Or the steps on that page above lists extra actions to enable the new updates.
There was a previous stage, but this new one in combination with previous is a mess.

As far as it goes, I'm open for reports and the ideas how to help automate the transition.
If anyone does it manually successfully, let me know what was done to see if I missed something.

When updating the next time, fresh, make sure to:
- load Install.wim edition you want to use
- add the updates to the Updates page
- enable Update boot managers in the toolbar
- on the Apply page use Reapply - Integrate Updates - Boot.wim Setup
- Process when ready

If that doesn't help, test the image on the fresh VM, to make sure it can boot on a non-tagged machine.
Then let me know how far you got on the Microsoft page, which mitigations did you enable now or in the past etc.
 
This whole UEFI bootmgr rollout has been kinda ass.

The most direct and simplest solution would be MS providing the required bootmgr files in a standalone CAB. But I strongly suspect some stupid product manager somewhere has decided this allows users to more easily continue supporting older Windows builds.

If you read the current guidance (which is confusing), MS recommends one of two paths:
1. Download the latest ADK, and build an image from its bootmgr files. But we all know ADK stops updating as soon as it's released, which means that bootmgr is already outdated compared to the CU version(s).

2. Install the latest LCU on a live system, and copy bootmgr FROM THIS UPDATED SYSTEM. wtf?

Plus, they don't have a definitive way to check if you have a correct version (other than failing to boot on a revoked PC). There's some instructions to search the bootmgr's security certificate chain for a specific authority.

But that's OK, according to MS they have until July 2024 to provide some real guidance. My point is there's several versions of the same file floating out there, and they should provide a simple PS script to inform you if you're using the right (or approved) one.
 
garlin said:
This whole UEFI bootmgr rollout has been kinda ass.

The most direct and simplest solution would be MS providing the required bootmgr files in a standalone CAB. But I strongly suspect some stupid product manager somewhere has decided this allows users to more easily continue supporting older Windows builds.

If you read the current guidance (which is confusing), MS recommends one of two paths:
1. Download the latest ADK, and build an image from its bootmgr files. But we all know ADK stops updating as soon as it's released, which means that bootmgr is already outdated compared to the CU version(s).

2. Install the latest LCU on a live system, and copy bootmgr FROM THIS UPDATED SYSTEM. wtf?

Plus, they don't have a definitive way to check if you have a correct version (other than failing to boot on a revoked PC). There's some instructions to search the bootmgr's security certificate chain for a specific authority.

But that's OK, according to MS they have until July 2024 to provide some real guidance. My point is there's several versions of the same file floating out there, and they should provide a simple PS script to inform you if you're using the right (or approved) one.
Click to expand...
Yeah I have not been a fan of MSoft's handling of this. It's like the Windows 11 requirements all over again. So if I wanted to make this easier, I could theoretically copy a file from an updated system?
 
I think it would be easier for MS Security and Windows team (like a principal dev) to write a white paper explaining what changes they're rolling out. Presenting the steps without context is useless, because you have no idea why you're running the command. Or why you shouldn't skip certain steps for everything to work.

Like what's magic in the bcdstore that needs be tweaked?
 
nuhi said:
Yes, that is the new normal that will happen more and more with an older ISO, however there should be a solution.
More info here.

Basically once your machine was tagged to ignore older boot managers, it requires the image to be updated.
Maybe the updating process is not perfect, as I haven't gotten any feedback so far.
Or the steps on that page above lists extra actions to enable the new updates.
There was a previous stage, but this new one in combination with previous is a mess.

As far as it goes, I'm open for reports and the ideas how to help automate the transition.
If anyone does it manually successfully, let me know what was done to see if I missed something.

When updating the next time, fresh, make sure to:
- load Install.wim edition you want to use
- add the updates to the Updates page
- enable Update boot managers in the toolbar
- on the Apply page use Reapply - Integrate Updates - Boot.wim Setup
- Process when ready

If that doesn't help, test the image on the fresh VM, to make sure it can boot on a non-tagged machine.
Then let me know how far you got on the Microsoft page, which mitigations did you enable now or in the past etc.
Click to expand...
I appreciate the information. Unfortunately, my third attempt at this still produced the same boot error. The base image does indeed work by itself elsewhere. Any ideas on the next steps?

Small suggestion: If a user toggles the Update Boot Manager option on, then automatically enqueue and integrate the latest cumulative update?
 
tired-it said:
I appreciate the information. Unfortunately, my third attempt at this still produced the same boot error. The base image does indeed work by itself elsewhere. Any ideas on the next steps?

Small suggestion: If a user toggles the Update Boot Manager option on, then automatically enqueue and integrate the latest cumulative update?
Click to expand...
Btw it's not the same what method you use to create a bootable USB.
Try different tool, Ventoy and Rufus are the most popular ones, while on Rufus there are various options and they talk a lot about these issues on their forum.

Until more is known, try getting the latest ISO from here:

If that one doesn't boot without any editing, then we can talk more.
If it does boot, let me know if it still does after an edited ISO creation from NTLite.
 
nuhi said:
Btw it's not the same what method you use to create a bootable USB.
Try different tool, Ventoy and Rufus are the most popular ones, while on Rufus there are various options and they talk a lot about these issues on their forum.

Until more is known, try getting the latest ISO from here:

If that one doesn't boot without any editing, then we can talk more.
If it does boot, let me know if it still does after an edited ISO creation from NTLite.
Click to expand...
I have only ever used Rufus. Also, I have that exact ISO already, but I downloaded it regardless.

The flash drive boots with the original ISO. An edited ISO is where the issues popup.

Update: Only updated the ISO with the option for updating the boot sector toggled on. Still did not boot. Going to try without updating the boot sector to rule that out.
 
Last edited:
Update: Used an updated ISO without the boot update toggled on. The image booted. Maybe the system did not actually update its boot files? I had Windows 10 fully updated on the system and expected the latest cumulative update to have those mitigations.

So it looks like I may have overlooked an important detail.
 
Before i did the Bios update in a Sysprep a reboot showed a empty bootpartition for the sysprepped image.
After updating the Bios as showed in upperpost everything got back to normal.
I'm using Ventoy, as it works great with bootable ISOs files.
 
You must log in or register to reply here.
Back
Top