Recover a no-boot or repeating firmware-recovery failure tied to BIOS/UEFI firmware

The computer stopped reaching Windows immediately after a BIOS/UEFI firmware update; an exact-model OEM advisory identifies the installed older firmware as the cause of a pre-Windows black/no-boot symptom; or the firmware declares itself corrupt, completes an automatic or USB recovery, restarts, and begins the same recovery again. These are three variations of one firmware-version or persistence mechanism:

• older firmware mishandles display, boot, or platform initialization and the OEM identifies a corrected version;
• the new firmware runs but resets a setting, changes device initialization, or contains a model-specific regression; or
• the firmware image does not remain usable, so the platform repeatedly invokes its own recovery before Windows starts.

The first task is to locate the failure phase. A manufacturer recovery screen, POST failure, blank screen before the Windows logo, LED/beep pattern, or firmware progress bar is not a Windows error and cannot be repaired with BCD, SFC, DISM, Startup Repair, or a Windows reinstall. If Windows Boot Manager or Windows Recovery appears, record its exact code; the firmware may then be stable while a reset boot setting exposes a separate Windows startup problem.

Searchable Windows error codes and exact messages

Search the exact system or motherboard model, the installed firmware version, the prior or attempted version, and the complete displayed message together. A code copied from another machine is not evidence for this one.

Use this procedure when the first no-boot or recovery loop began on the restart that installed a confirmed BIOS/UEFI update, when setup shows that the firmware version changed, or when the firmware itself repeatedly enters a documented automatic recovery. It also applies when an exact-model OEM advisory or release note explicitly identifies the currently installed older firmware and the same pre-Windows black/no-boot symptom, and names a supported corrected version.

The strongest confirmation is one of these results: restoring a recorded setting makes Windows start; an exact-model OEM correction resolves the documented older-firmware defect or newer-firmware regression; an OEM-supported rollback restores startup; or one verified recovery completes and remains persistent across cold starts.

Do not use this procedure merely because Windows Update ran before an unrelated startup failure. Do not use it for a computer whose firmware version did not change, an intermittently disappearing or failing disk, a routine BCD error with stable firmware, a Windows update rollback, a recovery USB that is itself malformed, or a motherboard replacement that has never booted this Windows installation.

If the only screen is INACCESSIBLE_BOOT_DEVICE, use the controller-mode procedure once evidence shows that the firmware reset the storage setting. If the only screen is a Secure Boot violation or 0xc0000428, use the trusted-boot procedure. If firmware recovery completes once and Windows then starts normally, verify the result rather than flashing again.

The exact Windows build, the firmware's internal defect, and the previously installed firmware version may remain unknown during a pre-Windows recovery. The exact model or motherboard revision, the currently reported firmware version when it is readable, the source and filename of any recovery package, whether the package is approved for that exact model, whether the update is actively writing, and the phase at which the loop occurs may not remain unknown.

The user does not need to know the original firmware mode or partition layout. If WinRE is reachable, detect GPT/MBR and the existing partitions. Do not change firmware mode to make the layout fit a guess.

• The exact computer model, service tag/serial number, or retail motherboard model and hardware revision
• The model-specific OEM firmware update and recovery instructions
• Stable AC power; for a portable computer, the OEM-required minimum battery charge and the AC adapter connected
• A second working computer and an empty USB drive only if the exact OEM recovery method requires them
• Photographs of every firmware message, version, progress indication, LED/beep code, and current setting that remains accessible
• The original boot order, storage-controller setting, Secure Boot state, virtualization/security settings, and other nondefault settings when they can be recovered from earlier notes or photos
• A backup of important data before any subsequent Windows repair

Do not begin a new update, rollback, or recovery without the exact model-specific package and procedure. Generic key combinations, filenames, jumpers, and USB layouts are not interchangeable among manufacturers or models.

If a firmware progress bar, flashing LED pattern documented as an active update, or explicit do not power off message is still changing, leave stable power connected and allow the OEM's stated completion time. Do not interrupt an active firmware write because Windows has not appeared yet.

