Recover a Windows logo or spinning-dots stall after a motherboard or major hardware change

After a motherboard, CPU/platform, chipset, or similarly major hardware change, Windows Boot Manager hands off to Windows and the Windows logo or spinning dots appear, but startup never reaches sign-in. The old installation may be waiting on platform enumeration, an incompatible or missing destination driver, ACPI/HAL initialization, a display driver, unstable new hardware, or firmware that does not correctly support the new CPU/platform.

This article focuses on a no-code logo/spinner stall and platform-specific stop codes after the major hardware change. A pre-logo blinking cursor is a boot-loader problem. INACCESSIBLE_BOOT_DEVICE is a storage-path migration problem. A black screen only after sign-in is a shell/display-session problem.

Searchable Windows error codes and exact messages

Search the full stop name or message with the new motherboard/computer model, CPU, firmware version, and any named driver. Do not classify a no-code spinner as 0xA5, 0x5C, or 0x124 unless Windows actually displays or logs that code.

Use this procedure when the failure began immediately after replacing the motherboard, changing the CPU/platform or chipset, or moving an existing Windows 10/11 installation to materially different consumer hardware, and Windows reaches its logo or spinning dots but not sign-in. It is strongest when the installation still starts on the old hardware or in Safe Mode on the new hardware.

Do not use it when firmware cannot see the disk, a blinking cursor appears before the Windows logo, Windows displays INACCESSIBLE_BOOT_DEVICE, the failure followed only a disk clone with no platform change, or the screen becomes black only after sign-in. RAID, SCSI, VMD/IRST, HBA, and other specialist storage migrations remain deferred. Do not use Sysprep as a post-failure repair on an already deployed installation.

The exact Windows build and exact old driver version may remain unknown unless a replacement package depends on them. The old and new motherboard/platform identities, CPU support, firmware version, boot stage, displayed code, storage configuration, Safe Mode result, and availability of the old hardware or a pre-change image may not remain unknown.

• A verified system image and data backup from before the hardware change, or the unchanged old hardware as a rollback path
• Windows Recovery Environment or current Windows 10/11 installation media
• Exact signed Windows 10/11 drivers for the destination motherboard or computer
• Access to the new motherboard/computer support documentation and CPU-support list
• Firmware settings recorded before changing them
• A detected removable volume for driver packages when offline servicing is required
• Standard consumer AHCI/NVMe storage; specialist RAID/SCSI/VMD/IRST paths use a different procedure

If the old platform still starts, do not erase or alter it. Complete Branch A before moving the installation again. If the migration has already occurred, leave the Windows disk unchanged, disconnect unrelated storage and peripherals, record the new firmware settings, and use the minimum supported hardware configuration. Do not change UEFI/legacy mode or controller mode while also diagnosing platform drivers.

In WinRE, use W: only after verifying the offline Windows volume. Use R: only for the detected removable volume that contains exact destination drivers. Prove each proposed letter is unused before assignment; if it is occupied, choose another unused letter and substitute it consistently. Stop when assignment fails or a content check identifies the wrong volume.

1. Confirm the sequence: firmware logo, then Windows logo or spinning dots, then a stall before sign-in. If a blinking cursor appears before Windows, use FIX-031.

2. In firmware, verify that the Windows disk is consistently present with the expected model and capacity.

3. Detect the installed layout and map the offline volumes rather than asking the reader to know the firmware mode:

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

   Confirm that the second detail display still identifies the intended Windows volume. When removable driver media is needed, reopen DiskPart and map it separately:

   diskpart
   list volume
   select volume <driver-media-volume-number>
   detail volume
   assign letter=R
   detail volume
   exit
   

   Confirm that the second detail display still identifies the intended removable volume. Then verify content:

   dir W:\Windows\System32\Config\SYSTEM
   dir "R:\TargetDrivers\<exact-driver.inf>"
   

   Stop if either required file is absent. A GPT disk with an existing EFI System Partition indicates UEFI. An MBR disk with an active NTFS system partition indicates BIOS/MBR Windows 10.

4. Confirm that firmware is starting the verified Windows Boot Manager for that disk. If a one-time selection repairs startup, correct boot order under the boot-target article instead of continuing platform-driver changes.

