Isolate an OEM-logo boot stall caused by storage or motherboard hardware

The computer repeatedly stops at its manufacturer logo, sometimes before spinning dots appear and sometimes during the firmware-to-Windows handoff. The installed Windows environment, Windows recovery media, or both may stall. Reinstalling Windows or rebuilding boot files does not establish a hardware cause. This writeup reaches a storage-drive or motherboard conclusion only through preboot diagnostics, known-good media, removal or substitution of one component at a time, and a reproducible before/after result.

A static OEM logo is not automatically a Windows error screen. On many UEFI systems, Windows Boot Manager keeps the manufacturer's logo on screen while Windows displays spinning dots beneath it. Record whether dots appear, whether firmware setup remains responsive, and whether known-good external media reaches its first interactive screen.

Searchable Windows error codes and exact messages

There is no unique Windows error code for an OEM-logo stall, and a stall before Windows Boot Manager runs produces no Windows code. OEM diagnostic failure IDs are valuable evidence, but they are manufacturer codes, not Windows error codes.

Record an OEM diagnostic's exact failure ID, validation code, service tag/serial number, test name, and date in the evidence pack. Do not present that identifier as an actual Windows code.

Use this procedure when the OEM-logo stall is repeatable and at least one independent test points below Windows: OEM preboot diagnostics report hardware trouble; a Windows installer or recovery USB that works on another computer also stalls on this one; the behavior changes when an internal drive, cable, slot, memory module, or board is isolated; or an authorized repair's component replacement resolves the stall.

Do not use this procedure when known-good recovery media reaches WinRE normally and only the installed Windows copy fails; when the only proven defect is BCD, an update, a driver, or an incorrect firmware boot entry; when the screen goes black only after sign-in; or when the system drive intermittently disappears from firmware without comparative testing—use FIX-043 first. Do not diagnose a motherboard merely because Windows Setup also fails once; bad USB media, an incompatible port, memory, power, peripherals, and firmware configuration must be controlled.

The exact Windows build, installed edition, and original software state may remain unknown because the decisive tests occur before the installed OS. The exact component may remain unknown until substitution or authorized service. The stage of the stall, whether known-good media was independently verified, firmware's device inventory, OEM diagnostic results, and the outcome with the internal storage path removed or substituted may not remain unknown.

• OEM preboot diagnostics and the exact computer service manual
• A Windows 10/11 installation or recovery USB tested on another compatible computer to its first interactive screen
• A camera to record the logo phase, diagnostic screens, serial numbers, and each configuration
• A current backup or a data-recovery plan before testing the original drive
• Stable AC power and the OEM power adapter where applicable
• Antistatic precautions and qualified service for internal component work
• Known-good compatible memory or storage only when safe and available
• A written test matrix so that one variable is changed at a time

Disconnect docks, external drives, memory cards, printers, and nonessential USB devices. Leave only power, display, keyboard, and the verified recovery USB when it is being tested. Photograph firmware settings and physical connections. Preserve the existing storage-controller mode, Secure Boot state, and boot mode; do not load firmware defaults unless every consequential setting is recorded and the model-specific procedure is understood.

Do not start another Windows installation. Repeated reinstalls write heavily to a possibly failing drive and cannot repair a board, connector, memory, or power defect.

1. Record a continuous video from power-on to the stall. Note the last visible state:

   • static OEM logo with no spinning dots;
   • OEM logo with Windows spinning dots;
   • automatic repair text;
   • a blue-screen code; or
   • a diagnostic or firmware message.

2. Test whether firmware setup and the one-time boot menu open reliably. If the system freezes inside firmware setup, before selecting any boot device, Windows is not running. Prioritize minimum-hardware and OEM service tests.

3. In firmware, record the detected CPU, installed memory total, system drive model/capacity, and firmware version. Do not infer drive detection from the presence of an old Windows Boot Manager entry.

4. Run the OEM preboot quick test. Then run its targeted storage and memory tests. Record the exact test name, completion status, error/failure ID, validation code, serial number, and date. If the system freezes during a particular preboot test, record the test and elapsed time even if no code is generated.

5. Verify the Windows recovery USB on another compatible computer. It must boot through the logo and reach the language, keyboard, or Choose an option screen. Do not install Windows on that comparison computer.

6. Return the verified USB to the affected computer, select it explicitly from the one-time boot menu, and record whether it reaches the same first interactive screen.