If the machine has already repeated the same completed recovery cycle or has remained unchanged beyond the OEM's documented limit, record the screen and power it off only according to the model's instructions. Disconnect docks, external drives, memory cards, and unnecessary USB devices. Leave required power, display, keyboard, and the OEM recovery USB connected only when the documented recovery method calls for it.

Before changing a setting, photograph every accessible firmware page. Record the exact package filename, where it came from, whether the update was delivered by Windows Update or an OEM tool, and any success or failure text. Do not load defaults, clear CMOS, move a recovery jumper, or attempt another flash as a diagnostic shortcut.

1. Establish the last known-good event sequence. Record whether Windows requested the restart, an OEM update utility displayed a firmware version, or the firmware itself announced an update. A temporal association without a confirmed firmware-version change is weaker evidence.

2. Identify the first screen in each cycle:

   • no manufacturer logo or POST, a black screen, or a firmware corruption/recovery screen means the failure is before Windows;
   • a manufacturer logo followed by Windows Boot Manager, spinning dots, a blue-screen stop code, or WinRE means firmware has progressed far enough to hand off toward Windows;
   • a manufacturer logo followed by another automatic flash or recovery, before Windows Boot Manager, is the repeating-firmware-recovery variation.

3. If firmware setup opens, record rather than change:

   • the model and serial/service identifier;
   • firmware version and date;
   • whether the internal Windows disk is consistently listed;
   • boot order and, only on a detected GPT/UEFI installation, the presence of Windows Boot Manager; a BIOS/MBR installation normally exposes the physical system disk instead;
   • storage-controller configuration;
   • Secure Boot status and whether factory or custom keys are reported;
   • date/time and any indication that settings reset on every power cycle.

4. If the internal disk is absent, appears intermittently, firmware settings will not persist, or the firmware reports a CPU, board, flash-storage, power, or memory fault, stop. Windows repair commands are not the next step.

5. If the detected layout is GPT/UEFI and the one-time boot menu lists Windows Boot Manager for the intended disk, select it once without changing other settings. On a detected BIOS/MBR installation, select the proven physical system disk instead; do not require or invent a UEFI NVRAM entry.

6. Interpret that one test:

   • If Windows starts, the update probably reset boot order; use Branch A.
   • If 0x0000007B appears, record it and compare the current controller setting with the recorded pre-update setting; use the dedicated controller-mode procedure rather than trying every mode.
   • If a Secure Boot violation or 0xc0000428 appears, preserve the named file and use the trusted-boot procedure.
   • If 0xc000000e, 0xc0000225, 0xc000000f, or 0xc0000098 appears, firmware is now handing off to Windows. Photograph the full code, File:, and Info: fields. Stabilize firmware first, then route by the named object—not by the code alone.
   • If firmware recovery begins again before the selection is possible, use Branch D or E.

7. If WinRE or current Windows installation media boots, inspect the physical disk and partition layout without changing it:

   diskpart
   list disk
   list volume
   exit
   

   The GPT asterisk and existing volume/partition characteristics supply the layout evidence. Do not switch UEFI/legacy mode, initialize a disk, mark a random partition active, or format an existing FAT32 volume.

8. If Windows starts by any reversible branch, capture the installed firmware and exact system identity from an administrator PowerShell window:

   Get-CimInstance Win32_ComputerSystemProduct | Format-List Vendor,Name,Version,IdentifyingNumber
   Get-CimInstance Win32_BIOS | Format-List Manufacturer,SMBIOSBIOSVersion,ReleaseDate
   

9. Compare that identity and version with the OEM's affected-model notice, release notes, change log, recovery page, and downgrade restrictions. For an older-firmware black/no-boot case, the notice must explicitly match the exact model, installed version range, and symptom; general advice to “update BIOS” is not sufficient. A package for a similar product name, a different board revision, or an unverified mirror fails this check.