5. Route explicit codes before proceeding:

   • 0x7B: storage-path article.
   • 0xc000000e or 0xc0000225: boot-device/BCD inspection.
   • 0xc0000428: exact named file and Secure Boot/signature article.
   • 0xA5, 0x5C, or 0x124: Branch F in this article.

6. Manually reverse only individually recorded CPU overclocking, undervolting, XMP/EXPO, and related tuning changes. Set those items to their documented safe values and use a supported baseline memory configuration. Do not load global firmware defaults and do not change storage-controller mode, boot architecture, Secure Boot state, TPM state, or boot order.

7. Disconnect nonessential USB devices, add-in cards, secondary displays, external storage, and secondary internal disks. Keep only the Windows disk, basic input, primary display, and hardware required by the platform.

8. In WinRE, select Troubleshoot > Advanced options > Startup Settings > Restart. Try Enable low-resolution video once, then Enable Safe Mode once.

9. Interpret the result:

   • Low-resolution video starts: focus on the exact destination display/GPU driver.
   • Safe Mode starts but normal mode stalls: a non-core driver, service, or device initialization is likely.
   • Neither starts and a platform stop code appears: use the code-specific branch.
   • Neither starts and there is no code: collect a boot log and offline events before injecting drivers.

10. From Startup Settings, choose Enable boot logging, attempt one normal start, then return to WinRE. Detect the Windows volume and inspect:

    dir W:\Windows\ntbtlog.txt
    type W:\Windows\ntbtlog.txt | more
    

11. Treat the log as comparison evidence. Repeated BOOTLOG_NOT_LOADED entries occur during normal and Safe Mode boots. A line becomes significant only when it names a non-Microsoft driver associated with the new or removed hardware and the same transition fails repeatedly.

12. Query the offline System log for Plug and Play and hardware evidence:

    wevtutil qe W:\Windows\System32\winevt\Logs\System.evtx /lf:true /q:"*[System[Provider[@Name='Microsoft-Windows-Kernel-PnP'] and EventID=219]]" /rd:true /f:text /c:30
    wevtutil qe W:\Windows\System32\winevt\Logs\System.evtx /lf:true /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger'] and (EventID=18 or EventID=19)]]" /rd:true /f:text /c:30
    

13. Look for crash dumps before assuming the stall had no code:

    dir W:\Windows\Minidump\*.dmp
    dir W:\Windows\MEMORY.DMP
    

14. If Safe Mode starts, capture the driver and problem-device state:

    md "%SystemDrive%\BootRepairBackup"
    pnputil /enum-drivers > "%SystemDrive%\BootRepairBackup\drivers-after-hardware-change.txt"
    pnputil /enum-devices /problem > "%SystemDrive%\BootRepairBackup\problem-devices-after-hardware-change.txt"
    copy "%WINDIR%\ntbtlog.txt" "%SystemDrive%\BootRepairBackup\ntbtlog-after-hardware-change.txt"
    pnputil /? | findstr /i "/files"
    

    Run pnputil /enum-drivers /files only if the help output lists /files; that option is not available on every supported Windows 10 build.

Branch A — Prepare a planned migration while the old platform still boots

1. Create and verify a full system image plus a separate copy of irreplaceable data.

2. Record Windows edition and activation state:

   dism /online /Get-CurrentEdition
   slmgr /xpr
   

3. If Windows uses a digital license, confirm in Settings > System > Activation that the intended Microsoft account is linked before the hardware change. Activation is not a boot repair, but this reduces a separate post-migration problem.

4. Export the existing third-party driver inventory and packages to a detected external volume. Create the destination before DISM runs:

   md R:\MigrationBackup
   md R:\MigrationBackup\DriverExport
   pnputil /enum-drivers > R:\MigrationBackup\drivers-before-migration.txt
   pnputil /? | findstr /i "/files"
   dism /online /export-driver /destination:"R:\MigrationBackup\DriverExport"
   

   Use pnputil /enum-drivers /files for an additional file-level inventory only when pnputil /? advertises /files.

5. Download the exact signed Windows 10/11 destination-board chipset, platform, network, and display-driver packages from the board/computer manufacturer. Do not include RAID, VMD/IRST, SCSI, or unrelated models.

