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.

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.

Before you start:

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.

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.

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.

Check the cause

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.
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.
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.
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.
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.
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.
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.
If the original drive contains needed data and is currently readable, stop and back it up before additional stress or substitution.
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.
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.
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.
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.
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.
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.

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

Stop stress testing the original drive and preserve it for data recovery.
Record its model, serial number, firmware, OEM diagnostic result, and every host path in which the failure followed it.
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.
Confirm that the replacement remains visible in firmware and that the verified Windows USB reaches Setup/WinRE on three cold starts.
Restore a verified image or install Windows onto the replacement only after those hardware-path tests pass. Do not overwrite the original drive.
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

Preserve the one-variable test matrix showing which known-good components passed and failed.
Replace the isolated removable cable or use the alternate supported port/slot if the system manual allows it and repeated tests remain stable.
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.
Retest both verified external media and the replacement/internal storage before restoring Windows.

Branch C — The motherboard or onboard controller is isolated

Save OEM diagnostic codes, the verified-media result, minimum-configuration result, known-good part comparisons, firmware inventory, and video.
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.
If no specifically applicable safe update exists, or the condition persists, arrange authorized motherboard repair or replacement.
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.
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

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.
Reassemble the supported configuration one component at a time, testing the verified USB after each addition.
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 has sufficient diagnostic evidence

Return the computer to its recorded supported configuration.
Stop reinstalling Windows, resetting firmware, and swapping untracked parts.
Escalate with the video, exact stall stage, verified-USB comparison, OEM diagnostics, storage-removed result, memory result, and part matrix.
Ask the service provider to test with known-good memory, storage, power, and board components and to document which substitution changes the failure.

Check the result

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.
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.

To undo the change:

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.

Preparation, backups and recovery reference

Sources and evidence

Case reports describe observed outcomes. They do not establish a measured success rate or independent laboratory reproduction.

System unable to display or power on after BIOS update - ThinkStation P330 SFF/Tower — documentation
No display after custom image or Windows update deployment - ThinkPad T490/T590/P53/P53s/X390/T490s — documentation
Computer occurs black screen when the BIOS update process is interrupted — documentation
Dell Latitude wont boot past BIOS after Windows 10 update — reported case
Startup Repair Loop, maybe hard drive problem? — reported case

Windows error codes and exact messages

Displayed identifier	Windows name or exact message	When it can apply
No Windows code	Search phrases: Stuck on manufacturer logo, stuck on OEM logo without spinning dots, Windows USB freezes at logo	Primary symptom descriptions, not Windows error text. They identify a stage to test, not a failed component.
`0x00000124`	`WHEA_UNCORRECTABLE_ERROR`	Windows received a fatal hardware error record. The WHEA record and bug-check parameters are required to narrow the component; the stop code alone does not prove motherboard or SSD failure.
WHEA-Logger event `17`	A corrected hardware error has occurred.	Often records a corrected PCI Express error. Preserve the component and bus/device/function; the event does not by itself distinguish an add-in device, slot, board, power, or firmware cause.
WHEA-Logger event `18`	A fatal hardware error has occurred.	Commonly carries an uncorrectable machine-check record. Preserve the error source, reported component, processor/APIC data, and raw record rather than assuming the board failed.
WHEA-Logger event `19`	A corrected hardware error has occurred.	Hardware reported and corrected an error. Repeated matching records are relevant, but a corrected event alone is not a component verdict.
Kernel-Power event `41`	The system has rebooted without cleanly shutting down first.	Confirms an unclean shutdown, freeze, crash, or power loss. It does not identify the cause or prove a power-supply or motherboard failure.
System event `129`	Reset to device, \Device\RaidPort1, was issued.	A storage timeout caused Storport to reset the path. Correlate it with the affected physical disk and comparative tests.
System event `153`	The IO operation at logical block address `<address>` for Disk `<number>` was retried.	A storage request timed out and was retried. It supports a storage-path investigation but not a component conclusion.
System event `157`	Disk `<number>` has been surprise removed.	A fixed disk disappeared from Windows. If the same drive is also absent from firmware, use FIX-043 before calling the motherboard failed.
`0x0000007A`	`KERNEL_DATA_INPAGE_ERROR`	A kernel page could not be read from the paging file. Storage and RAM are possible; use parameter 2 and the surrounding events.
`0x0000007B`	`INACCESSIBLE_BOOT_DEVICE`	Windows lost access to the system partition during startup. Storage hardware, controller configuration, and boot-driver causes remain possible.
`0x00000154`	`UNEXPECTED_STORE_EXCEPTION`	The kernel memory-store component caught an unexpected exception. It is not, by itself, an SSD or motherboard verdict.
`0xc000000e`	A required device isn't connected or can't be accessed	Boot Manager cannot access a referenced device. Check firmware detection and the hardware path before BCD repair if the drive is intermittent.
Device Manager `Code 10`	This device cannot start. (Code 10) followed by Try upgrading the device drivers for this device.	A disk, storage controller, PCIe root port, or other device enumerates but cannot start. Use the exact device instance.
Device Manager `Code 43`	Windows has stopped this device because it has reported problems. (Code 43)	A device or its driver reported failure. It does not identify the motherboard as the failed part.