Diagnose a failing or intermittently disappearing Windows system drive

Windows crashes, freezes, or stops booting, and the system HDD, SATA SSD, or NVMe drive is then absent from firmware setup, the one-time boot menu, Windows Recovery Environment, Disk Management, or Device Manager. The drive may return only after a complete shutdown and removal of power, after it is reseated, after it is moved to another compatible slot or port, or after a cable, drive, or motherboard is replaced.

This is an enumeration or communication failure first, not a BCD problem. Windows cannot repair a drive that the firmware and storage controller cannot consistently detect. A full power removal that temporarily restores the device is useful evidence because it resets the drive electronics and host storage path; it is not a durable repair.

The same detection-first rule applies to a hard disk, SATA SSD, and M.2 NVMe SSD; only their cable, slot, power, thermal, and model-specific diagnostic branches differ. A SATA controller-mode change can affect an HDD or an SSD, but do not change controller mode during this procedure: an unexplained mode change is a separate configuration problem.

There is no unique Windows error code for a system HDD, SATA SSD, or NVMe drive that intermittently disappears. If the drive vanishes before Windows starts, there may be no Windows-generated message at all. Use only identifiers that the affected computer actually recorded.

Do not search an event or stop code without its drive model, event provider, faulting device, bug-check parameters, and timing. Event 129 alone can describe a timeout; Event 157 plus the same drive disappearing from firmware is substantially stronger evidence.

Use this procedure when a system HDD, SATA SSD, or M.2 NVMe SSD is sometimes absent from the firmware inventory or disappears from Windows after a crash, freeze, sleep/wake transition, restart, or power event. It also applies when the drive returns after a complete power removal, reseat, compatible slot or port change, known-good cable change, or component replacement.

Do not use this procedure when the drive is detected consistently by firmware and WinRE but Windows reports only a BCD, loader, update, or file-system error. Do not use it for a storage-controller mode that was deliberately changed, a USB enclosure that disconnects, a disk that is merely absent from the firmware boot order while still present in the firmware storage inventory, or a post-login black screen. Use the branch that matches the physical path: SATA HDD/SSD or M.2 NVMe.

The exact Windows build, the crash's original trigger, and whether the defective part is the drive, cable, connector, M.2 slot, motherboard, power path, or firmware may remain unknown during the first pass. The drive's model and serial number, whether firmware detects it in each test state, whether the failure follows the drive or stays with the host path, and whether important data has been backed up may not remain unknown before repair or firmware work.

Related cases:

Diagnose BSODs resolved by replacing a failing system drive

Before you start:

A separate destination for an immediate backup or image when the drive is readable
A phone or camera to record firmware inventory, OEM diagnostics, and each test state
The computer's service manual and supported storage specifications
The drive manufacturer's model-specific diagnostic and firmware utility, when one exists for the exact model
OEM preboot diagnostics, when available
For a serviceable SATA drive: a known-good compatible data cable, power connector, and port
For a serviceable M.2 drive: antistatic precautions and a technician if opening the device would be unsafe or void coverage
A known-good compatible spare drive or a second compatible computer for controlled comparison, when available

Do not begin an extended stress test or firmware update until irreplaceable data is backed up. If the drive contains the only copy of important data and is unstable, stop ordinary troubleshooting and use a qualified data-recovery service.

Disconnect unrelated external storage and record the current firmware storage settings without changing them. Do not initialize, format, clean, convert, repartition, or run Startup Repair against an intermittently missing device. Do not repeatedly power-cycle the drive simply to see how many times it will return.

If Windows currently starts and the drive is readable, copy the most important data first. Favor a single, prioritized backup pass over benchmarks, full-surface scans, CHKDSK /r, or repeated cloning attempts. If ordinary copying produces timeouts, disconnects, or rapidly falling throughput, stop and reassess whether professional recovery is required.

