KB5042562 Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates


  • Staff

 Microsoft Support:

Summary

Microsoft was made aware of a vulnerability in Windows that allows an attacker with administrator privileges to replace updated Windows system files that have older versions, opening the door for an attacker to reintroduce vulnerabilities to Virtualization-based security (VBS). Rollback of these binaries might allow an attacker to circumvent VBS security features and exfiltrate data that is protected by VBS. This issue is described in CVE-2024-21302 | Windows Secure Kernel Mode Elevation of Privilege Vulnerability.

To resolve this issue, we will revoke vulnerable VBS system files that are not updated. Because of the large number of VBS-related files that must be blocked, we use an alternative approach to block file versions that are not updated.

Scope of Impact

All Windows devices that support VBS are affected by this issue. This includes on-premises physical devices and virtual machines (VMs). VBS is supported on Windows 10 and later Windows versions, and Windows Server 2016 and later Windows Server versions.

The VBS state can be checked through the Microsoft System Information tool (Msinfo32.exe). This tool collects information about your device. After starting Msinfo32.exe, scroll down to the Virtualization-based security row. If the value of this row is Running, VBS is enabled and running.

System Information dialog box with the Virtualization-based security row highlighted


The VBS state can also be checked with Windows PowerShell by using the Win32_DeviceGuard WMI class. To query the VBS state from PowerShell, open an elevated Windows PowerShell session and then run the following command:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

After running the above PowerShell command, the VBS state status should be one of the following.

Field nameStatus
VirtualizationBasedSecurityStatus
  • If the field equals 0, VBS is not enabled.
  • If the field equals 1, VBS is enabled but not running.
  • If the field equals 2, VBS is enabled and running.

Available mitigations

For all supported versions of Windows 10, version 1809 and later Windows versions, and Windows Server 2019 and later Windows Server versions, administrators can deploy a Microsoft-signed revocation policy (SkuSiPolicy.p7b). This will block vulnerable versions of VBS system files that are not updated from being loaded by the operating system.

Note Additional mitigations and mitigation support for all supported versions of Windows 10, version 1507 and earlier Windows versions, and Windows Server 2016 and earlier Windows Server versions are planned for future updates.


When this policy is applied to a Windows device, the policy will also be locked to the device by adding a variable to the UEFI firmware. During startup, the policy loads and Windows blocks the loading of binaries that violate the policy. If the UEFI lock is applied and the policy is removed or replaced with an older version, the Windows boot manager will not start, and the device will not start. This boot failure will not show an error and the system will proceed to the next available boot option which might result in a boot loop.

For the policy mitigation to work, the device must be updated with the Windows update released on or after August 13, 2024. If updates are missing, the device might not start with the mitigation applied or the mitigation may not work as expected. Additionally, mitigations described in KB5025885 should be applied to your device.

Important Do not apply this mitigation to Windows versions earlier than Windows 10, version 1809 or versions of Windows Server earlier than Windows Server 2019. If the mitigation is applied to devices that are unsupported, the devices will not start and you receive an error 0xc0000428. You will need to follow the instructions in the Policy removal and recovery procedure section to recover.

e2043db2-1589-4759-be6b-d3470111dccd.png


Understanding mitigation risks

You need to be aware of potential risks before applying the Microsoft-signed revocation policy. Please review these risks and make any necessary updates to recovery media before applying the mitigation.
  • User Mode Code Integrity (UMCI). The Microsoft-signed revocation policy enables user mode code integrity so that rules in the policy are applied to user mode binaries. UMCI also enables Dynamic Code Security by default. Enforcing these features may introduce compatibility issues with applications and scripts and may prevent them from running and have a performance impact on start up time. Before deploying the mitigation, follow the instructions to deploy audit mode policy to test for potential issues.
  • UEFI Lock and Uninstalling updates. After applying the UEFI lock with the Microsoft-signed revocation policy on a device, the device cannot be reverted (by uninstalling Windows updates, by using a restore point, or by other means) if you continue to apply Secure Boot. Even reformatting the disk will not remove the UEFI lock of the mitigation if it has already been applied. This means that if you attempt to revert the Windows OS to an earlier state that does not have the applied mitigation, the device will not start, no error message will be displayed, and UEFI will proceed to the next available boot option. This might result in a boot loop. You must disable Secure Boot to remove the UEFI lock. Please be aware of all possible implications and test thoroughly before you apply the revocations that are outlined in this article to your device.
  • External Boot Media. After the UEFI lock mitigations have been applied to a device, external boot media must be updated with the Windows updates tht are dated on or after August 13, 2024 and with the Microsoft-signed revocation policy (SkuSiPolicy.p7b). If external boot media is not updated, the device might not boot from that media. See the instructions in the Updating external boot media section before applying the mitigations.

    Boot media that is updated with the Microsoft-signed revocation policy, must only be used to boot devices that have the mitigation already applied.  If it is used with devices without the mitigation, the UEFI lock will be applied during startup from the boot media. Subsequent starts from disk will fail, unless the device is updated with the mitigation or the UEFI lock is removed.
  • Windows Recovery Environment. The Windows Recovery Environment (WinRE) on the device must be updated with the Windows updates dated on or after August 13, 2024 before the SkuSipolicy.p7b is applied to the device. Omitting this step might prevent WinRE from running the Reset PC feature. For more information, see Add an update package to Windows RE.
  • Preboot Execution Environment (PXE) boot. If the mitigation is deployed to a device and you attempt to use PXE boot, the device will not start unless the mitigations are also applied to the network boot sources (root where bootmgfw.efi is present). If a device starts from a network boot source that has the mitigation applied, then the UEFI lock will apply to the device and impact subsequent starts. We do not recommend deploying mitigations to network boot sources unless all devices in your environment have the mitigations deployed.

Mitigation deployment guidelines

To address the issues described in this article, you can deploy a Microsoft-signed revocation policy (SkuSiPolicy.p7b). This mitigation is only supported on Windows 10, version 1809 and later Windows versions, and Windows Server 2019 and later Windows Server versions. Before you deploy the Microsoft-signed revocation policy (SkuSiPolicy.p7b), you should test for compatibility issues by using an audit mode policy.

Note If you use BitLocker, make sure that your BitLocker recovery key has been backed up. You can run the following command from an Administrator command prompt and take note of the 48-digit numerical password:

manage-bde -protectors -get %systemdrive%


Deploying an audit mode policy