6. Stage each exact destination INF in the old running Windows installation. Staging does not force a nonmatching driver onto current hardware:

   pnputil /add-driver "R:\TargetDrivers\<exact-driver.inf>"
   

7. Repeat only for specifically selected destination packages. Save their names and versions with the image.

8. Optional deployment-only Sysprep boundary—not a repair step: Use Sysprep only when this is a deliberate image-deployment workflow, a verified image exists, application/licensing consequences are understood, and the installation is being prepared before capture or transfer. Run:

   %WINDIR%\System32\Sysprep\Sysprep.exe /generalize /oobe /shutdown
   

   /generalize removes machine-specific state and the next start enters OOBE. It can affect activation, provisioning, restore points, event history, device state, and applications. It is not the default one-off consumer repair and must not be run after the migration has already failed.

9. After Sysprep shuts down, do not boot that prepared image again on the source hardware before capture or transfer.

10. Move or deploy the image, start with minimum new hardware, and retain the source image and old platform until verification is complete.

Branch B — Establish a stable new-platform baseline

1. Verify that the installed CPU is listed as supported for the new board and note the minimum required firmware version.

2. If the current firmware does not support that CPU or the vendor release notes specifically address ACPI, CPU, or startup compatibility, use the board manufacturer's supported update method. Do not update firmware during unstable power or without its documented recovery path.

3. Do not load global firmware defaults. Manually return only individually recorded overclock, XMP/EXPO, undervolting, and vendor performance-tuning settings to documented safe values. Leave the recorded boot architecture, storage-controller presentation, Secure Boot state, TPM state, and boot order unchanged.

4. Use the minimum supported memory configuration and only essential devices.

5. Select the verified Windows Boot Manager once and test Safe Mode again.

6. If 0xA5, 0x5C, or 0x124 persists with tuning disabled and supported firmware, stop Windows repair and use Branch F's hardware/firmware route.

Branch C — Safe Mode or low-resolution video starts

1. Preserve the driver and boot-log inventories from section 7.

2. If only low-resolution video starts, install the exact supported destination GPU/display driver. Do not use a third-party mass driver-removal utility as the first action.

3. Install one exact destination platform or device driver at a time:

   pnputil /add-driver "R:\TargetDrivers\<exact-driver.inf>" /install
   pnputil /scan-devices
   

4. Re-run the problem-device inventory:

   pnputil /enum-devices /problem
   

5. Restart normally after each material driver group so the successful change remains attributable.

6. Remove an old-board utility, monitoring tool, RGB/control service, or hardware filter only when its product identity and timing are demonstrated. Prefer its normal uninstaller in Settings > Apps.

7. If one exact third-party driver package remains after its product is removed, create a package-specific directory, export it, and verify its INF before deleting it. Do not use /force:

   md "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>"
   pnputil /export-driver <oem-number.inf> "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>"
   dir "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>\*.inf"
   pnputil /delete-driver <oem-number.inf> /uninstall
   

   Record the exact exported INF filename as <exported-driver.inf>. Hard-stop before deletion if the export fails or its INF is absent.

8. Restart normally twice before reinstalling optional board utilities.

Branch D — Boot logging identifies one exact third-party driver transition

1. Repeat one boot-logging attempt to confirm that the same transition recurs.

2. Compare the normal-start log with a Safe Mode log. Do not select a driver merely because it is the last BOOTLOG_NOT_LOADED line.

3. Match the .sys file to its signed publisher and published INF from the driver inventory.

4. Prefer System Restore to a point before that driver's installation or update.

5. If Safe Mode works, uninstall the exact related product or driver as in Branch C.

6. If Safe Mode does not work, remove an offline third-party package only when its published oem<number>.inf, file, device, and a reinstallable signed rollback package have been established. Export the offline third-party driver repository to the verified external volume first:

   md R:\MigrationBackup\OfflineDriverExportBeforeRemoval
   dism /Image:W:\ /Get-Drivers /Format:Table
   dism /Image:W:\ /Export-Driver /Destination:"R:\MigrationBackup\OfflineDriverExportBeforeRemoval"
   dir /s "R:\MigrationBackup\OfflineDriverExportBeforeRemoval\*.inf"
   dism /Image:W:\ /Remove-Driver /Driver:<oem-number.inf>
   

   Correlate the published name to one exact exported INF and record its full path as <exact-exported-driver.inf>. Hard-stop before /Remove-Driver if the export fails, more than one package remains plausible, or the exact INF cannot be reopened from external storage.