Do not initialize, format, clean, convert, repartition, or reinstall Windows onto an intermittently disappearing drive.
Do not run CHKDSK /f or /r, a full-surface test, or a benchmark before preserving irreplaceable data.
Do not rebuild BCD when firmware cannot consistently see the physical drive.
Do not change SATA/AHCI/RAID/VMD controller mode during an enumeration investigation.
Do not hot-plug an internal system drive or reseat hardware while power is connected.
Do not flash BIOS or drive firmware while power or device detection is unstable.
Do not increase TimeOutValue or another storage timeout to hide resets without vendor guidance.
Do not treat Kernel-Power Event 41, a passed one-time diagnostic, or one successful boot as identification of the failed part.
Do not change cable, port, drive, driver, and firmware at once; doing so destroys the comparison.

Stop immediately if the drive holds the only copy of important data, produces increasing read errors, becomes unusually hot or physically damaged, disappears during backup, cannot remain detected for a supported firmware operation, or requires opening a non-serviceable device. Stop and obtain professional hardware or data-recovery help when the test cannot distinguish the drive from the board, connector, or power path.

Check the cause

Build a state table with one row for each occurrence. Record:
- time and preceding event: crash, sleep, restart, normal shutdown, or power loss;
- whether firmware lists the exact drive model and capacity;
- whether Windows Boot Manager appears for that drive;
- whether WinRE diskpart lists the physical disk;
- whether a complete shutdown and removal of power changes the result; and
- any storage event, stop code, OEM code, or diagnostic result.
At the next missing-drive occurrence, enter firmware setup before attempting Windows repair. Photograph the storage or NVMe inventory. Do not count a missing Windows Boot Manager entry as a missing drive unless the firmware's physical-device inventory also omits the drive.
If firmware does not list the physical drive, stop using BCD, CHKDSK, SFC, DISM, and Windows reinstall commands. Continue with the powered-off hardware-path branches in the repair steps.
If firmware lists the drive, boot WinRE and inspect without changing layout:
```
diskpart
list disk
list volume
exit
```
Match capacity and volume contents to the already identified Windows installation. If firmware lists the drive but DiskPart does not, record that boundary; the storage driver/controller path or the device can still be failing.

When Windows is usable, open an administrator PowerShell window and capture the current identity and health views:

New-Item -ItemType Directory -Force "$env:SystemDrive\StorageEvidence" | Out-Null
Get-Disk | Format-List Number,FriendlyName,SerialNumber,UniqueId,BusType,HealthStatus,OperationalStatus,Size | Out-File "$env:SystemDrive\StorageEvidence\Get-Disk.txt"
Get-PhysicalDisk | Format-List FriendlyName,SerialNumber,UniqueId,MediaType,BusType,HealthStatus,OperationalStatus,Size | Out-File "$env:SystemDrive\StorageEvidence\Get-PhysicalDisk.txt"
Get-PhysicalDisk | Get-StorageReliabilityCounter | Format-List * | Out-File "$env:SystemDrive\StorageEvidence\StorageReliability.txt"

Get-StorageReliabilityCounter is not supported through every consumer controller. An empty or unsupported result is not a pass and is not a failure; record it as unavailable.

Export the System log before it rolls over:

wevtutil epl System "%SystemDrive%\StorageEvidence\System.evtx" /ow:true

Extract the most relevant storage events in PowerShell:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7,11,51,55,98,129,153,157} -ErrorAction SilentlyContinue |
  Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message |
  Format-List | Out-File "$env:SystemDrive\StorageEvidence\StorageEvents.txt"
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Id=17} -ErrorAction SilentlyContinue |
  Select-Object TimeCreated,Id,LevelDisplayName,Message |
  Format-List | Out-File "$env:SystemDrive\StorageEvidence\WHEA-PCIe.txt"