The Microsoft-signed revocation policy (SkuSiPolicy.p7b) enforces user mode code integrity (UMCI) and Dynamic Code Security. These features may have compatibility issues with customer applications. Before deploying the mitigation, you should deploy an audit policy to detect compatibility issues.

You have two audit policy options:
  • Use the provided SiPolicy.p7b audit policy,
  • Or, compile your own audit policy binary from a provided XML file.
We recommend using the provided SiPolicy.p7b audit policy binary unless you have already deployed an existing Windows Defender Application Guard (WDAC) policy. The provided audit policy binary will not be UEFI locked. External boot media and recovery media do not need to be updated before applying the audit policy.

Windows Code Integrity will evaluate user and kernel mode binaries against the rules in the audit policy. If code integrity identifies an application or script in violation of the policy, a Windows Event log event will be generated with information about the blocked application or script and information about the enforced policy. These events can be used to determine if there are incompatible applications or scripts being used on your device. For more information, see the Windows Event logs section.


 Use the SiPolicy.p7b audit policy

The SiPolicy.p7b audit policy is included in the Windows update dated on or after August 13, 2024 for all supported Windows operating systems of Windows 10, version 1809 and later Windows versions, and Windows Server 2019 and later Windows Server versions. This audit policy should only be applied to devices that have the August 13, 2024 or later Windows update installed or the audit policy may not behave as expected.

To deploy the provided SiPolicy.p7b audit policy, follow these steps:
  1. Run the following commands from an elevated Windows PowerShell prompt:

    Code:
    # Initialize policy location and destination
    $PolicyBinary = $env:windir+"\System32\SecureBootUpdates\VbsSI_Audit.p7b"
    $DestinationBinary = $env:windir+"\System32\CodeIntegrity\SiPolicy.p7b"
    # Copy the audit policy binary
    Copy-Item -Path $PolicyBinary -Destination $DestinationBinary -force
  2. Restart the device.
  3. Confirm the policy is loaded in the Event Viewer by using the information in the Policy activation events section.
  4. Test by using applications and scripts while the policy is applied to identify compatibility issues.
To uninstall the SiPolicy.p7b audit policy, follow these steps:
  1. Run the following commands from an elevated Windows PowerShell prompt:

    Code:
    # Initialize policy location
    $PolicyBinary = $env:windir+"\System32\CodeIntegrity\SiPolicy.p7b"
    # Remove SiPolicy.p7b
    Remove-Item -Path $PolicyBinary -force
  2. Restart the device.
  3. Confirm the audit policy is not loaded in the Event Viewer by using the information in the Policy activation events section.


 Use an XML audit policy

If you use WDAC to manage applications and drivers allowed to run on your devices, you may already be using a policy named “SiPolicy.p7b”. For all supported Windows operating systems of Windows 10, version 1903 and later Windows versions, and Windows Server 2022 and later Windows Server versions, you can use the provided XML file to build and deploy an audit policy by using WDAC multiple policy format. For instructions to build and deploy the audit policy binary, see Deploying Windows Defender Application Control (WDAC) policies.

An XML file with the audit policy rules is available on devices that have the Windows update dated on or after August 13, 2024 installed. The XML file is located under “%systemroot%\schemas\CodeIntegrity\ExamplePolicies\VbsSI_Audit.xml”.

If you use the WDAC policy on Windows 10, version 1809 and earlier Windows versions, or on Windows Server 2016 and earlier Windows Server versions, then you will need to replace the existing WDAC policy with the audit policy to test for compatibility issues with the mitigation.

Deploying a Microsoft-signed revocation policy (SkuSiPolicy.p7b)

The Microsoft-signed revocation policy is included as part of the Windows update dated on or after August 13, 2024. This policy should only be applied to devices that have the August 13, 2024 or later update installed. If updates are missing, the device may not start with the mitigation applied or the mitigation may not work as expected.

To deploy the Microsoft-signed revocation policy (SkuSiPolicy.p7b), follow these steps:

  1. Run the following commands in an elevated Windows PowerShell prompt:

    Code:
    $PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b"
    $MountPoint = 'C:\EFIMount'
    $EFIDestinationFolder = "$MountPoint\EFI\Microsoft\Boot"
    $EFIPartition = (Get-Partition | Where-Object IsSystem).AccessPaths[0]
    if (-Not (Test-Path $MountPoint)) { New-Item -Path $MountPoint -Type Directory -Force }
    mountvol $MountPoint $EFIPartition
    if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force }
    Copy-Item -Path $PolicyBinary -Destination $EFIDestinationFolder -Force
    mountvol $MountPoint /D
  2. Restart your device.
  3. Confirm the policy is loaded in the Event Viewer by using the information in the Windows Event logs section.
Notes
  • You should not remove the SkuSiPolicy.p7b revocation (policy) file after it is deployed. Your device might no longer be able to start if the file is removed.
  • If your device does not start, see the  Recovery procedure section.

Updating external boot media

To use external boot media with a device that has a Microsoft-signed revocation policy applied, the external boot media must be updated with the applied policy file. Additionally, it must include the Windows updates dated on or after August 13, 2024. If the media does not include the updates, the media will not start.

Boot media which is updated with the Microsoft-signed revocation policy, must only be used to boot devices that have the mitigation already applied.  If it is used with devices without the mitigation, the UEFI lock will be applied during startup from the boot media. Subsequent starts from disk will fail, unless the device is updated with the mitigation or the UEFI lock is removed.

Important We recommend that you Create a recovery drive before proceeding. This media can be used to reinstall a device in case there is a major issue.

Use the following steps to update the external boot media:
  1. Go to a device where the Windows updates released on or after August 13, 2024 have been installed.
  2. Mount the external boot media as a drive letter. For example, mount a thumb drive as D:.
  3. Click Start, type Create a Recovery Drive in the Search box, and then click Create a recovery drive control panel. Follow the instructions to create a recovery drive by using the mounted thumb drive.
  4. With the newly created media mounted, copy the SkuSiPolicy.p7b file to <MediaRoot>\EFI\Microsoft\Boot (for example, D:\EFI\Microsoft\Boot).
  5. Safely remove the mounted thumb drive.
If you manage installable media in your environment by using the Update Windows installation media with Dynamic Update guidance, follow these steps:
  1. Go to a device where the Windows updates released on or after August 13, 2024 have been installed.
  2. Follow the steps in Update Windows installation media with Dynamic Update to create media that has the Windows updates released on or after August 13, 2024 installed.
  3. Place the contents of the media on a USB thumb drive and mount the thumb drive as a drive letter. For example, mount the thumb drive as D:.
  4. Copy SkuSiPolicy.p7b to <MediaRoot>\EFI\Microsoft\Boot (for example, D:\EFI\Microsoft\Boot).
  5. Safely remove the mounted thumb drive.