7. Restart once. If the identical stall remains, restore the exact exported package or system image rather than removing more candidates.

Branch E — One exact required destination driver is proven absent

Use this branch only when a dump, boot log, problem device, or destination documentation identifies a specific signed platform driver. Do not use it to inject a complete vendor driver library.

1. Detect W: as the offline Windows volume and R: as the removable driver volume.

2. Capture the existing offline inventory on the verified external volume:

   md R:\MigrationBackup\OfflineDriverAdd
   dism /Image:W:\ /Get-Drivers /Format:Table > R:\MigrationBackup\OfflineDriverAdd\drivers-before-offline-add.txt
   

3. Add exactly one verified driver INF:

   dism /Image:W:\ /Add-Driver /Driver:"R:\TargetDrivers\<exact-driver.inf>"
   

4. Confirm that DISM accepted the package, capture the new inventory, and diff it against the saved inventory:

   dism /Image:W:\ /Get-Drivers /Format:Table > R:\MigrationBackup\OfflineDriverAdd\drivers-after-offline-add.txt
   fc /n R:\MigrationBackup\OfflineDriverAdd\drivers-before-offline-add.txt R:\MigrationBackup\OfflineDriverAdd\drivers-after-offline-add.txt > R:\MigrationBackup\OfflineDriverAdd\driver-inventory-diff.txt
   type R:\MigrationBackup\OfflineDriverAdd\driver-inventory-diff.txt
   

5. Require the diff to show exactly one newly published oem<number>.inf, and record it as <new-oem-number.inf>. If no new package or more than one new package appears, stop before reboot. Do not use /Recurse against a mixed driver folder and do not bypass signature enforcement.

6. Restart once. If the same stall remains, remove only <new-oem-number.inf> using the rollback instructions, then stop adding drivers.

Branch F — Follow the displayed platform stop code

0x000000A5 ACPI_BIOS_ERROR

1. Confirm CPU support and the required firmware version for the exact board revision.

2. Manually reverse only individually recorded tuning changes and use documented safe CPU/memory values. Leave the detected boot architecture, storage mode, Secure Boot state, TPM state, and boot order unchanged.

3. Apply the board vendor's stable firmware update only when it addresses CPU/ACPI/platform support and its recovery method is available.

4. If 0xA5 remains on supported firmware with tuning disabled and documented safe values, stop. BCD, SFC, and driver-pack injection do not repair invalid ACPI firmware behavior.

0x0000005C HAL_INITIALIZATION_FAILED

1. Verify CPU, chipset, firmware, and Windows architecture compatibility.

2. Disable only individually recorded tuning changes and use minimum supported hardware.

3. If the old platform still starts, preserve an image and stage exact destination drivers before another attempt.

4. If 0x5C persists on a supported platform, stop for board/CPU/firmware diagnosis or a clean supported deployment.

0x00000124 WHEA_UNCORRECTABLE_ERROR

1. Disable overclocking, undervolting, XMP/EXPO, and automatic performance tuning.

2. Use a minimum supported memory configuration and verify CPU power/cooling and board power connections.

3. Run the board/OEM memory and hardware diagnostics.

4. Inspect WHEA Event 18 or the crash dump for the reported component only after a boot is possible.

5. If 0x124 repeats with tuning disabled and documented safe values, stop Windows repair; the evidence is hardware/firmware, not a missing BCD entry.

0x000001D5 DRIVER_PNP_WATCHDOG

1. Record the dump and any named driver or device.

2. Disconnect nonessential devices and retest once.

3. Use Safe Mode to update or remove only the exact destination or old-platform device package identified by the dump and PnP inventory.

4. If no device or driver can be attributed, keep the dump and stop mass driver changes.

Branch G — Return to the last bootable platform

1. Reinstall the old motherboard/platform or restore the pre-migration image to its original hardware when practical.