10. Classify the repair path:

    • Settings reset, firmware otherwise stable: Branch A.
    • OEM lists the installed older version or newer regression version as affected and a corrected version exists: Branch B.
    • OEM explicitly permits rollback to a known-good version: Branch C.
    • No POST or firmware reports corruption and offers supported recovery: Branch D.
    • A verified recovery reports success but starts again on every cold boot: Branch E.
    • Firmware is stable and only a Windows code remains: Branch F.

Branch A — Restore only the setting demonstrated to have reset

1. Use the successful one-time selection as evidence before changing persistent boot order: Windows Boot Manager for detected GPT/UEFI, or the proven physical system disk for detected BIOS/MBR.

2. In firmware setup, place that same proven target ahead of network/PXE, HTTP boot, UEFI shell when present, diagnostics, USB, and unrelated disks. Do not change firmware mode or repartition the disk.

3. If the screen is INACCESSIBLE_BOOT_DEVICE and the pre-update controller setting is documented, restore that exact setting. This applies to any HDD, SATA SSD, or other Windows disk using that controller path; it is not an SSD-specific repair.

4. Do not switch among AHCI, compatibility, RAID, VMD, or vendor modes by trial and error. If the former setting is unknown, preserve the current screen and use the controller-mode decision procedure.

5. Save only the proven change, shut down fully, and test two cold starts. Do not disconnect AC or remove a battery unless the exact OEM procedure requires it.

6. If the setting reverts again, stop treating it as a one-time configuration reset. Firmware settings that do not persist require OEM diagnosis of RTC/CMOS power, NVRAM, firmware storage, or motherboard state.

Branch B — Apply the OEM's corrected firmware for an exact-model documented defect

1. Confirm that the OEM notice or release note names the exact model or board revision, the currently installed affected version or version range, the same pre-Windows symptom, and a corrected version. This may be an older-firmware initialization defect or a regression in a newer release.

2. Download the corrected package only through the OEM's product-identified support path. Verify any OEM-published checksum or digital signature and preserve the filename and version. Do not update merely because a newer version exists; the exact advisory match is the authorization for this branch.

3. Read the package-specific instructions completely. Confirm required intermediate versions, embedded-controller or management-engine dependencies, update method, battery threshold, AC requirement, and whether settings will reset.

4. Use the OEM's supported preboot, USB, recovery, or operating-system update route exactly as specified. Do not substitute another model's key combination, recovery filename, or command-line switch.

5. Maintain stable power and do not use the machine, close the lid, press keys, remove media, or force a restart while the documented update is active.

6. After the OEM reports completion and restarts, enter setup once. Record the new version and confirm the proven startup target remains visible—Windows Boot Manager for detected GPT/UEFI, or the physical system disk for detected BIOS/MBR. Compare each security, controller, and boot setting with the pre-update record.

7. Correct only settings that the record proves were changed. Then test Windows startup and two cold starts.

Branch C — Use an OEM-supported rollback only when the regression is proven

1. Confirm that the OEM explicitly supports downgrading this exact model from the installed version to the chosen earlier version. A package's availability does not itself prove rollback support.

2. Check for OEM warnings about anti-rollback, security fixes, capsule policy, embedded-controller versions, CPU support, or a minimum allowed firmware. Do not bypass a blocked downgrade.

3. Verify the older package's exact model/revision match and OEM signature or checksum.

4. Connect stable AC power and meet the OEM battery requirement. Use only the documented rollback or recovery method and its exact prompts.

5. Do not select options that erase security keys, service identifiers, asset data, or NVRAM unless the model-specific instructions require them and their consequences are understood.

6. When rollback completes, record the installed version and restore only the documented prior settings. Before changing BCD, test the one-time Windows Boot Manager path for detected GPT/UEFI or the proven physical system disk for detected BIOS/MBR.

7. Prevent the known-bad version from being reapplied only through the OEM's or Windows Update's supported deferral/remediation mechanism. Do not disable all firmware or security updates indefinitely.