Windows Event logs

Windows logs events when code integrity policies, including SkuSiPolicy.p7b, are loaded and when a file is blocked from loading because of policy enforcement. You can use these events to verify that the mitigation has been applied.

Code integrity logs are available in the Windows Event Viewer under Application and Services logs > Microsoft > Windows > CodeIntegrity > Operational > Application and Services logs > Services logs > Microsoft > Windows > AppLocker > MSI and Script.

For more information on code integrity events, see the Windows Defender Application Control operational guide.

Policy activation events

Policy activation events are available in the Windows Event Viewer under Application and Services logs > Microsoft > Windows > CodeIntegrity > Operational.

CodeIntegrity Event 3099 indicates that a policy has been loaded and includes details about the loaded policy. Information in the event includes the friendly name of the policy, a globally unique identifier (GUID), and a hash of the policy. Multiple CodeIntegrity Event 3099 events will be present if there are multiple code integrity policies applied to the device.

When the provided audit policy is applied, there will be an event with the following information:
  • PolicyNameBuffer – Microsoft Windows Virtualization Based Security Audit Policy
  • PolicyGUID – {a244370e-44c9-4c06-b551-f6016e563076}
  • PolicyHash – 98FC5872FD022C7DB400953053756A6E62A8F24E7BD8FE080C6525DFBCA38387
da9f8388-5762-41e9-8aa2-51ef85720f75.png


When the Microsoft-signed revocation policy (SkuSiPolicy.p7b) is applied, there will be an event with the following information (See screenshot of CodeIntegrity event 3099 below):
  • PolicyNameBuffer – Microsoft Windows SKU SI Policy
  • PolicyGUID – {976d12c8-cb9f-4730-be52-54600843238e}
  • PolicyHash – 107E8FDD187C34CF8B8EA46A4EE99F0DB60F491650DC989DB71B4825DC73169D
a5c76a17-463e-4c6f-8874-43a83a372671.png


If you have applied the audit policy or the mitigation to your device and CodeIntegrity Event 3099 for the applied policy is not present, the policy is not being enforced. Please consult the deployment instructions to verify the policy was installed correctly.

Audit and block events

Code integrity audit and block events are available in the Windows Event Viewer under Application and Services logs > Microsoft > Windows > CodeIntegrity > Operational > Application and Services logs > Microsoft > Windows > AppLocker > MSI and Script.

The former logging location includes events about the control of executables, dlls, and drivers. The latter logging location includes events about the control of MSI installers, scripts, and COM objects.

CodeIntegrity Event 3076 in the "CodeIntegrity – Operational" log is the main block event for audit mode policies and indicates that a file would have been blocked if a policy was enforced. This event includes information about the blocked file and about the enforced policy. For files that would be blocked by the mitigation, the policy information in Event 3077 will match the policy information of audit policy from Event 3099.

CodeIntegrity Event 3077 in the "CodeIntegrity – Operational" log indicates that an executable, .dll, or driver has been blocked from loading. This event includes information about the blocked file and about the enforced policy. For files blocked by the mitigation, the policy information in CodeIntegrity Event 3077 will match the policy information of SkuSiPolicy.p7b from CodeIntegrity Event 3099. CodeIntegrity Event 3077 will not be present if there are not any executable, .dll, or drivers in violation of code integrity policy on your device.

For other code integrity audit and block events, see Understanding Application Control events.

Policy Removal and Recovery Procedure

If something goes wrong after applying the mitigation, you can use the following steps to remove the mitigation:
  1. Suspend BitLocker if it is enabled. Run the following command from an elevated Command Prompt window:

    Manager-bde -protectors -disable c: -rebootcount 3
  2. Turn off Secure Boot from the UEFI BIOS menu.

    The procedure for turning off Secure Boot differs between device manufacturers and models. For help locating where to turn off Secure Boot, consult with documentation from your device manufacturer. More details can be found in Disabling Secure Boot.
  3. Remove the SkuSiPolicy.p7bpolicy.
    1. Start Windows normally and then sign in.

      The SkuSiPolicy.p7b policy must be removed from the following location:
      • <EFI System Partition>\Microsoft\Boot\SKUSiPolicy.p7b
    2. Run the following script from an elevated Windows PowerShell session to clean up policy from those locations:

      Code:
      $PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b"
      $MountPoint = 'C:\EFIMount'
      $EFIPolicyPath = "$MountPoint\EFI\Microsoft\Boot\SkuSiPolicy.p7b"
      $EFIDestinationFolder="$MountPoint\EFI\Microsoft\Boot"
      $EFIPartition = (Get-Partition | Where-Object IsSystem).AccessPaths[0]
      if (-Not (Test-Path $MountPoint)) { New-Item -Path $MountPoint -Type Directory -Force }
      mountvol $MountPoint $EFIPartition
      if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force }
      if (Test-Path   $EFIPolicyPath ) {Remove-Item -Path $EFIPolicyPath -Force }
      mountvol $MountPoint /D
  4. Turn on Secure Boot from BIOS.

    Consult with the documentation from your device manufacturer for locating where to turn on Secure Boot.

    If you turned off Secure Boot in Step 1 and your drive is protected by BitLocker, suspend BitLocker protection and then turn on Secure Boot from your UEFI BIOS menu.
  5. Turn on BitLocker. Run the following command from an elevated Command Prompt window:

    Manager-bde -protectors -enable c:
  6. Restart your device.


 Source:

 
I installed the mitigation and got a different PolicyHash:
36E1176CA0F8B1473684C4B20A112E5027719CCE2D97103FDC97BF5B554A3BD4

However, the PolicyIdBuffer and the PolicyGUID match those of the document.

I don't know what to make of this. Any ideas?
 

My Computer

System One

  • OS
    Windows 11 Pro
    Computer type
    PC/Desktop
    Manufacturer/Model
    iBUYPOWER
    CPU
    Intel i9-13900KF
    Motherboard
    ASUS ROG Maximus Z790 Hero
    Memory
    32 GB Corsair Vengeance DDR5-6000 MHz
    Graphics Card(s)
    ASUS Dual GeForce RTX 4070
    Sound Card
    none
    Monitor(s) Displays
    Dell U2412M
    Screen Resolution
    1920 x 1200
    Hard Drives
    WD Black SN850X NVMe SSD - 1 TB
    PSU
    Thermaltake Toughpower GF3 1000W
    Case
    Fractal Design Meshify 2 RGB
    Cooling
    Corsair H150i RGB Elite
    Keyboard
    Deck Hassium Pro
    Mouse
    Logitech Marathon M705
    Internet Speed
    800 Mbps download, 20 Mbps upload
    Browser
    Firefox
    Antivirus
    Bitdefender Internet Security