7. Interpret that comparison:

   • If the USB reaches Setup/WinRE while the internal drive does not, the board can execute the recovery environment; investigate the internal drive and its path.
   • If the verified USB stalls at the same point, installed Windows and its BCD are not sufficient explanations. Continue isolating peripherals, memory, internal storage, firmware, and board.
   • If the USB behaves differently between ports, record the port. A failed USB port or controller path can mimic bad media.

8. If the original drive contains needed data and is currently readable, stop and back it up before additional stress or substitution.

9. If the internal storage is serviceable, have a qualified person shut down, remove power, and disconnect the internal drive according to the service manual. Boot the verified USB again without installing anything.

10. Interpret the storage-removed test:

    • If the USB now reaches its interactive screen repeatedly, the presence of the drive or its host path triggers the stall. This does not yet distinguish drive from cable, slot, connector, controller, or power.
    • If the stall remains with all internal storage removed, the installed SSD and its Windows copy are not the cause. Continue with memory, peripheral, power, firmware, and board isolation.

11. For a serviceable desktop, reduce to the OEM-supported minimum configuration: one known-good memory module in the documented primary slot, integrated graphics when supported, verified keyboard/display, no add-in cards except those required to display or boot the test. For a laptop or all-in-one, do not improvise minimum-hardware disassembly; use authorized service.

12. Run OEM memory diagnostics in the minimum configuration. If a memory failure follows one module, stop and replace that module. A memory result must be resolved before using a broad WHEA code to blame the motherboard.

13. Isolate a suspected storage path one variable at a time:

    • replace only a SATA data cable;
    • use another supported SATA port;
    • move an NVMe SSD only to a slot confirmed compatible by the manual;
    • test a known-good compatible blank/spare SSD in the original path; or
    • test whether the suspect SSD remains detectable as a secondary device in another compatible system.

    Do not boot the original Windows installation as the system OS on unrelated hardware. Do not write to or initialize the suspect drive during a comparison.

14. Require comparative evidence for a component conclusion:

    Storage-device failure is supported when the failure follows the drive across compatible host paths, a model-specific non-destructive diagnostic fails, and a known-good drive works in the original system.

    Motherboard or onboard storage-path failure is supported when multiple known-good compatible drives or verified boot media fail through the same board path, the failure remains with the original board after memory and peripherals are controlled, or an OEM board diagnostic/authorized replacement confirms it.

15. If Windows occasionally loads, preserve the logs before service:

    md "%SystemDrive%\HardwareEvidence"
    wevtutil epl System "%SystemDrive%\HardwareEvidence\System.evtx" /ow:true
    msinfo32 /nfo "%SystemDrive%\HardwareEvidence\msinfo32.nfo"
    

    Copy any crash dumps and record Device Manager status. In an administrator PowerShell window, extract the records most likely to preserve component detail:

    Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Id=17,18,19} -ErrorAction SilentlyContinue |
      Select-Object TimeCreated,Id,LevelDisplayName,Message |
      Format-List | Out-File "$env:SystemDrive\HardwareEvidence\WHEA.txt"
    

    Do not let generic Event 41 replace the comparative matrix.

Branch A — The failure follows the storage drive

1. Stop stress testing the original drive and preserve it for data recovery.

2. Record its model, serial number, firmware, OEM diagnostic result, and every host path in which the failure followed it.

3. Replace it with an OEM-supported compatible SSD. Do not reuse an intermittently failing drive as a system disk merely because it passes one later test.

4. Confirm that the replacement remains visible in firmware and that the verified Windows USB reaches Setup/WinRE on three cold starts.

5. Restore a verified image or install Windows onto the replacement only after those hardware-path tests pass. Do not overwrite the original drive.

6. Recover data from the original with the least stressful supported method or engage a professional recovery service.

Branch B — The failure stays with a cable, connector, port, or M.2 slot

1. Preserve the one-variable test matrix showing which known-good components passed and failed.

2. Replace the isolated removable cable or use the alternate supported port/slot if the system manual allows it and repeated tests remain stable.

3. If the connector or slot is soldered to the board, stop field repair and request board-level or motherboard service. Do not wedge, bend, tape, or shim a failing connector.

4. Retest both verified external media and the replacement/internal storage before restoring Windows.

Branch C — The motherboard or onboard controller is isolated

1. Save OEM diagnostic codes, the verified-media result, minimum-configuration result, known-good part comparisons, firmware inventory, and video.

2. Check the exact model's OEM support information for a firmware release that specifically addresses boot, storage enumeration, PCIe, or stability. Apply it only with stable power, responsive firmware, the exact package, and an OEM-supported recovery route. Do not flash firmware as a speculative test on an unstable board.

