Recover a Secure Boot violation, invalid-signature failure, or Automatic Repair loop

Windows starts when Secure Boot is disabled but firmware rejects the boot path, Windows reports an invalid digital signature, or Windows enters Automatic Repair when Secure Boot is enabled. The visible symptom can come from several different mechanisms:

• the computer is still starting in legacy BIOS/CSM mode and is not prepared for UEFI Secure Boot;
• the firmware is in Secure Boot Setup Mode because no Platform Key is enrolled;
• the firmware's allowed-signature database does not trust the current boot manager;
• the forbidden-signature database or Secure Version Number rejects an older boot manager;
• bootmgfw.efi, winload.efi, or another Microsoft boot file is damaged or stale;
• a boot-start third-party driver is signed, but its signature, catalog, certificate, or policy status is not acceptable to Windows;
• a test-signing, flight-signing, integrity, or related boot-policy setting conflicts with the intended production boot path.

The disk and partition layout must be detected. Do not ask the reader to guess whether the installation is UEFI/GPT. Firmware architecture matters only because Secure Boot operates in UEFI mode; it is not a reason to change unrelated firmware settings.

Searchable Windows error codes and exact messages

Firmware rejection wording is manufacturer-specific. Useful exact search phrases include:

• Secure Boot Violation
• Invalid Signature Detected. Check Secure Boot Policy in Setup
• Selected boot image did not authenticate
• The image's hash and certificate are not allowed (DB)

These are firmware or virtual-firmware messages, not standardized Windows error codes.

Searchable Secure Boot servicing events

These events are in the System log with source TPM-WMI or Microsoft-Windows-TPM-WMI:

Searchable driver and Code Integrity events

In Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational, the most relevant IDs are:

• 3001 — an unsigned driver attempted to load;
• 3002 — Code Integrity could not verify the boot image because a page hash was unavailable;
• 3004 — a kernel driver or integrity-checked file has an invalid signature or page-hash problem;
• 3010 — the signature catalog is invalid;
• 3026 — the catalog-signing certificate was revoked;
• 3032 — the file or one of its signatures is revoked;
• 3033 — signature or policy requirements were not met, commonly because a signature is revoked or a Lifetime Signing certificate expired;
• 3036 — the certificate that signed the file was revoked;
• 3077 — an enforced App Control policy blocked the file;
• 3089 — correlated signature details for a blocked file;
• 3112 — Windows revoked the certificate that signed the file.

Use this procedure when Windows 10 or Windows 11 starts with Secure Boot disabled but fails, reports an invalid signature, or enters Automatic Repair when Secure Boot is enabled. It also applies when current Windows or recovery media is rejected after a documented Secure Boot certificate, DBX, Boot Manager, or SVN update.

The strongest initial evidence is an A/B result in which changing only Secure Boot reproduces or removes the failure. One controlled confirmation is sufficient; do not repeatedly cycle the setting.

Do not use this as a generic repair when Windows also fails with Secure Boot disabled, the system disk is missing or unstable, memory or storage diagnostics fail, or the failure began after a SATA/AHCI/RAID/VMD controller change. Do not use the default-key branch on an enterprise-managed, owner-keyed, custom-key, or intentionally multi-boot system.

If a firmware update, custom operating-system loader, antimalware recovery environment, Linux shim, PXE loader, backup product, or vendor preboot application owns part of the boot chain, its vendor may need to supply a newly trusted loader. Do not replace or delete that component as though it were a standard Windows file.

The exact Windows build may remain unknown during mode, layout, key-state, event-log, and BCD inspection. It becomes material before copying boot files from external media, matching a driver package, or performing version-dependent Secure Boot certificate servicing.

The manufacturer-specific firmware menu names and the original reason Secure Boot was disabled may remain unknown. The following may not remain unknown before a write operation:

• whether the running installation uses UEFI/GPT or legacy BIOS/MBR;
• whether a Platform Key is enrolled and whether the platform is in Setup Mode;
• whether the computer is expected to use OEM factory keys or custom keys;
• the exact boot file or driver named by Windows, when one is displayed;
• whether DBX or SVN revocations have already been applied;
• the exact system disk, EFI System Partition, Windows volume, and BCD store being changed.

• The ability to return Secure Boot to the last bootable setting
• Administrator access to Windows while Secure Boot is temporarily disabled, or current Windows 10/11 recovery media
• A verified backup of irreplaceable data before UEFI conversion, firmware updating, or boot-file replacement
• An exported BCD store and copied EFI boot directory before running BCDBoot
• Current OEM firmware when Secure Boot variable-update events implicate firmware
• A current, supported Windows or vendor driver package when a boot-start driver is rejected
• Manufacturer or organizational key-management guidance if OEM-default ownership cannot be proven
• For the SecureBootRecovery.efi branch only, a separate trusted, currently updated x64 Windows 10/11 computer and an empty FAT32 USB drive