Does that mean Beta Insiders even with the updates does not support the new policy yet?
 

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
I installed it on 2 PCs and it worked.
At first I didn't understand, but it is necessary to run the 2 scripts.
Does that mean Beta Insiders even with the updates does not support the new policy yet?
There are no signs in the KB that Microsoft will incorporate this into windows, but I hope they do until the release of Windows 11 24H2
 

My Computer

System One

  • OS
    Windows 11 Pro
    Computer type
    PC/Desktop
    Manufacturer/Model
    ASUS
    CPU
    Intel Core i7-13700KF
    Motherboard
    ASUS TUF GAMING B660M-PLUS D4
    Memory
    16GB DDR4-3731 / PC4-29800 DDR4 SDRAM UDIMM
    Graphics Card(s)
    NVIDIA GeForce RTX 4060 TI
    Sound Card
    RealTek ALC897
    Monitor(s) Displays
    ASUS TUF Gaming VG32V
    Screen Resolution
    2560 x 1440
    Hard Drives
    Corsair MP600 CORE XT 4TB
    PSU
    650 W
    Case
    Cooler Master Elite 300
    Cooling
    Thermalright Phantom Spirit 120 Evo
    Keyboard
    Dell Keyboard
    Mouse
    Alienware Mouse
    Internet Speed
    500 mb/s
    Browser
    Edge
    Antivirus
    Kaspersky Plus
    Other Info
    CineBench R23
    28851
I tried this and added both SiPolicy.p7b and SkuSiPolicy.p7b and get the following GSOD, how do I fix this as I couldn’t boot snd using mobile phone to post this. Is there a way to create a USB flash drive to boot to delete the two files from the EFI?

78CD9F34-8E80-46CA-86B8-72BB8EDBE42A.jpeg
which I started another thread on here:
 
Last edited:

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows

Policy Removal and Recovery Procedure

If something goes wrong after applying the mitigation, you can use the following steps to remove the mitigation:

  1. Suspend BitLocker if it is enabled. Run the following command from an elevated Command Prompt window:
    Manager-bde -protectors -disable c: -rebootcount 3
  2. Turn off Secure Boot from the UEFI BIOS menu.

    The procedure for turning off Secure Boot differs between device manufacturers and models. For help locating where to turn off Secure Boot, consult with documentation from your device manufacturer. More details can be found in Disabling Secure Boot.
  3. Remove the SkuSiPolicy.p7b policy.
    1. Start Windows normally and then sign in.

      The SkuSiPolicy.p7b policy must be removed from the following location:
      • <EFI System Partition>\Microsoft\Boot\SKUSiPolicy.p7b
    2. Run the following script from an elevated Windows PowerShell session to clean up policy from those locations:
      $PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b"
      $MountPoint = 'C:\EFIMount'
      $EFIPolicyPath = "$MountPoint\EFI\Microsoft\Boot\SkuSiPolicy.p7b"
      $EFIDestinationFolder="$MountPoint\EFI\Microsoft\Boot"
      $EFIPartition = (Get-Partition | Where-Object IsSystem).AccessPaths[0]
      if (-Not (Test-Path $MountPoint)) { New-Item -Path $MountPoint -Type Directory -Force }
      mountvol $MountPoint $EFIPartition
      if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force }
      if (Test-Path $EFIPolicyPath ) {Remove-Item -Path $EFIPolicyPath -Force }
      mountvol $MountPoint /D
  4. Turn on Secure Boot from BIOS.

    Consult with the documentation from your device manufacturer for locating where to turn on Secure Boot.

    If you turned off Secure Boot in Step 1 and your drive is protected by BitLocker, suspend BitLocker protection and then turn on Secure Boot from your UEFI BIOS menu.
  5. Turn on BitLocker. Run the following command from an elevated Command Prompt window:
    Manager-bde -protectors -enable c:
  6. Restart your device.
 

My Computer

System One

  • OS
    Windows 11 Pro
    Computer type
    PC/Desktop
    Manufacturer/Model
    ASUS
    CPU
    Intel Core i7-13700KF
    Motherboard
    ASUS TUF GAMING B660M-PLUS D4
    Memory
    16GB DDR4-3731 / PC4-29800 DDR4 SDRAM UDIMM
    Graphics Card(s)
    NVIDIA GeForce RTX 4060 TI
    Sound Card
    RealTek ALC897
    Monitor(s) Displays
    ASUS TUF Gaming VG32V
    Screen Resolution
    2560 x 1440
    Hard Drives
    Corsair MP600 CORE XT 4TB
    PSU
    650 W
    Case
    Cooler Master Elite 300
    Cooling
    Thermalright Phantom Spirit 120 Evo
    Keyboard
    Dell Keyboard
    Mouse
    Alienware Mouse
    Internet Speed
    500 mb/s
    Browser
    Edge
    Antivirus
    Kaspersky Plus
    Other Info
    CineBench R23
    28851
You will need another PC with the update

Bootable media
It will be important to update bootable media once the Deployment Phase begins in your environment.

Guidance for updating bootable media is coming with future updates to this article. See the next section to create a USB thumb drive for recovering a device.

Updating Windows install media
NOTE
When creating a bootable USB thumb drive, be sure to format the drive by using the FAT32 filesystem.
You can use the Create Recovery Drive application by following these steps. This media can be used to reinstall a device in case there is a major issue such as a hardware failure, you will be able to use the recovery drive to reinstall Windows.

  1. Go to a device where the July 9, 2024 updates and the first mitigation step (updating the Secure Boot DB) have been applied.
  2. From the Start menu, search for “Create a Recovery Drive” control panel applet and follow the instructions to create a recovery drive.
  3. With the newly created flash drive mounted (for example, as drive “D:”), run the following commands as an administrator. Type each of the following commands, and then press Enter:
COPY D:\EFI\MICROSOFT\BOOT\BCD D:\EFI\MICROSOFT\BOOT\BCD.BAK
bcdboot c:\windows /f UEFI /s D: /bootex
COPY D:\EFI\MICROSOFT\BOOT\BCD.BAK D:\EFI\MICROSOFT\BOOT\BCD
If you manage installable media in your environment by using the Update Windows installation media with Dynamic Update guidance, follow these steps. These additional steps will create a bootable flash drive that uses boot files signed by the “Windows UEFI CA 2023” signing certificate.

  1. Go to a device where the July 9, 2024, updates and the first mitigation step (updating the Secure Boot DB) has been applied.
  2. Follow the steps in the link below to create media with the July 9, 2024, updates. Update Windows installation media with Dynamic Update
  3. Place the contents of the media on a USB thumb drive and mount the thumb drive as a drive letter. For example, mount the thumb drive as “D:”.
  4. Run the following commands from a command window as an administrator. Type each of the following commands, and then press Enter.
COPY D:\EFI\MICROSOFT\BOOT\BCD D:\EFI\MICROSOFT\BOOT\BCD.BAK
bcdboot c:\windows /f UEFI /s D: /bootex
COPY D:\EFI\MICROSOFT\BOOT\BCD.BAK D:\EFI\MICROSOFT\BOOT\BCD
If a device has the Secure Boot settings reset to the defaults after applying the mitigations, the device will not boot. To resolve this issue, a repair application is included with the July 9, 2024 updates that can be used to reapply the “Windows UEFI CA 2023” certificate to the DB (mitigation #1).

NOTE Do not use this repair application on a device or system that is described in the Known Issues section.
  1. Go to a device where the July 9, 2024 updates have been applied.
  2. In a command window, copy the recovery app to the flash drive using the following commands (assuming the flash drive is the “D:” drive). Type each command separately and then press Enter:
md D:\EFI\BOOT
copy C:\windows\boot\efi\securebootrecovery.efi
D:\EFI\BOOT\bootx64.efi
  1. On the device that has the Secure Boot settings reset to the defaults, insert the flash drive, restart the device and boot from the flash drive.

 

My Computer

System One

  • OS
    Windows 11 Pro
    Computer type
    PC/Desktop
    Manufacturer/Model
    ASUS
    CPU
    Intel Core i7-13700KF
    Motherboard
    ASUS TUF GAMING B660M-PLUS D4
    Memory
    16GB DDR4-3731 / PC4-29800 DDR4 SDRAM UDIMM
    Graphics Card(s)
    NVIDIA GeForce RTX 4060 TI
    Sound Card
    RealTek ALC897
    Monitor(s) Displays
    ASUS TUF Gaming VG32V
    Screen Resolution
    2560 x 1440
    Hard Drives
    Corsair MP600 CORE XT 4TB
    PSU
    650 W
    Case
    Cooler Master Elite 300
    Cooling
    Thermalright Phantom Spirit 120 Evo
    Keyboard
    Dell Keyboard
    Mouse
    Alienware Mouse
    Internet Speed
    500 mb/s
    Browser
    Edge
    Antivirus
    Kaspersky Plus
    Other Info
    CineBench R23
    28851
@EduCustod - What you mentioned will only work if Windows will boot. And the other thing is WinRE needs to be updated in order to even use Windows Recovery Environment as it will also fail, there is a section everyone missed in the article:

Windows Recovery Environment. The Windows Recovery Environment (WinRE) on the device must be updated with the Windows updates dated on or after August 13, 2024 before the SkuSipolicy.p7b is applied to the device. Omitting this step might prevent WinRE from running the Reset PC feature. For more information, see Add an update package to Windows RE.
 

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
The correct way supposedly to do it is this:

as it needs the August 13, 2024 or later WinRE. The instructions you provided will only get one to July 9, 2024 updates. I bought a temporary machine to use and then return within 30 days.
There is really no need to do all that copying as the objective is to mount the UEFI first and then delete one single file which is what the Powerscript does:
  • <EFI System Partition>\Microsoft\Boot\SKUSiPolicy.p7b
That was the reason I created the other thread so if I manage to fix it, others can use it for reference in the future. Even with another PC, I couldn't fix something on a M2 based SSD, if it was the traditional Serial ATA connectors, then one can just physically mount the drive to another machine. So the thing is hopefully one of the following works:
TuxPE,
Macrium Reflect Rescue USB,
Medicat USB,
Hiren's BootCD PE x64,
Windows 11 ISO from something August 14, 2024 or later
Probably will have all of them on Ventoy

I'll give what you wrote a try first and report back before trying the above.
 
Last edited:

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
@EduCustod - I did everything in KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support starting from:
"Mitigation deployment guidelines" after updating to Windows 11 Release Preview build 26100.1591 (24H2) Home Edition which came out on August 27, 2024.

Under "Updating Windows install media", the two sets of instructions are identical as the first one shows:
Code:
COPY D:\EFI\MICROSOFT\BOOT\BCD D:\EFI\MICROSOFT\BOOT\BCD.BAK

bcdboot c:\windows /f UEFI /s D: /bootex

COPY D:\EFI\MICROSOFT\BOOT\BCD.BAK D:\EFI\MICROSOFT\BOOT\BCD

the second one which claims "These additional steps will create a bootable flash drive that uses boot files signed by the “Windows UEFI CA 2023” signing certificate." shows:
Code:
COPY D:\EFI\MICROSOFT\BOOT\BCD D:\EFI\MICROSOFT\BOOT\BCD.BAK

bcdboot c:\windows /f UEFI /s D: /bootex

COPY D:\EFI\MICROSOFT\BOOT\BCD.BAK D:\EFI\MICROSOFT\BOOT\BCD

Not sure what the purpose of the last line in each of them are for as the BCD.BAK was a copy created from BCD and then it's just making a new BCD from the BCD.BAK.

the last two lines in the instructions are wrong
Code:
copy C:\windows\boot\efi\securebootrecovery.efi
D:\EFI\BOOT\bootx64.efi

as it should be one line:
Code:
 copy C:\windows\boot\efi\securebootrecovery.efi D:\EFI\BOOT\bootx64.efi

This the the before using that command:
Code:
dir D:\efi\boot
 Volume in drive D is RECOVERY
 Volume Serial Number is 4C46-466C

 Directory of D:\efi\boot

08/28/2024  03:30 AM    <DIR>          .
08/28/2024  03:30 AM    <DIR>          ..
08/27/2024  09:44 PM         2,759,448 bootx64.efi
               1 File(s)      2,759,448 bytes
               2 Dir(s)  19,362,873,344 bytes free

and this is the after using that command:
Code:
dir D:\efi\boot
 Volume in drive D is RECOVERY
 Volume Serial Number is 4C46-466C

 Directory of D:\efi\boot

08/28/2024  03:30 AM    <DIR>          .
08/28/2024  03:30 AM    <DIR>          ..
08/27/2024  09:44 PM           160,576 bootx64.efi
               1 File(s)        160,576 bytes

Booting by hitting F12 and then selecting the USB Flash Drive which showed some lines about it rebooting and then it ended up with the exact same GSOD as I posted with the same exact error code so this method doesn't work. This s on a 32GB FAT32 partition on a 128GB USB Flash Drive.

Also, it appears that WinRE according to this KB5028997: Instructions to manually resize your partition to install the WinRE update - Microsoft Support says that WinRE is automatically updated:
"Microsoft has changed how it updates PCs that run the Windows Recovery Environment (WinRE). WinRE will be updated using the monthly cumulative update. This change only applies to PCs that get updates from Windows Update (WU) and Windows Server Update Services (WSUS). This change starts on June 27, 2023, for the Windows 11, version 22H2 cumulative update."

The fix was simple:

1) Turn off Secure Boot
2) Boot with a USB Flash Drive and use one of the WinPE type things, I chose Hiren's BootCD PE
3) Opened Administrator Command Prompt and then ran Powershell from there.
This script was useless as the commands were complaining one way or another...
Code:
$PolicyBinary = $env:windir+"\System32\SecureBootUpdates\SkuSiPolicy.p7b"
$MountPoint = 'C:\EFIMount'
$EFIPolicyPath = "$MountPoint\EFI\Microsoft\Boot\SkuSiPolicy.p7b"
$EFIDestinationFolder="$MountPoint\EFI\Microsoft\Boot"
$EFIPartition = (Get-Partition | Where-Object IsSystem).AccessPaths[0]
if (-Not (Test-Path $MountPoint)) { New-Item -Path $MountPoint -Type Directory -Force }
mountvol $MountPoint $EFIPartition
if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force }
if (Test-Path $EFIPolicyPath ) {Remove-Item -Path $EFIPolicyPath -Force }
mountvol $MountPoint /D