Branch D — Perform one exact OEM firmware recovery for no POST or reported corruption

1. Locate the recovery instructions by exact model/service identifier. Confirm that the model supports the proposed built-in, hard-drive, USB, button/key, or service-jumper method.

2. Prefer the OEM-designated first recovery method. Some systems search an internal recovery image first; others require a specifically prepared FAT32 USB, filename, directory, port, or keyboard sequence. Follow only the instructions for this model.

3. If USB recovery is required, prepare a dedicated USB on a working computer. Obtain the recovery image from the OEM product page, verify its identity, and place or rename it exactly as the OEM specifies. Do not copy a normal BIOS updater and invent a recovery filename.

4. Connect stable power and meet the battery threshold. Remove unrelated media. Initiate recovery using the exact model-specific sequence.

5. Once recovery begins, do not interrupt it. Record each stage and wait through the OEM-documented completion and restart period.

6. When the firmware explicitly reports success, follow the OEM instruction about removing the recovery USB. A USB left attached can cause some platforms to prefer it again.

7. Enter setup, record the recovered version, and verify that the version and settings survive a shutdown and cold start before attempting Windows repair.

Branch E — Stop a repeating automatic firmware-recovery cycle

1. Confirm that each cycle returns to a firmware recovery screen before Windows Boot Manager and that the progress or success message is genuinely repeating.

2. If a recovery USB is attached and no write is active, power down according to the OEM instructions, remove the USB, and cold-start once. This distinguishes repeated USB selection from recovery stored on the machine.

3. If recovery no longer repeats, enter setup, verify the installed version, boot order, disk visibility, and settings persistence. Do not reinsert the USB merely to repeat a successful recovery.

4. If automatic recovery still repeats, verify the exact recovery image, model, required filename, package integrity, power conditions, and documented recovery method from the beginning.

5. Permit only one controlled retry after correcting a demonstrated packaging, filename, media, or power error. Record whether the firmware reports image missing, image invalid, verification failure, write failure, success, or a model-specific LED/beep code.

6. If the exact OEM image verifies and recovery reports success but the same recovery starts again, or the reported firmware version/settings do not persist, stop. This is evidence for failed firmware storage, NVRAM, RTC/CMOS power, embedded-controller coordination, or motherboard failure—not a Windows problem.

7. Escalate with the model/service identifier, attempted versions, package filename/hash when available, photographs, recovery result, power state, and persistence test. Do not erase Windows or keep reflashing while waiting for service.

Branch F — Firmware is stable but a specific Windows startup error remains

1. Cold-start twice and confirm that firmware no longer recovers, the internal disk remains consistently visible, and settings persist.

2. Select the proven startup target once—Windows Boot Manager on detected GPT/UEFI, or the physical system disk on detected BIOS/MBR—and record the exact Windows code, File:, and Info: text.

3. Route by evidence:

   • 0x0000007B: restore or transition the proven storage-controller mode using the controller-mode procedure;
   • 0xc0000428: use the trusted-boot or named-file procedure; the code alone does not prove firmware keys;
   • 0xc000000e, 0xc0000225, 0xc000000f, or 0xc0000098 with File: \Boot\BCD or File: \EFI\Microsoft\Boot\BCD: back up the readable BCD and use the matching BCD procedure;
   • any of those codes with a named .sys, .efi, .exe, or other binary: use the driver/system-file procedure for that named file;
   • any of those codes with File: \Windows\System32\Config\SYSTEM: use the registry-hive procedure;
   • no named file plus required-device/inaccessible-device text: use the required-device procedure;
   • Automatic Repair couldn't repair your PC: preserve and inspect SrtTrail.txt.

4. Do not flash firmware again solely because the remaining Windows code appeared after the original update.