Correlate events to the physical drive. Do not assume Disk 0 is the Windows drive. Compare the disk number, model, serial number, controller, and time. In running Windows, confirm echo %SystemRoot%, then preserve dumps from %SystemRoot%\Minidump or %SystemRoot%\MEMORY.DMP if they exist; absence of a dump can itself occur when the system disk vanishes during crash-dump writing.
Open Device Manager, expand Disk drives and Storage controllers, and inspect Device status and the Events tab. Record any Code 10, 24, 43, or 45 and the exact device instance. Showing hidden devices can reveal a formerly enumerated instance, but a gray icon is not proof that the hardware failed.
Run the OEM preboot quick storage test and record the complete result, model, failure ID, and validation code. If the quick test passes, that proves only that the drive responded during that test. Run an extended non-destructive test only after the backup and only if the vendor identifies it as safe for the exact drive.
Compare a normal restart with a true shutdown. If Windows is usable, execute:
```
shutdown /s /t 0
```
After power-off, wait for the system to shut down completely, then start and recheck firmware inventory. Do not repeatedly remove power from a running system.
Classify the evidence before changing parts:
- Failure follows the drive: the same drive disappears in another compatible slot/port/system, or its vendor diagnostic reports a repeatable failure while a known-good compatible drive works in the original path.
- Failure stays with the host path: more than one known-good compatible drive fails in the same slot/port while the suspect drive remains stable elsewhere.
- SATA path implicated: a known-good cable or motherboard port changes the result.
- Not isolated: a single timeout event, one passed diagnostic, or one successful reboot provides no component-level conclusion.

Branch A — The drive is absent from firmware and returns only after complete power removal

Treat the next readable interval as a data-preservation window. Complete the prioritized backup before updates or tests.
Record the drive model, serial number, current drive firmware when reportable, system BIOS version, and whether the failure follows warm restart, sleep/wake, or a crash.
Perform one controlled complete shutdown, remove AC power using the computer manufacturer's shutdown procedure, and reconnect power only after the device is fully off. For a laptop with a non-removable battery, use only the model's documented power-reset procedure; do not improvise battery disconnection.
Recheck firmware inventory before Windows starts. If the drive returns, label the action temporary controller/path reset, not fixed.
Check the OEM and drive-manufacturer support information for a firmware release that explicitly applies to the exact model and addresses detection, resume, reset, or stability. Update only after backup, with stable AC power, reliable drive detection, the exact package, and a supported update method.
If the drive is not reliably detectable long enough for a supported update, do not flash it. Proceed to comparative hardware testing or replacement.

Branch B — A serviceable SATA HDD/SSD or its SATA path is implicated

Shut down fully, disconnect AC power, and follow the service manual. Do not hot-plug an internal system drive.
Photograph the existing SATA data and power connections.
Reseat both ends of the SATA data cable and the drive's power connector. Test without changing any other variable.
If the failure recurs, replace only the SATA data cable with a known-good compatible cable. Retest cold start, restart, and sleep/wake.
If it recurs, move only the data cable to another supported motherboard SATA port. Preserve the current controller mode; do not switch AHCI, RAID, IDE, VMD, or another mode.
If available, test the drive through a known-good compatible host path and test a known-good compatible SATA drive through the original path. Do not boot the suspect Windows installation as the operating system of an unrelated computer; attach it only for controlled diagnostics or data recovery.
Replace the drive when the failure follows it. Replace or service the cable, connector, power lead, or motherboard when the failure stays with that path. A passed one-time SMART check does not overrule a reproducible disappearance.

Branch C — A serviceable M.2 NVMe SSD or its slot is implicated

Shut down, remove AC power, and use the model-specific service manual and antistatic precautions. If the SSD is soldered, covered by warranty restrictions, or difficult to access, stop and use authorized service.
Record the installed M.2 slot, screw/standoff position, heat spreader, thermal pad arrangement, and SSD label before removal.
Reseat the SSD squarely in the same compatible slot, reinstall the correct retention screw, and restore the original thermal components exactly as documented. Test without changing firmware settings.
If the issue recurs and the manual confirms another slot supports that SSD type and size, move the SSD to that compatible slot for a controlled comparison. Some M.2 slots share resources or support different protocols; physical fit alone does not prove compatibility.
Test a known-good compatible NVMe SSD in the original slot, if available. Use firmware inventory and non-destructive diagnostics as the comparison; do not install Windows over existing data merely to complete the test.
Replace the SSD when the disappearance follows it across compatible slots or systems. Service the slot or motherboard when multiple known-good SSDs fail in that slot while the suspect SSD remains stable elsewhere.

Branch D — Firmware always detects the drive, but Windows records resets or surprise removals