It was easier to just:
Code:
mountvol s: /s
del s:\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Reboot
2) Turn on Secure Boot

Everything works again and I am back in business.... so SkuSiPolicy.p7b is the problem or it could be WinRE not updated unless there was a way to verify when it was last updated.
 
Last edited:

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
The correct way to verify the version of WinRE, when it was updated and also update it is in this thread:
 

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
The correct way to verify the version of WinRE, when it was updated and also update it is in this thread:
Simplifying External Boot Media Mitigation Updates

WinRE on the local system partition is always updated by windows updates. External media not.

I was able to successfully boot Windows 11 24H2 ISO, & Macrium Reflect 10 rescue medium with Ventoy by using macriums built in rescue media builder. Currently, the ISO's base WIM NEEDS to be WinRE, and must be created in a windows 24h2 (26100) environment. WinPE base wim files are currently outdated (may 2024) and fail with SKUSiPolicy.P7b added.

Building it in a 23H2 (22631) environment with SKUSiPolicy.P7b results in boot failure on external media, even with an up-to-date windows machine that works with the security update locally on the system partition.

There may be other methods to update the environment of external media but I found this exhaustive.

I used a 24H2 virtual machine to install Macrium and make the ISO.

I used PowerISO to edit and save C:\Windows\System32\SecureBootUpdates\SKUSiPolicy.P7b to the iso \EFI\Microsoft\Boot folder. It works; and that is all that is needed.

This method also works for Windows 11 24H2 ISO. SKUSiPolicy.P7b must be added to work with secure boot enabled.
 
Last edited:

My Computer

System One

  • OS
    Windows 11
I had 0xc000000f errors booting into the local system Windows Recovery environment and Safemode after applying these mitigations.

Turns out my BCD was corrupted, and needed to be rebuilt. Here is how I did it: Redirecting
 

My Computer

System One

  • OS
    Windows 11
@Squack202 - Thanks for replying to the thread. The site didn't send me the notifications by e-mail for whatever reason and I was attempting this again today so I'll comment ask some questions since you know more about how to fix things than I do.

In my case, my WinRE never updated as Windows Updates only periodically updates the WinRE so in my case, mines was outdated as seen here
with a 22621.3518 from May 2024 despite me doing the regular Windows Updates of updating 23H2 Beta Insiders which is once every 1-2 weeks regularly. The only way my WinRE would update was when I did a UUP Dump ISO Repair install/upgrade as mentioned here when it did bring it to 22621.4225 to a current September 23, 2024 version that was released 3 days earlier and ofcourse Windows Updates to newer Beta Insider builds do not update the WinRE until I did a UUP Dump ISO install/upgrade of the same version that was Windows Updated. 22635.4305 by Windows Update did apparently update the WinRE to 22621.4305. Even with the current 22635.4440 Beta Build as seen here and from the answers, it appears that Windows Updated versions to 22635.4440 would still have 22635.4305 for WinRE while a UUP Dump ISO Repair install/upgrade does bring it to a matching 22635.4440 version. What is interesting is Microsoft here says under the "Check the WinRE image version", it does say the following:
"Make sure that the ServicePackBuild is greater than or equal to the UBR for the update that you added. For example, for Windows 11, version 22H2, the November security update would show 819 as the SerivcePack Build, since full version number for that update is 22621.819.

If the version reported is an earlier version, this indicates the Windows RE image is not up to date.
If the reported version is the same or a later version, no action is needed."

UBR if I understand it correctly is basically the installed build of Windows.

I will probably re-attempt everything again after doing a UUP Dump ISO Upgrade/repair install in the next few days to 22635.4440 so the two files are the latest versions as well as get my WinRE to 22621.4440.
There is probably something wrong with my BCD as well as a few weeks ago which was after I got the system booting again, I can only boot up in non-secure boot mode or secure boot in audit mode but secure boot in deployed mode no longer works.

Are you the author of Redirecting as after reading, I would like to thank the author and you for providing the link because it does provide answers to many things which is probably why it didn't work for me.

So I will comment here on a few sections:
1) "This mitigation is still somewhat cutting edge. It will probably work with 24H2 out of the box, but as of the time of this post 23H2's recovery environment did not work with it. It was updated with the October Rollout. This might change in the Nov Rollup. The file dates of wimre.wim was October 8'th, after windows update installed kb5044285 (October rollup). The failing Winre was ServicePack build 4305; the one that worked was 4317.