2. Confirm that it starts twice without new errors.

3. Complete Branch A: backup, inventory, stage exact target drivers, and plan the migration deliberately.

4. If the destination remains unsupported or cannot pass stock hardware diagnostics, retain the old installation as the data source and perform a clean supported Windows deployment on the new platform rather than repeatedly modifying the only working image.

• Safe Mode starts and exact destination drivers restore normal boot: The installation could start on the new platform but lacked or conflicted with a normal-mode device path.
• Low-resolution video works: The display path is the leading branch; install the supported target GPU driver and verify normal mode.
• The old platform still boots but the new one does not: Preserve the source, stage exact destination drivers, and retain rollback. Do not treat the new failure as proof that the Windows installation is corrupt.
• 0x7B appears: Route to the storage-path migration article; do not continue generic chipset or display work.
• 0xA5, 0x5C, or 0x124 persists with tuning disabled and documented safe values: The repair boundary has moved to firmware/hardware compatibility.
• Windows starts but reports 0xc004f211 or 0xc004f213: Boot recovery is complete. Use Activation Troubleshooter and the linked digital license separately.
• Boot log shows many BOOTLOG_NOT_LOADED lines: That is normal evidence, not a list of drivers to delete.

• Do not run Sysprep on the already failed migrated installation as a repair attempt.
• Do not mass-remove old motherboard, chipset, ACPI, storage, or filter drivers.
• Do not inject every INF in a vendor download or use DISM /Recurse against a mixed driver library.
• Do not force a HAL, ACPI table, or kernel choice with BCD edits copied from another platform.
• Do not change UEFI/legacy mode and controller mode while also changing platform drivers.
• Do not rebuild BCD for a Windows-logo stall when Boot Manager already handed off successfully.
• Do not troubleshoot activation before Windows can boot reliably.
• Do not enable overclocking, XMP/EXPO, or performance tuning until stock verification passes.

The strongest rollback is the unchanged old platform or verified pre-migration system image. Restore recorded firmware settings if the baseline changes did not help.

Use System Restore to reverse a demonstrated driver or product change. If Branch E added one exact offline driver, remove only its recorded <new-oem-number.inf>:

dism /Image:W:\ /Get-Drivers /Format:Table
dism /Image:W:\ /Remove-Driver /Driver:<new-oem-number.inf>

If Branch D removed an offline package, restore only the exact externally exported INF whose path was recorded before removal:

dism /Image:W:\ /Add-Driver /Driver:"R:\MigrationBackup\OfflineDriverExportBeforeRemoval\<package-folder>\<exact-exported-driver.inf>"

If a Safe Mode package was removed, reinstall its exact exported rollback INF only after returning to the hardware for which that package is correct:

pnputil /add-driver "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>\<exported-driver.inf>" /install

Sysprep generalization has no simple undo command. Restore the verified pre-Sysprep image if its OOBE/generalization effects are unacceptable.

• Windows starts normally twice and completes one full shutdown/cold start on the new platform.
• Safe Mode is no longer required and no persistent safeboot setting was created.
• Device Manager and pnputil /enum-devices /problem show no unresolved boot-relevant destination device.
• No new WHEA-Logger Event 18 or repeating Event 19 appears with tuning disabled and documented safe values.
• The Windows disk remains consistently visible with the expected identity and capacity.
• The intended Windows Boot Manager entry is used without manual selection.
• Optional peripherals are reconnected one at a time without returning the stall.
• Activation is checked only after the boot and hardware baseline remain stable.

Confidence is high when the old platform still boots and Safe Mode, a named destination driver, or a specific platform stop code isolates the new-hardware dependency. Confidence is moderate for a no-code spinner that began with the hardware change but has no corroborating log, dump, or Safe Mode result. Stop if the disk is absent or intermittent; RAID, SCSI, VMD/IRST, or another specialist storage path is discovered; no verified image or old-hardware rollback exists before invasive changes; 0xA5, 0x5C, or 0x124 persists with tuning disabled on supported firmware; the exact driver cannot be identified; the new CPU is unsupported; mass driver or registry removal is the only proposed path; the unlocked-volume standing assumption becomes false; or post-failure Sysprep is being proposed as the remaining repair.