3. If no specifically applicable safe update exists, or the condition persists, arrange authorized motherboard repair or replacement.

4. Give the repair provider the test matrix and request that the replaced component and post-repair diagnostic result be recorded. A repair-center assertion without a before/after test is weaker evidence than a replacement that reproducibly resolves the stall.

5. After board replacement, load only model-correct OEM firmware settings and drivers. Keep the original storage drive unchanged until data and boot verification are complete.

Branch D — A different component is isolated

1. If the stall follows one memory module, power adapter, add-in card, or peripheral, resolve that component instead of forcing the case into the storage/motherboard category.

2. Reassemble the supported configuration one component at a time, testing the verified USB after each addition.

3. Update the condition classification to the component actually demonstrated. Do not retain a motherboard label after a different part explains the result.

Branch E — No component reaches the 80% evidence threshold

1. Return the computer to its recorded supported configuration.

2. Stop reinstalling Windows, resetting firmware, and swapping untracked parts.

3. Escalate with the video, exact stall stage, verified-USB comparison, OEM diagnostics, storage-removed result, memory result, and part matrix.

4. Ask the service provider to test with known-good memory, storage, power, and board components and to document which substitution changes the failure.

• Verified USB works with the internal drive disconnected: investigate the drive and its cable/slot/controller path; this is not yet proof that the drive itself failed.
• Verified USB still stalls with all storage removed: installed Windows, BCD, and the original SSD are not sufficient causes. Continue minimum-hardware and board/power testing.
• Failure follows one SSD across compatible systems: replace/preserve that SSD.
• Known-good SSD and verified USB both fail only on the original system: motherboard, onboard controller, power, memory, or another platform component remains; use OEM diagnostics and minimum configuration to separate them.
• OEM memory test fails: resolve memory before drawing a motherboard conclusion.
• Board replacement alone resolves all media and storage tests: record the replacement as the confirmed resolution.
• A reinstall appears to work once: this is not hardware verification. Complete cold-start, restart, recovery-media, and diagnostic tests.

• Do not claim a Windows error code when the system stopped before Windows ran.
• Do not call the motherboard failed from an OEM logo, Event 41, or one 0x124 alone.
• Do not repeatedly reinstall Windows onto a drive or path under hardware suspicion.
• Do not initialize, clean, format, or overwrite the original drive for a comparison.
• Do not change firmware boot mode or storage-controller mode while isolating hardware.
• Do not load defaults without recording settings that can affect access to the existing installation.
• Do not flash BIOS/UEFI during unstable power, firmware freezes, or an unsupported configuration.
• Do not swap several parts at once; the result will not identify the resolution.
• Do not boot the original Windows installation on unrelated hardware as a diagnostic test.
• Do not open a non-serviceable, soldered, or in-warranty device without the appropriate service path.

Return cables, memory, drives, cards, and firmware settings to the photographed starting configuration after each unsuccessful test. Reinstall the original component only if doing so is safe and does not threaten data; otherwise store it labeled and protected. Firmware updates may not support rollback, which is why speculative flashing is excluded.

If a replacement does not change the stall, remove the replacement, restore the prior supported configuration, and mark that component as not isolated. Do not leave a collection of untracked substitutions in the system.

• OEM preboot quick, targeted storage, and memory diagnostics complete without a failure ID.
• The verified Windows USB reaches its first interactive screen on three cold starts and three restarts.
• The repaired/replaced internal storage remains present in firmware on every test.
• Windows starts normally after restoration or installation and no new matching WHEA or storage-path events appear.
• Sleep/wake and an ordinary workload complete without a freeze or return to the OEM-logo stall.
• The before/after matrix shows that one documented repair changed the result.
• Needed data from the original drive is backed up or its recovery disposition is recorded.

Confidence is approximately 90% when the failure follows a storage device across compatible hosts or a documented motherboard replacement alone resolves a stall that survived verified-media, storage-removed, memory, and minimum-configuration tests. Confidence is approximately 80–85% when multiple known-good components fail only through one onboard path and OEM diagnostics corroborate it. A single logo stall, passed one-time test, Event 41, or generic WHEA stop remains below 80%.

Stop when important data is not backed up, the computer freezes inside firmware, a diagnostic reports a repeatable hardware failure, power is unstable, the device is not safely serviceable, or the comparison cannot separate storage, memory, power, and motherboard. Escalate with the evidence pack rather than adding Windows repair commands to a pre-Windows hardware failure.