Microsoft claims winre on machines with updates after August 2024 should not have problems with VBS mitigation enforcement.

For whatever reason it was broken with post august updates, and even the October update. But manually servicing winre.wim with the October rollup update fixed the problem. Here is what I did to accomplish that."

This is interesting and very useful information as I didn't realize even post August 13, 2024 WinRE would have the problem and thankfully for you mentioning the post, my thought of not attempting this with the WinRE 22621.4305 on a 22635.4440 Beta OS is correct as it would fail and 22621.4440 would work as it's atleast 4317. So while I do not have to manually service winre.wim, I'll just let the UUP Dump ISO upgrade/repair install of 22635.4440 Beta do it instead as it seems faster and easier, atleast to me anyways.

2) "Microsoft's tutorial leaves out the compression step I include below; Microsofts tutorial results in a file that is 1.2 gb, too large to fit in the recovery partition."
This was probably the same reason my WinRE did not update from the May 2024 version as my recovery partition was I think 1.06GB and the 22635.4225 UUP Dump Upgrade/Repair Install did put a new 1.2GB Recovery Partition which matches what is said.

3) "3. Clean up image
dism /image:C:\mount /cleanup-image /StartComponentCleanup /ResetBase"
/ResetBase is ignored and turned off by default from what I read in Windows 11 as mentioned in a thread here.

4) "The solution was to

1. Disable secure boot in the BIOS
2. Boot into windows, temporarily disable the applied VBS mitigations with the powershell command here (link),
3. Reboot into windows to ensure policy is applied
4. Enter into the windows recovery environment. and rebuild BCD (link)
5. Re-enable SecureBoot, Re-apply VBS rollback mitigations"

For step 3., I thought the policy would have been removed from 2.
For 4. , the rebuild BCD (link) is correct but the contents of the page is for "how to add KB5042562 vbs rollback mitigations to windows 11 iso" instead of "how torebuild bcd windows 11" so the instructions to rebuild BCD are actually missing.
 

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
@Squack202 - Thanks for replying to the thread. The site didn't send me the notifications by e-mail for whatever reason and I was attempting this again today so I'll comment ask some questions since you know more about how to fix things than I do.

In my case, my WinRE never updated as Windows Updates only periodically updates the WinRE so in my case, mines was outdated as seen here
with a 22621.3518 from May 2024 despite me doing the regular Windows Updates of updating 23H2 Beta Insiders which is once every 1-2 weeks regularly. The only way my WinRE would update was when I did a UUP Dump ISO Repair install/upgrade as mentioned here when it did bring it to 22621.4225 to a current September 23, 2024 version that was released 3 days earlier and ofcourse Windows Updates to newer Beta Insider builds do not update the WinRE until I did a UUP Dump ISO install/upgrade of the same version that was Windows Updated. 22635.4305 by Windows Update did apparently update the WinRE to 22621.4305. Even with the current 22635.4440 Beta Build as seen here and from the answers, it appears that Windows Updated versions to 22635.4440 would still have 22635.4305 for WinRE while a UUP Dump ISO Repair install/upgrade does bring it to a matching 22635.4440 version. What is interesting is Microsoft here says under the "Check the WinRE image version", it does say the following:
"Make sure that the ServicePackBuild is greater than or equal to the UBR for the update that you added. For example, for Windows 11, version 22H2, the November security update would show 819 as the SerivcePack Build, since full version number for that update is 22621.819.

If the version reported is an earlier version, this indicates the Windows RE image is not up to date.
If the reported version is the same or a later version, no action is needed."

UBR if I understand it correctly is basically the installed build of Windows.

I will probably re-attempt everything again after doing a UUP Dump ISO Upgrade/repair install in the next few days to 22635.4440 so the two files are the latest versions as well as get my WinRE to 22621.4440.
There is probably something wrong with my BCD as well as a few weeks ago which was after I got the system booting again, I can only boot up in non-secure boot mode or secure boot in audit mode but secure boot in deployed mode no longer works.

Are you the author of Redirecting as after reading, I would like to thank the author and you for providing the link because it does provide answers to many things which is probably why it didn't work for me.

So I will comment here on a few sections:
1) "This mitigation is still somewhat cutting edge. It will probably work with 24H2 out of the box, but as of the time of this post 23H2's recovery environment did not work with it. It was updated with the October Rollout. This might change in the Nov Rollup. The file dates of wimre.wim was October 8'th, after windows update installed kb5044285 (October rollup). The failing Winre was ServicePack build 4305; the one that worked was 4317.

Microsoft claims winre on machines with updates after August 2024 should not have problems with VBS mitigation enforcement.

For whatever reason it was broken with post august updates, and even the October update. But manually servicing winre.wim with the October rollup update fixed the problem. Here is what I did to accomplish that."

This is interesting and very useful information as I didn't realize even post August 13, 2024 WinRE would have the problem and thankfully for you mentioning the post, my thought of not attempting this with the WinRE 22621.4305 on a 22635.4440 Beta OS is correct as it would fail and 22621.4440 would work as it's atleast 4317. So while I do not have to manually service winre.wim, I'll just let the UUP Dump ISO upgrade/repair install of 22635.4440 Beta do it instead as it seems faster and easier, atleast to me anyways.

2) "Microsoft's tutorial leaves out the compression step I include below; Microsofts tutorial results in a file that is 1.2 gb, too large to fit in the recovery partition."
This was probably the same reason my WinRE did not update from the May 2024 version as my recovery partition was I think 1.06GB and the 22635.4225 UUP Dump Upgrade/Repair Install did put a new 1.2GB Recovery Partition which matches what is said.

3) "3. Clean up image
dism /image:C:\mount /cleanup-image /StartComponentCleanup /ResetBase"
/ResetBase is ignored and turned off by default from what I read in Windows 11 as mentioned in a thread here.

4) "The solution was to

1. Disable secure boot in the BIOS
2. Boot into windows, temporarily disable the applied VBS mitigations with the powershell command here (link),
3. Reboot into windows to ensure policy is applied
4. Enter into the windows recovery environment. and rebuild BCD (link)
5. Re-enable SecureBoot, Re-apply VBS rollback mitigations"