Preserve the evidence and backup first.
In Settings > Windows Update, install applicable Windows updates, then restart once and retest.
Obtain the model-specific chipset and storage-controller driver from the computer manufacturer. Record the existing provider, version, and date in Device Manager before installing the supported replacement.
If the failure began immediately after a storage-controller driver update and Roll Back Driver is available, use that rollback as a controlled test. Do not replace an OEM controller driver with an arbitrary driver from a different model.
Apply a supported drive-firmware update only under the stable conditions in Branch A.
Retest and compare new logs with the preserved baseline. Do not increase storage timeout registry values to conceal Events 129 or 153 unless the hardware vendor supplies model-specific guidance.
If the drive later becomes absent from firmware, return to Branch B or C. Windows driver repair cannot explain away a firmware-level absence.

Branch E — Comparative testing isolates a failed part

Save the before/after matrix, diagnostic result, serial numbers, and warranty information.
Replace or obtain service for only the isolated part. Preserve the original drive untouched until data recovery and post-repair verification are complete.
Restore from a verified backup or clone only after the replacement path remains stable through OEM diagnostics and repeated detection tests.
If replacing the drive resolves the disappearance but the old file system has damage, repair the restored copy or replacement volume rather than performing aggressive repair on the only failing original.

Check the result

The exact drive model and capacity appear in firmware on three cold starts and three normal restarts.
WinRE and Windows enumerate the same physical drive and expected volumes each time.
Sleep/wake and one ordinary workload cycle do not make the drive disappear.
OEM and vendor non-destructive diagnostics complete without a failure ID.
No new Event 157 occurs, and any Event 129 or 153 is evaluated against the same disk identity and workload.
A current backup has been restored or sampled successfully.
The changed component and the before/after result are documented; the improvement is not based on a single boot.
Drive follows the failure to another compatible host: replace the drive; preserve it for recovery if data remains.
Multiple known-good drives fail in one port or slot: service the cable, connector, power path, or motherboard.
A SATA cable alone changes the result: replace that cable and verify all power states.
Firmware always detects the drive but Windows logs timeouts: use the supported driver/firmware branch, then repeat evidence capture.
Drive returns only after all power is removed: treat it as an unresolved controller, power-state, firmware, or hardware-path defect until an update or component comparison proves otherwise.
SMART/reliability counters show normal: this does not clear an intermittent enumeration fault; many such failures leave no useful SMART attribute.
Only BCD codes remain after detection is stable: preserve the BCD store and route to the matching boot-file writeup.

To undo the change:

Restore each physical connection, cable, and slot to its photographed starting position if a controlled change worsens detection. Use Device Manager's Roll Back Driver only for the specific controller driver changed during this procedure. Restore recorded firmware settings if they were changed by an approved vendor update process, but do not attempt an unsupported firmware downgrade; many drive and system firmware updates are intentionally irreversible.

Keep the original drive, original cable, and evidence until the replacement has passed verification and all needed data is recovered. If no component has been isolated, return the system to its original physical configuration and escalate with the state table rather than continuing substitutions.

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.

chkdsk — documentation
Failed to recover ME Firmware and 2100 Storage detection error - ThinkPad L14 Gen4, L15 Gen4, L13 Gen4, and S2 Gen8 — documentation
AMD RAID Software Release Notes ver. 8.03.24.733 — documentation
Steps to Resolve WD_BLACK SN850 Not Detected On Cold Boot — documentation
[Troubleshooting] The Notebook Cannot Power On or Enter the Operating System — documentation
Windows 10 advanced start options command prompt failed storage recovery — reported case

Windows error codes and exact messages