• The one-time proven startup target starts Windows: Persist only the corrected boot order—Windows Boot Manager for GPT/UEFI or the physical system disk for BIOS/MBR; the firmware image is probably usable.
• Restoring the documented controller setting removes 0x7B: Keep that setting and use a planned driver transition before any future mode change.
• A corrected OEM firmware version restores startup: Preserve the affected and corrected versions, the exact-model advisory match, and repeated cold-boot results.
• An OEM-supported rollback works: Keep the known-good version until the OEM publishes a compatible correction.
• One OEM recovery completes and remains stable: Reconfigure only settings shown to have reset, then verify Windows separately.
• Recovery repeats only while its USB remains attached: Remove the media after the documented success point and correct persistent boot order if needed.
• Recovery repeats without USB after a verified successful write: Escalate as firmware-storage, NVRAM, embedded-controller, or motherboard failure.
• Firmware is stable but a Windows code remains: Stop reflashing and use that code's Windows repair path.
• The internal disk disappears or settings change between starts: Stop for hardware/OEM diagnosis; do not alter partitions or BCD.

• Do not interrupt an active firmware write because its screen appears idle for a few minutes.
• Do not cross-flash a similar model, force a package past its platform check, or use an unofficial modified image.
• Do not bypass anti-rollback, signature, capsule, embedded-controller, or minimum-version protections.
• Do not try controller modes in random order or describe the problem as SSD-specific; the controller path can serve HDDs or SSDs.
• Do not clear CMOS, move a recovery/service jumper, disconnect an internal battery, or short board contacts unless the exact service manual for that exact revision instructs it.
• Do not erase Secure Boot keys, TPM data, service tags, asset data, or NVRAM as a generic reset.
• Do not use BCD, SFC, DISM, CHKDSK, Reset, or reinstall commands to repair a loop that occurs before Windows Boot Manager.
• Do not repeatedly run the same recovery after it reports success without testing media removal and persistence.
• Do not flash from an unstable Windows session, an unreliable power source, or a nearly discharged battery.

Restore a changed boot, controller, or security setting from the photographs and written pre-change values. There is no universal undo for a firmware write. A firmware rollback exists only when the OEM explicitly supports the exact source and target versions; use no generic force switch.

If an attempted settings correction makes the symptom worse, restore the one changed setting before trying another branch. If a recovery USB causes repeated selection, remove it only after the OEM-documented completion point. If the firmware no longer reaches setup or cannot retain the recovered image, stop rather than attempting an improvised rollback.

• Firmware POST completes without corruption, recovery, or update messages.
• The reported firmware version is the intended corrected, recovered, or supported rolled-back version.
• The version, date/time, disk detection, boot order, controller setting, and security settings persist across two cold starts. A Windows Boot Manager NVRAM entry is required only for a detected GPT/UEFI installation; a detected BIOS/MBR installation is verified by the correct physical disk target.
• The internal Windows disk is detected consistently.
• Windows completes three normal starts and one cold boot without the recorded boot code or Automatic Repair loop.
• The recovery USB can remain disconnected during ordinary startup.
• No new 0x0000007B, 0xc000000e, 0xc0000225, 0xc000000f, 0xc0000098, or 0xc0000428 appears.
• The OEM-specific function affected by the firmware correction remains usable after power removal and restart.

Confidence is approximately 85–90% when the firmware version demonstrably changed on the first failed restart and a documented setting restoration, OEM correction, supported rollback, or verified recovery produces repeatable cold starts. The same range applies when an exact-model OEM advisory explicitly matches the installed older version and pre-Windows symptom and the named corrected version fixes repeated cold starts. Confidence is approximately 75–80% when timing is the primary evidence but the exact old version is unavailable. A repeating recovery that reports success yet does not persist is high-confidence evidence that Windows repair is out of scope, but it does not identify which board component failed.

Stop immediately when the exact model or package cannot be proven, an update is still actively writing, stable power cannot be maintained, the disk or firmware settings are intermittent, the OEM blocks rollback, the recovery image fails verification, the board reports a hardware fault, or one verified recovery reports success and then repeats. Escalate rather than improvise firmware filenames, jumpers, key combinations, or force-flash options.