For step 3., I thought the policy would have been removed from 2.
For 4. , the rebuild BCD (link) is correct but the contents of the page is for "how to add KB5042562 vbs rollback mitigations to windows 11 iso" instead of "how torebuild bcd windows 11" so the instructions to rebuild BCD are actually missing.
@Almighty1,
Hi,
I don't understand the above explanation about the problem with the Recovery environment.
The only problem I ever had updating the Recovery was caused by the small size created by windows when doing a clean install.
To avoid that I created much bigger recovery partition than the one windows clean install creates by default.
I never had any problem updating Recovery after that. 🤞
In this sample I have a recovery partition of 2.53 GB and plenty of free space.
In the last 2 years, this system was updated from Windows 10 and through all the Windows 11 UBR Builds and it is now 24H2 26100.2161, still working fine. 🤞
1730681112293.png
 

My Computer

System One

  • OS
    Windows 11 Pro
    Computer type
    Laptop
    Manufacturer/Model
    Lenovo Yoga 920
    CPU
    Intel I7-8550U
    Motherboard
    n/a
    Memory
    16GB
    Graphics Card(s)
    Intel Graphics UHD 620
    Sound Card
    Realtek High Definition Audio (SST)
    Monitor(s) Displays
    4k Touch screen
    Screen Resolution
    3480 x 2160
    Hard Drives
    512GB NVMe
@fg2001gf11F - The problem with the Recovery Environment for this thread depending which problem you are referring to can be space which you addressed, I'll probably merge the two recovery partitions by deleting the unused one so that it will be 2.26GB or even make it bigger than that when I have some time as I don't want to delete the wrong recovery partition. Do you actually check regularly if the Recovery is updated? The other problem is the WinRE even with Windows Updates like the current Beta for example as we both know only updates to 22621.4305 which even though it is newer than August 13, 2024 would not work with the original purpose of this thread as Microsoft apparently didn't update the WinRE to work until 22621.4317 as I had quoted so the only way to get to atleast 4317 is using the 22635.4440 UUP Dump ISO.
 
Last edited:

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
@fg2001gf11F - The problem with the Recovery Environment for this thread depending which problem you are referring to can be space which you addressed, I'll probably merge the two recovery partitions by deleting the unused one so that it will be 2.26GB or even make it bigger than that when I have some time as I don't want to delete the wrong recovery partition. Do you actually check regularly if the Recovery is updated? The other problem is the WinRE even with Windows Updates like the current Beta for example as we both know only updates to 22621.4305 which even though it is newer than August 13, 2024 would not work with the original purpose of this thread as Microsoft apparently didn't update the WinRE to work until 22621.4317 as I had quoted so the only way to get to atleast 4317 is using the 22635.4440 UUP Dump ISO.
In this case uupdump ISOets 22621.4440 WinRE.
I think that when MS will need the new version 22621.4317 or higher they will probably make it part of the update that requires it or at least they should. 😉
 

My Computer

System One

  • OS
    Windows 11 Pro
    Computer type
    Laptop
    Manufacturer/Model
    Lenovo Yoga 920
    CPU
    Intel I7-8550U
    Motherboard
    n/a
    Memory
    16GB
    Graphics Card(s)
    Intel Graphics UHD 620
    Sound Card
    Realtek High Definition Audio (SST)
    Monitor(s) Displays
    4k Touch screen
    Screen Resolution
    3480 x 2160
    Hard Drives
    512GB NVMe
Well, the 4317 or higher was discovered by the person who wrote the referenced post as Microsoft tells you that you need a WinRE dated August 13, 2024 or later but all WinRE's from August 13, 2024 or later fails until atleast 4317 as tested in the referenced post. See Comment #14 under 1) where I quoted the section which is needed to manually fix a security issue which is what the first post is for. Only 4317 will work otherwise one will end up with a unbootable system.
 

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
Well, the 4317 or higher was discovered by the person who wrote the referenced post as Microsoft tells you that you need a WinRE dated August 13, 2024 or later but all WinRE's from August 13, 2024 or later fails until atleast 4317 as tested in the referenced post. See Comment #14 under 1) where I quoted the section which is needed to manually fix a security issue which is what the first post is for. Only 4317 will work otherwise one will end up with a unbootable system.
I still have a 23H2 Build 22631.4391 on one machine that has the old WinRE .4305.
I'll leave it alone for now and wait to see what happens when they will try to update.
I will take action when I'll face the problem. 🤷‍♂️

1730689605630.png
 

My Computer

System One

  • OS
    Windows 11 Pro
    Computer type
    Laptop
    Manufacturer/Model
    Lenovo Yoga 920
    CPU
    Intel I7-8550U
    Motherboard
    n/a
    Memory
    16GB
    Graphics Card(s)
    Intel Graphics UHD 620
    Sound Card
    Realtek High Definition Audio (SST)
    Monitor(s) Displays
    4k Touch screen
    Screen Resolution
    3480 x 2160
    Hard Drives
    512GB NVMe
I still have a 23H2 Build 22631.4391 on one machine that has the old WinRE .4305.
I'll leave it alone for now and wait to see what happens when they will try to update.
I will take action when I'll face the problem. 🤷‍♂️

View attachment 115181
It will be hard for you to face the problem because apparently for Microsoft, they don't enable the security fixes by default. The user has to manually do it and even in-place upgrade repair installs and new installs don't enable the security fixes by default. 4305 was the last time Windows Update actually updated the WinRE as it seems every Windows Update probably includes a WinRE and it will only install 4305 unless 4305 is already on the system.
 

My Computer

System One

  • OS
    Windows XP/7/8/8.1/10/11, Linux, Android, FreeBSD Unix
    Computer type
    Laptop
    Manufacturer/Model
    Dell XPS 15 9570
    CPU
    Intel® Core™ i7-8750H 8th Gen Processor 2.2Ghz up to 4.1Ghz
    Motherboard
    Dell XPS 15 9570
    Memory
    32GB using 2x16GB modules
    Graphics Card(s)
    Intel UHD 630 & NVIDIA GeForce GTX 1050 Ti with 4GB DDR5
    Sound Card
    Realtek ALC3266-CG
    Monitor(s) Displays
    15.6" 4K Touch UltraHD 3840x2160 made by Sharp
    Screen Resolution
    3840x2160
    Hard Drives
    Toshiba KXG60ZNV1T02 NVMe 1024GB/1TB SSD
    PSU
    Dell XPS 15 9570
    Case
    Dell XPS 15 9570
    Cooling
    Stock
    Keyboard
    Stock
    Mouse
    SwitftPoint ProPoint
    Internet Speed
    Comcast/XFinity 1.44Gbps/42.5Mbps
    Browser
    Microsoft EDGE (Chromium based) & Google Chrome
    Antivirus
    Windows Defender that came with Windows
Back
Top Bottom