Displayed identifier	Windows name or exact message	When it can apply
No Windows code	Search phrases: HDD not detected in BIOS/UEFI, SSD not detected in BIOS/UEFI, NVMe missing after restart, drive returns after full power cycle	Symptom descriptions, not error text generated by Windows. A firmware inventory or boot-menu absence is evidence, but any displayed wording is normally supplied by the computer manufacturer.
System event `129`	Reset to device, \Device\RaidPort1, was issued.	Storport timed out a request and reset the storage path. `RaidPort` is an internal Storport name and does not prove that the computer uses a user-configured RAID array. Record the provider and device name shown by the actual event.
System event `153`	The IO operation at logical block address `<address>` for Disk `<number>` was retried.	A storage request timed out and was retried. Correlate the disk number with the drive model and serial number; disk numbers can change between boots.
System event `157`	Disk `<number>` has been surprise removed.	Windows was told that a fixed disk disappeared. This is strong communication-loss evidence but does not by itself identify the drive, slot, cable, controller, power rail, or board as the failed part.
WHEA-Logger event `17`	A corrected hardware error has occurred.	Commonly accompanies a corrected PCI Express error. If the event's component and bus/device/function map to the NVMe path, it is supporting PCIe-link evidence; it is not proof that the SSD or motherboard is the failed side of the link.
NTFS events `55` and `98`	The file system structure on the disk is corrupt and unusable or Volume ... needs to be taken offline to perform a Full Chkdsk	Current Microsoft storage guidance publishes these characteristic templates. They describe a possible consequence of incomplete I/O; they do not prove that NTFS corruption made the physical drive disappear.
NTFS events `50` and `140`	File-system or write/corruption event whose exact text must be copied from this computer	Retain the event ID, provider, volume, status, and full local message. Do not assign the Event 55/98 wording to these different IDs.
Device Manager `Code 10`	This device cannot start. (Code 10) followed by Try upgrading the device drivers for this device.	The disk or its controller enumerates but cannot start. Hardware, firmware, and driver causes remain possible.
Device Manager `Code 24`	This device is not present, is not working properly, or does not have all its drivers installed. (Code 24)	Windows retains a device instance whose hardware is absent or not working.
Device Manager `Code 43`	Windows has stopped this device because it has reported problems. (Code 43)	The device or a controlling driver reported failure. It is not a component-level diagnosis.
Device Manager `Code 45`	Currently, this hardware device is not connected to the computer. To fix this problem, reconnect this hardware device to the computer. (Code 45)	A formerly enumerated device is no longer connected. For a fixed internal drive, investigate why communication was lost.
`0x0000007A`	`KERNEL_DATA_INPAGE_ERROR`	Windows could not read a requested kernel page from the paging file. Storage hardware and RAM are both possible; read parameter 2 and the events immediately before the stop.
`0xC000009D` within `0x7A`	`STATUS_DEVICE_NOT_CONNECTED`	The `KERNEL_DATA_INPAGE_ERROR` status says the controller did not see the disk or a connection was defective. Use only when it is actually parameter 2 in the dump.
`0xC000000E` within `0x7A`	`STATUS_NO_SUCH_DEVICE`	The `0x7A` status indicates hardware failure or an incorrect drive configuration. It does not identify the failed component.
`0xC000009C` within `0x7A`	`STATUS_DEVICE_DATA_ERROR`	Commonly associated with an unreadable block. It is a reason to preserve data and run vendor diagnostics, not proof of intermittent enumeration.
`0xC000016A` within `0x7A`	`STATUS_DISK_OPERATION_FAILED`	Commonly associated with a failed disk operation or unreadable block. Preserve the complete bug-check parameters.
`0xC0000185` within `0x7A`	`STATUS_IO_DEVICE_ERROR`	An I/O failure was reported. Preserve the complete dump and contemporaneous device/events; this status alone does not identify a modern SATA/NVMe cable, drive, controller, or host path.
`0x00000154`	`UNEXPECTED_STORE_EXCEPTION`	The kernel memory-store component caught an unexpected exception. It can accompany storage trouble, but Microsoft does not define it as proof of SSD failure. Corroborate it with the dump and storage events.
`0x0000007B`	`INACCESSIBLE_BOOT_DEVICE`	Windows lost access to the system partition during startup. It applies only if Windows reached this stop code; a drive absent from firmware requires hardware-path diagnosis first.
`0xc000000e`	A required device isn't connected or can't be accessed	Windows Boot Manager cannot open the referenced device. If firmware intermittently omits the drive, repair detection before changing BCD.
`0xc0000225`	A required device isn't connected or can't be accessed	A boot object, file, or device cannot be resolved. It is not proof that the drive itself failed.