Do not proceed on the assumption that Clear keys, Delete keys, Reset to Setup Mode, Restore factory defaults, and Install factory keys mean the same thing. They do not.

Record the current Secure Boot, boot-mode, CSM, and key-mode settings with photographs. If enabling Secure Boot causes the failure, return only Secure Boot to its last bootable state. Leave CSM, UEFI/legacy mode, storage-controller mode, TPM settings, boot order, and keys unchanged.

Start Windows with Secure Boot temporarily disabled. This is recovery access, not the completed solution. If disabling Secure Boot no longer restores the previously bootable state, stop this procedure and diagnose the new failure separately.

Step 1 — Capture where startup fails

1. Record the complete screen, including the firmware heading, Windows code, File: path, and exact wording.

2. Classify the stage:

   • A firmware violation before Windows Boot Manager appears points toward UEFI mode, key databases, a revoked UEFI application, or the selected boot application.
   • 0xc0000428 with bootmgfw.efi or winload.efi points toward a Microsoft boot component, its signing chain, or its file integrity.
   • 0xc0000428 with \Windows\System32\drivers\<vendor>.sys points toward a driver-signature or Code Integrity branch.
   • Automatic Repair after Windows begins loading means at least one boot application executed; inspect the loader, kernel, driver, BCD policy, and Code Integrity evidence rather than assuming the Platform Key is missing.

3. Before the single controlled Secure-Boot-on test, save its start time while Windows is accessible. From elevated PowerShell:

   $evidence = Join-Path $env:SystemDrive 'BootRepairBackup\SecureBoot'
   New-Item -ItemType Directory -Path $evidence -Force | Out-Null
   (Get-Date).ToString('o') |
       Set-Content (Join-Path $evidence 'SecureBoot-test-start.txt')
   

   Enable only Secure Boot, reproduce the failure once, then return only Secure Boot to the recorded bootable setting. Do not repeat the firmware toggle merely to create more events.

4. If Automatic Repair provides a log path, copy the actual offline log before further repair. In WinRE, detect the Windows volume and assign W: only after verifying it:

   diskpart
   list disk
   list volume
   select volume <Windows-volume-number>
   detail volume
   assign letter=W
   exit
   

5. Display and copy the log:

   type W:\Windows\System32\LogFiles\Srt\SrtTrail.txt
   md W:\BootRepairBackup\SecureBoot
   copy W:\Windows\System32\LogFiles\Srt\SrtTrail.txt W:\BootRepairBackup\SecureBoot\SrtTrail-before-repair.txt
   

Treat a filename in SrtTrail.txt as a diagnostic lead. Startup Repair's conclusion does not establish why a signature or hash failed.

Step 2 — Detect the firmware and partition layout

In the running Windows installation, open msinfo32 and record:

• BIOS Mode — UEFI or Legacy;
• Secure Boot State — On, Off, or Unsupported.

Then run elevated PowerShell:

Confirm-SecureBootUEFI

Get-Disk |
    Where-Object { $_.IsBoot -or $_.IsSystem } |
    Format-Table Number,FriendlyName,PartitionStyle,IsBoot,IsSystem

Interpret the result:

• True means Secure Boot is currently active.
• False means the UEFI platform supports Secure Boot but it is disabled.
• Cmdlet not supported on this platform. combined with BIOS Mode: Legacy supports a legacy/CSM boot, not missing Secure Boot keys.
• An MBR system disk and legacy boot must be converted and moved to UEFI before Secure Boot can operate.
• A GPT system disk with a FAT32 EFI System Partition and BIOS Mode: UEFI does not need MBR2GPT.

If WinPE itself must be checked, run:

wpeutil UpdateBootInfo
reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType

0x1 means WinPE was started in BIOS mode; 0x2 means WinPE was started in UEFI mode. This reports how the recovery environment was booted, not how the installed Windows previously booted.

Step 3 — Inspect current and default Secure Boot variables

From elevated Windows PowerShell:

foreach ($n in 'SetupMode','SecureBoot','PK','PKDefault',
                   'KEK','KEKDefault','db','dbDefault',
                   'dbx','dbxDefault') {
    try {
        $v = Get-SecureBootUEFI -Name $n -ErrorAction Stop
        "${n}: defined; $($v.Bytes.Count) bytes; first byte $($v.Bytes[0])"
    }
    catch {
        "${n}: $($_.Exception.Message)"
    }
}

Use these distinctions:

• SetupMode first byte 1 plus an undefined PK means the platform is in Setup Mode and no current Platform Key is enrolled.
• SetupMode first byte 0 plus defined PK, KEK, db, and dbx means keys exist. Do not reinstall them merely because Secure Boot is off.
• Defined PKDefault, KEKDefault, dbDefault, and dbxDefault show that firmware exposes a factory-default set. They do not prove that overwriting custom keys is safe.
• Event 1803 does not establish that the current KEK is missing; it means a suitable PK-signed KEK update was not found for that device.

Secure Boot is actually active only when the platform is out of Setup Mode and the Secure Boot variable is enabled.

Step 4 — Preserve and inspect BCD and EFI boot files

From an elevated Command Prompt in the running Windows installation:

md "%SystemDrive%\BootRepairBackup\SecureBoot"
bcdedit /export "%SystemDrive%\BootRepairBackup\SecureBoot\BCD-before-secureboot-repair"
bcdedit /enum all /v > "%SystemDrive%\BootRepairBackup\SecureBoot\BCD-enum-before.txt"
mountvol S: /s
dir S:\EFI\Microsoft\Boot\BCD
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum {bootmgr} /v > "%SystemDrive%\BootRepairBackup\SecureBoot\ESP-bootmgr-before.txt"
copy S:\EFI\Microsoft\Boot\BCD "%SystemDrive%\BootRepairBackup\SecureBoot\BCD-file-before"
robocopy S:\EFI\Microsoft\Boot "%SystemDrive%\BootRepairBackup\SecureBoot\Microsoft-Boot-before" /E /COPY:DAT

Use S: only if it was unused before mountvol. Confirm that the mounted volume contains the BCD and Microsoft boot files used by the current Windows Boot Manager. If more than one ESP exists or the intended ESP cannot be established, stop before BCDBoot.

Inspect the complete enumeration rather than reducing it to matching lines:

notepad "%SystemDrive%\BootRepairBackup\SecureBoot\BCD-enum-before.txt"

Search within that file for testsigning, flightsigning, nointegritychecks, debug, and bootdebug. For every match, preserve the preceding object-type header, identifier, and surrounding fields. A filtered findstr result by itself loses the object boundary and is not enough to choose a target. Do not remove a setting until its exact BCD object and purpose are known.

Check the primary Microsoft boot files from elevated PowerShell:

Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi |
    Format-List Status,StatusMessage,SignerCertificate

Get-AuthenticodeSignature "$env:SystemRoot\System32\winload.efi" |
    Format-List Status,StatusMessage,SignerCertificate

Get-FileHash S:\EFI\Microsoft\Boot\bootmgfw.efi -Algorithm SHA256
Get-FileHash "$env:SystemRoot\System32\winload.efi" -Algorithm SHA256

A PowerShell status of Valid is not conclusive proof of Secure Boot trust. It indicates a syntactically valid Authenticode signature; DBX, SVN, kernel policy, App Control, HVCI, or a catalog can still reject the component.

Step 5 — Collect Secure Boot and Code Integrity events

From elevated PowerShell:

$testStart = [DateTimeOffset](Get-Content (
    Join-Path $env:SystemDrive `
        'BootRepairBackup\SecureBoot\SecureBoot-test-start.txt'))
$startLocal = $testStart.LocalDateTime
$testEnd = Get-Date

$sbIds = 1033,1036,1037,1042,1043,1044,1045,
         1795,1796,1797,1798,1799,1800,1801,1802,1803,1808

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-TPM-WMI'
    Id           = $sbIds
    StartTime    = $startLocal
    EndTime      = $testEnd
} -MaxEvents 100 -ErrorAction SilentlyContinue |
    Select-Object TimeCreated,Id,LevelDisplayName,Message |
    Format-List

Then query Code Integrity:

$ciIds = 3001,3002,3004,3010,3026,3032,3033,3036,3077,3089,3112

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id      = $ciIds
    StartTime = $startLocal
    EndTime   = $testEnd
} -MaxEvents 200 -ErrorAction SilentlyContinue |
    Select-Object TimeCreated,Id,LevelDisplayName,Message |
    Format-List

Save both command outputs. Use events inside the controlled-test window as evidence for this failure; older events are historical context unless independently tied to the same occurrence. A driver name repeated in the recovery screen and Code Integrity log within that window is materially stronger evidence than the Secure Boot toggle alone. If the timestamp file is unavailable, use the recorded firmware-test time to set a narrow manual StartTime and EndTime rather than treating the newest 100 events as one incident.

Use only the branch supported by section 7. Do not apply every branch.

Branch A — The installation is still legacy BIOS/MBR

If msinfo32 reports BIOS Mode: Legacy, the system disk is MBR, and Windows boots only in the prior legacy/CSM configuration, Secure Boot cannot be enabled on that current boot path.

1. Return firmware to the recorded bootable Legacy/CSM setting and leave Secure Boot disabled.

2. Create a verified full disk image or equivalent recoverable backup. MBR-to-GPT conversion is not undone by simply switching firmware back to Legacy.

3. Record the exact Windows system-disk number from Get-Disk and Disk Management.

4. Check encryption and protection state even though the Windows volume is currently unlocked:

   manage-bde -status %SystemDrive%
   

5. If the OS volume is encrypted and Protection Status is Protection On, stop. An unlocked volume is not the same as suspended protection. Continue only after the authorized BitLocker procedure has suspended protection and manage-bde -status shows Protection Off for the OS volume. Do not disable, remove, or regenerate protectors in this writeup.

6. Validate without converting:

   mbr2gpt /validate /disk:<system-disk-number> /allowFullOS
   

7. If validation fails, stop. Do not force conversion or use a different disk number by trial.

8. If validation succeeds and conversion is authorized, run:

   mbr2gpt /convert /disk:<system-disk-number> /allowFullOS
   

9. Confirm that MBR2GPT reports successful conversion.

10. Restart into firmware and change only the boot architecture from Legacy/CSM to UEFI. Keep Secure Boot disabled.

11. Select Windows Boot Manager for the converted disk and start Windows twice.

12. Confirm BIOS Mode: UEFI and a GPT system disk. Only then proceed to the applicable key, file, or driver branch and enable Secure Boot. If BitLocker protection was deliberately suspended before conversion, resume it only after these UEFI boots succeed, then verify its state:

    manage-bde -protectors -enable %SystemDrive%
    manage-bde -status %SystemDrive%
    

If the disk is already GPT and Windows already reports UEFI mode, do not run MBR2GPT. If CSM is merely enabled as a fallback but Windows is currently starting through UEFI, record the setting and disable CSM only if the platform requires it for Secure Boot. Test Windows with Secure Boot still off before proceeding.

Branch B — The Platform Key is absent and OEM defaults are appropriate

Use this branch only when all of the following are true:

• SetupMode=1;
• PK is undefined;
• the device is expected to use the manufacturer's standard Windows keys;
• the OEM confirms that this model's factory-default key set trusts the boot chain currently installed, including Windows UEFI CA 2023 when the installed Boot Manager requires it;
• no enterprise, owner-managed, custom, or intentional multi-boot key set must be preserved.

1. Keep Secure Boot disabled.

2. Confirm both of the following before selecting any firmware key action:

   • the firmware exposes default variables such as PKDefault, KEKDefault, dbDefault, and dbxDefault;
   • the manufacturer documents that the defaults for this exact model and firmware revision trust the installed Windows boot chain.

   Defined default variables alone are insufficient. Older OEM defaults can omit Windows UEFI CA 2023 and can make a 2023-signed Boot Manager unbootable.

3. Enter firmware key management.

4. If offered Standard versus Custom, select Standard only when OEM-default ownership has been established.

5. Select the option explicitly described as Install factory default keys, Restore factory default keys, or the manufacturer's equivalent.

6. Do not select Clear keys, Delete all Secure Boot variables, or Reset to Setup Mode.

7. Save and restart. If firmware permits, boot Windows once while Secure Boot remains disabled.

8. Re-run the variable inventory. Confirm that SetupMode=0 and PK, KEK, db, and dbx are defined.

9. Restart to firmware and enable only Secure Boot.

10. Start Windows and verify with Confirm-SecureBootUEFI.

If the OEM cannot confirm the trust content, factory-key enrollment is unavailable, variables remain undefined, or firmware cannot write them, stop for an OEM firmware update or model-specific service. If the only demonstrated defect is that a firmware reset removed Windows UEFI CA 2023 from db, use the tightly scoped recovery path in Branch C instead of resetting all keys. Do not import key files downloaded from an unrelated computer or motherboard.

Branch C — Secure Boot certificate servicing is incomplete

Use this branch for event 1800 or 1801, or when Windows UEFI CA 2023 transition status is incomplete without 1795, 1802, or 1803.

Windows certificate servicing requires a currently serviced Windows installation and Secure Boot enabled. Work performed while Secure Boot is off can prepare the device, but it does not prove that firmware accepted or applied the authenticated variable updates.

Branch C1 — Windows starts with Secure Boot enabled

1. While Windows is accessible, install the latest supported OEM firmware using the manufacturer's documented process and install current Windows servicing updates. Restart normally.

2. Enable only Secure Boot. Start Windows and confirm from elevated PowerShell:

   Confirm-SecureBootUEFI
   

   Continue only if it returns True. If enabling Secure Boot blocks Windows before it can service the certificates, do not repeatedly run the task with Secure Boot off. Use Branch C2 only when its missing-Windows UEFI CA 2023 evidence gate is met; otherwise return Secure Boot to the recorded bootable setting and stop for the matching key, file, driver, or OEM branch.

3. If event 1800 requested a restart, restart once and recheck the controlled-test event window before doing anything else.

4. Check transition status:

   (Get-ItemProperty -Path `
       'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' `
       -ErrorAction SilentlyContinue).UEFICA2023Status
   

5. Check whether the allowed database contains the new Windows certificate:

   [System.Text.Encoding]::ASCII.GetString(
       (Get-SecureBootUEFI db).Bytes
   ) -match 'Windows UEFI CA 2023'
   

6. If the built-in servicing task exists and Windows has already staged a Secure Boot update, run that existing task from elevated PowerShell:

   $task = Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' `
       -TaskName 'Secure-Boot-Update' -ErrorAction Stop
   $task | Start-ScheduledTask
   

7. Restart, then recheck the status, database, and time-correlated events.

8. Treat UEFICA2023Status=Updated, a True certificate query, and event 1808 as completion evidence. A task that merely started is not completion evidence.

Do not set AvailableUpdates, force DB/DBX changes, or apply revocations as a generic boot repair. If event 1795, 1802, or 1803 appears, stop this branch; the remedy is firmware/OEM support, not repeated task execution.

Branch C2 — Reapply only Windows UEFI CA 2023 with SecureBootRecovery.efi

Use this recovery path only when all of the following are established:

• the affected computer is x64 UEFI, not legacy BIOS/CSM;
• PK and KEK remain enrolled and the platform is not in Setup Mode;
• current evidence shows that Windows UEFI CA 2023 is missing from db after a firmware reset or replacement of the database;
• the installed Windows Boot Manager is the current 2023-signed version, or the device had already recorded the 2023 transition before firmware removed that trust anchor;
• enabling Secure Boot blocks the internal Windows boot path before online servicing can run.

This utility is not a generic key repair. It adds Windows UEFI CA 2023 back to db. It does not create a Platform Key, replace KEK, restore every OEM or Microsoft certificate, modify DBX, or repair a damaged Boot Manager.

1. On a separate trusted x64 Windows 10/11 computer with current Windows servicing updates, verify that this file exists:

   dir C:\Windows\Boot\EFI\SecureBootRecovery.efi
   

2. Use an empty USB drive that is already formatted FAT32. Verify its drive letter in File Explorer or Disk Management before continuing. The example uses R:. Do not format a drive containing needed data.

3. Create the UEFI fallback directory and copy the current recovery application under the x64 fallback name:

   md R:\EFI\BOOT
   copy C:\Windows\Boot\EFI\SecureBootRecovery.efi R:\EFI\BOOT\bootx64.efi
   fc /b C:\Windows\Boot\EFI\SecureBootRecovery.efi R:\EFI\BOOT\bootx64.efi
   

   Continue only if the copy succeeds and fc /b reports no differences.

4. On the affected computer, leave the existing PK, KEK, db, and dbx untouched. Enable Secure Boot if it was returned to off for recovery access, insert the USB, and use the firmware's one-time UEFI boot menu to select that USB. Do not switch to CSM or change storage-controller mode.

5. Allow SecureBootRecovery.efi to run and restart the computer. Do not interrupt it or remove power while it is updating the authenticated variable. If firmware rejects the USB application, reports a variable-write error, or the model is listed by Microsoft or the OEM as incompatible with the current recovery utility, stop.

6. Remove the USB after the recovery utility finishes, then start Windows from the internal Windows Boot Manager.

7. In elevated PowerShell, verify both active Secure Boot and the restored certificate:

   Confirm-SecureBootUEFI
   
   [System.Text.Encoding]::ASCII.GetString(
       (Get-SecureBootUEFI db).Bytes
   ) -match 'Windows UEFI CA 2023'
   

8. After Windows is accessible with Secure Boot enabled, return to Branch C1 to let current Windows servicing verify or apply the remaining certificate transition. Do not describe the device as fully updated merely because this one certificate was restored.

Do not use the bootx64.efi instructions on ARM64, on a device with an absent PK or KEK, on an owner-managed custom-key platform, or when the demonstrated failure is a revoked third-party loader, bad driver, damaged .efi file, or unrelated Automatic Repair loop.

Branch D — Microsoft boot files are damaged or stale

Use this branch when the screen names bootmgfw.efi or winload.efi, the system is UEFI/GPT, the expected keys exist, storage is stable, and current Windows still starts with Secure Boot disabled.

1. From the running Windows installation, repair protected Windows content first:

   DISM /Online /Cleanup-Image /ScanHealth
   sfc /scannow
   

2. If DISM reports that the component store is repairable, run:

   DISM /Online /Cleanup-Image /RestoreHealth
   sfc /scannow
   

3. Do not continue if storage errors occur, SFC names changing files, or correctly matched repair content is unavailable.

4. Confirm that section 7 created the online BCD export, the explicit offline BCD-file copy, and the EFI boot-directory copy.

5. Verify that S: is still the same intended ESP recorded in section 7. Confirm that S:\EFI\Microsoft\Boot\BCD exists and that its {bootmgr} output matches the recorded store:

   dir S:\EFI\Microsoft\Boot\BCD
   bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum {bootmgr} /v
   

   If S: is no longer mounted, mount the current system ESP with mountvol S: /s, then repeat the checks. If more than one ESP exists or the store does not match, stop; do not let BCDBoot choose by trial.

6. Choose exactly one BCDBoot command:

   • If the device has not completed the Windows UEFI CA 2023 transition, use the ordinary current boot files and preserve the existing default loader:

     bcdboot %SystemRoot% /s S: /f UEFI /d /v
     

   • If UEFICA2023Status is Updated, Windows UEFI CA 2023 is present in db, and the local bcdboot /? documents /bootex, use the 2023-signed boot files and preserve the existing default loader:

     bcdboot %SystemRoot% /s S: /f UEFI /d /v /bootex
     

   Do not run the ordinary command and then /bootex as two consecutive repair attempts. The trust state determines which single file set is appropriate.

7. Confirm:

   Boot files successfully created.
   

8. Re-enumerate the same store and confirm that its default and intended Windows loader remain present.

9. Unmount the ESP:

   mountvol S: /d
   

10. Start Windows twice with Secure Boot still disabled. Then enable Secure Boot as the only firmware change and test.

Do not erase or format the ESP. Do not use /bootex from a tool that does not document it, or before the platform trusts the Windows UEFI CA 2023 chain.

Branch E — A boot manager or recovery medium was revoked

Use this branch when event 1037 or 1042 confirms enforcement, an old boot or recovery medium stopped working, event 1033 names a vulnerable file, or event 1798 shows that the default Boot Manager is not yet 2023-signed.

1. Do not remove entries from dbx, reduce SVN, clear keys, or reinstall an older boot manager.

2. Install current supported Windows servicing while Windows is accessible with Secure Boot disabled.

3. Confirm that Windows UEFI CA 2023 exists in db before replacing a PCA2011-signed Windows Boot Manager.

4. Use Branch D to refresh the internal Windows boot files from the updated installation.

5. Replace old recovery or installation media with current Microsoft media. Media created before the revocation can be correctly signed yet still be blocked.

6. When preparing media on a patched system and the local BCDBoot version documents /bootex, preserve its existing BCD, update its boot files with /bootex, and restore the media's BCD according to the media-specific procedure. Do not experiment on the only recovery device.

7. If the rejected file belongs to Linux, a backup product, antimalware, PXE/WDS, or another third-party preboot environment, obtain a currently trusted loader from its vendor.

8. Confirm event 1799 or 1808, or independently verify that the current Boot Manager is accepted with Secure Boot enabled.

Revocations are designed to prevent rollback. Restoring an old disk image or copying an older signed .efi file does not make that loader trusted again.

Branch F — A third-party boot-start driver is rejected

Use this branch only when the recovery screen or Code Integrity log identifies the same third-party .sys file or driver package.

1. From WinRE choose Startup Settings > Restart > Disable driver signature enforcement for one session.

2. If Windows starts, preserve Code Integrity events and the driver file before changing the package. A successful one-session boot supports the signature-enforcement diagnosis; it is not a permanent repair.

3. Identify third-party driver packages from an elevated Command Prompt:

   pnputil /enum-drivers
   

4. Match the named .sys file to the exact published name such as oem42.inf, provider, class, date, version, and owning application. Do not select a package merely because its provider or device class looks similar.

5. Prefer, in order:

   • roll back the driver in Device Manager;
   • uninstall or update the owning application using its normal uninstaller;
   • install a supported Windows 10/11 package from the computer, device, or software vendor.

6. If the exact third-party package is demonstrated and ordinary uninstall is unavailable, remove it without /force:

   pnputil /delete-driver oem##.inf /uninstall /reboot
   

7. Restart normally with signature enforcement active while Secure Boot remains off.

8. Confirm the driver no longer produces a Code Integrity block. Then enable Secure Boot and test.

9. If Windows cannot start for the one-session diagnostic, use System Restore first. Offline removal is a last resort. In WinRE, after mapping Windows as W:, inspect the package:

   dism /Image:W:\ /Get-Drivers /Format:Table
   dism /Image:W:\ /Get-DriverInfo /Driver:oem##.inf
   

10. Remove it only when the exact third-party package and rollback source are verified:

dism /Image:W:\ /Remove-Driver /Driver:oem##.inf

Do not offline-remove an inbox Windows package, storage-controller driver, disk or file-system driver, encryption filter, antimalware early-launch driver, or any package whose boot role is uncertain. Do not delete or rename the .sys file by itself.

Branch G — An unintended BCD signing-policy value is present

Use this branch only when the exported enumeration shows an unexpected production boot-loader value such as testsigning Yes, flightsigning Yes, or nointegritychecks Yes and that value is not required by an intentional development/test configuration.

1. Use the exact loader identifier shown by bcdedit /enum all. In the running Windows installation this is normally {current}, but do not assume that in WinRE or a multi-boot store.

2. Preserve the BCD export from section 7.

3. Turn off test or flight signing only on the demonstrated loader:

   bcdedit /set <loader-identifier> testsigning off
   bcdedit /set <loader-identifier> flightsigning off
   

4. If nointegritychecks is explicitly present, remove that value from the demonstrated loader:

   bcdedit /deletevalue <loader-identifier> nointegritychecks
   

5. Enumerate the same object again and record the result.

6. Restart normally once with Secure Boot off, then enable Secure Boot and test.

Do not enable testsigning, flightsigning, or nointegritychecks to make an untrusted production driver boot. Obtain a compliant driver instead.

• Windows reports UEFI/GPT, current keys exist, and Secure Boot becomes active after enabling it: The firmware state is correct. No partition conversion or key reset is needed.
• PK was undefined, OEM defaults were appropriate, and enrollment changes SetupMode from 1 to 0: The missing Platform Key was the demonstrated cause.
• MBR2GPT validation fails: Leave the bootable Legacy/CSM configuration in place and stop conversion. Secure Boot cannot be enabled on that current legacy boot path.
• Event 1800 disappears after a restart: The update was waiting for a clean boot cycle.
• Event 1801 progresses to 1808: Secure Boot certificate servicing completed.
• SecureBootRecovery.efi restores Windows UEFI CA 2023 and Windows starts: The missing DB trust anchor was repaired. Return to online servicing; this result does not prove that every 2023 certificate update is complete.
• Event 1795, 1802, or 1803 persists: This is an OEM firmware or provisioning stop condition, not permission to force key changes.
• Event 1798 changes to 1799, then the machine starts with Secure Boot: The current 2023-signed Boot Manager replaced the old loader.
• Current Windows starts but old USB, PXE, or recovery media does not: The external medium may be correctly revoked. Replace or update the media rather than weakening firmware trust.
• The one-session signature-enforcement option starts Windows: The named driver or package is strongly implicated. Remove or replace that exact package and return to normal enforcement.
• The one-session option does not change the failure: Signature enforcement alone is not the demonstrated cause. Investigate file corruption, BCD, storage, or another boot-stage failure.
• Automatic Repair continues with no named file, no relevant events, and identical behavior with Secure Boot off: The Secure Boot diagnosis is not confirmed. Return to the general Automatic Repair procedure.
• 0xc000000e, 0xc000000f, or 0xc0000225 remains after signature state is corrected: Diagnose the selected firmware entry, ESP, and BCD references. Do not keep changing keys.

• Do not clear the TPM.
• Do not choose Clear keys, Delete all keys, or Reset to Setup Mode as a troubleshooting shortcut.
• Do not delete or weaken dbx, reduce SVN, or attempt to reverse a security revocation.
• Do not make Secure Boot permanently disabled when the intended Windows configuration supports it.
• Do not enable testsigning, flightsigning, or nointegritychecks as the permanent solution.
• Do not treat 0xc0000428 as proof that firmware keys are missing.
• Do not delete the named .sys, .efi, .exe, or .dll file by itself.
• Do not format, erase, or indiscriminately copy over the EFI System Partition.
• Do not run MBR2GPT on a GPT disk or after validation fails.
• Do not restore OEM factory keys when custom-key ownership is possible.
• Do not change Secure Boot, CSM, controller mode, TPM state, boot order, and keys in one firmware session.
• Do not use old recovery media after DBX or SVN enforcement and assume the internal disk is defective because the media is rejected.
• Do not force Secure Boot certificate deployment through undocumented registry values or scripts copied from another device.
• Do not use SecureBootRecovery.efi as a PK, KEK, DBX, damaged-file, driver, or generic Automatic Repair fix; its scope is restoring Windows UEFI CA 2023 to db.

If enabling Secure Boot reproduces the failure, return only Secure Boot to the recorded off setting. Do not clear keys or change CSM merely to regain access.

If a BCD-policy change makes the previously bootable Secure-Boot-off state worse but the same Windows installation still starts, restore the exported online system store from that installation:

bcdedit /import "%SystemDrive%\BootRepairBackup\SecureBoot\BCD-before-secureboot-repair"

bcdedit /import is valid only for the system store. Do not substitute a WinRE drive letter and assume it targets the offline ESP.

For offline rollback, start WinRE, redetect the affected Windows volume as W: and the proven intended ESP as S:, preserve the failed store, and copy back the explicit BCD-file backup created in section 7:

dir W:\BootRepairBackup\SecureBoot\BCD-file-before
dir S:\EFI\Microsoft\Boot\BCD
copy S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\SecureBoot\BCD-after-failed-change
copy /y W:\BootRepairBackup\SecureBoot\BCD-file-before S:\EFI\Microsoft\Boot\BCD
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum {bootmgr} /v

Stop if either path or the intended ESP cannot be proven. Do not copy a BCD file into the first FAT32 partition found.

Do not automatically restore old .efi files after DBX or SVN revocation; the backup may now contain a correctly blocked Boot Manager. Use a current trusted Windows source instead.

If a driver change fails, use System Restore or reinstall the previously recorded supported driver package. If MBR2GPT completed but UEFI boot fails, the reliable rollback is the verified pre-conversion disk image; switching firmware back to Legacy does not undo the GPT conversion.

If installing OEM default keys fails to produce a bootable Secure Boot state, disable Secure Boot and stop for model-specific firmware support. Do not try to recover by clearing the newly enrolled variables.

If SecureBootRecovery.efi is rejected or does not restore the certificate, return Secure Boot to the recorded off setting for access and stop. Do not attempt to "roll back" by deleting a DB certificate or clearing keys.

• msinfo32 reports BIOS Mode: UEFI and Secure Boot State: On.
• Elevated PowerShell Confirm-SecureBootUEFI returns True.
• SetupMode is 0; expected PK, KEK, db, and dbx variables are defined.
• Windows completes three normal restarts and one full shutdown/cold start without Automatic Repair.
• No new 0xc0000428, firmware violation, or named-file signature error appears.
• The System log has no recurring 1795, 1796, 1801, 1802, or 1803 event requiring action.
• When the 2023 certificate transition was involved, UEFICA2023Status is Updated, the DB contains Windows UEFI CA 2023, and event 1808 or equivalent verification is present.
• Code Integrity no longer blocks the demonstrated driver or boot component.
• Device Manager shows no applicable Code 52 for the repaired driver.
• Current recovery media also starts under the intended Secure Boot policy, or it has been explicitly documented as needing replacement.
• The BCD and EFI evidence backups remain available until several successful boots and a fresh system backup are complete.

The percentages here describe confidence that Secure Boot is the trigger and that the selected mechanism branch is correctly attributed. They are not a forecast that a repair command will succeed. Repair success requires the independent verification in section 12.

Trigger-attribution confidence is approximately 85% when changing only Secure Boot reliably controls the failure and one independent signal identifies the mechanism: SetupMode=1 with no PK, a UEFI/MBR mismatch, 0xc0000428 with a consistent file, matching time-correlated Code Integrity events, or documented DBX/SVN events. Trigger-attribution confidence is approximately 75–80% when Secure Boot consistently triggers Automatic Repair but no file is named; the procedure can still safely narrow the branch, but it must not claim a specific signature cause without supporting evidence.

Stop when custom-key ownership is unknown, MBR2GPT validation fails, an encrypted OS volume does not show suspended protection, storage or memory is unstable, the named component cannot be mapped confidently, recovery media is also rejected and is not current, or a firmware update still produces event 1795, 1802, or 1803. Also stop when Secure Boot off no longer restores the original bootable state, when SecureBootRecovery.efi is rejected or cannot write the variable, when only an old or third-party revoked loader is available, or when the required boot-file or driver source cannot be matched to the installed Windows version.