Lesson 5: Diagnose the Missing or Failing Drive

A drive that does not appear in File Explorer is not automatically dead.

A drive that still appears is not automatically healthy.

Those two statements are the reason storage troubleshooting needs a layered model.

You are trying to find the first point where detection, health, performance, or data integrity stops behaving normally.

And while you do that, you protect the data.

Use the storage path

Start here:

physical device
      ↓
interface + power
      ↓
firmware/controller detection
      ↓
health or array state
      ↓
operating-system detection
      ↓
partition + filesystem + mount
      ↓
application access
      ↓
trusted data

Different symptoms point to different boundaries.

If firmware cannot see the device, disk-management settings are not your first problem.

If firmware sees the drive but the operating system shows it as unallocated, the hardware path is at least partly working.

If the filesystem mounts but reads are extremely slow, the problem may be performance or health rather than detection.

The failure stage changes the next question.

Status lights and controller indicators are clues

Storage devices, bays, enclosures, and RAID controllers may expose state through LEDs or status indicators.

Depending on the hardware, an indicator may represent activity, fault, rebuild, degraded state, or another vendor-defined condition.

Do not invent a meaning from the color alone.

Record the exact indicator pattern and verify it against the correct device or controller documentation.

A blinking light is evidence that something is happening.

It does not explain why.

Case 1: new drive missing from the operating system

User report:

"I installed the new drive, but Windows cannot see it."

That statement is too broad.

First ask whether firmware sees the device.

Firmware does not detect the drive

The investigation stays low in the stack:

• device seating;
• SATA data connection;
• SATA power;
• M.2 protocol compatibility;
• supported or active port;
• lane or port sharing;
• failed drive, cable, slot, or controller.

Do not initialize or format anything because the operating system is not even seeing a storage device yet.

Firmware detects the drive

Now move upward.

Check the operating-system storage view.

A new device may be uninitialized, unpartitioned, formatted with an unsupported filesystem, missing a drive letter or mount point, or offline by policy or configuration.

Those are logical or storage-management conditions, not proof of dead hardware.

Same user complaint. Different layer.

Case 2: bootable device or OS not found

A system reaches firmware and reports that no bootable device or operating system can be found.

That does not immediately mean the operating system needs reinstalling.

Check the chain:

drive detected in firmware?
        ↓
correct boot device selected?
        ↓
expected partition/boot structure present?
        ↓
filesystem and bootloader readable?

If the drive is completely missing from firmware, start with hardware and interface detection.

If the drive is present but the boot order changed, the problem is different.

If the device is present and selected but the boot structure is damaged, the investigation moves higher again.

"OS not found" is a symptom at the end of several possible paths.

Case 3: SMART warning

SMART is a drive-health monitoring system that exposes internal health indicators and thresholds supported by the device.

A SMART warning is not a crystal ball.

It is also not something to ignore until the drive stops completely.

If a device reports concerning health evidence, the priority becomes data protection.

A reasonable response is:

1. preserve important data;
2. verify backup and recovery state;
3. collect the health and status evidence;
4. avoid unnecessary stress on the device;
5. follow the approved replacement process;
6. verify the replacement and restored data.

The goal is not to prove the drive can fail harder.

You already have evidence that the risk increased.

Case 4: clicking or grinding HDD

A hard disk drive has moving mechanical parts.

Clicking, grinding, or other abnormal mechanical sounds can be serious failure evidence.

Do not repeatedly power-cycle or run heavy tests just to reproduce the sound.

Protect the data and follow recovery or escalation procedure.

And do not transfer this symptom model directly to SSDs.

An SSD has no spinning platters or moving heads, so "grinding SSD" is not a meaningful hardware diagnosis.

Technology changes the evidence you expect.

Case 5: storage is present but painfully slow

Slow I/O can come from many places:

• failing media;
• interface or controller limits;
• thermal throttling on some SSDs;
• RAID degradation or rebuild;
• workload saturation;
• background maintenance;
• filesystem problems;
• low free space;
• operating-system conditions.

Measure before replacing.

Useful evidence can include:

• extended read or write times;
• throughput;
• IOPS;
• latency;
• queue depth or saturation;
• health state;
• temperature;
• controller or array status;
• comparison to a known baseline.

"It feels slow" is a symptom.

It is not a drive diagnosis.

Case 6: RAID controller is alarming

Suppose the controller reports:

array: degraded
member 2: failed
other members: online
audible alarm: active

The files still open.

Do you replace random disks until the alarm stops?

Absolutely not.

The controller has already identified a specific degraded state and member.

Your next steps should preserve recovery state, verify the correct member, follow the approved replacement or rebuild process, and monitor the array until it returns to healthy status.

A degraded array and a missing array are not the same event.

If the entire array disappears, the failure boundary may involve controller configuration, multiple member failures, cabling, backplane, or other conditions.

Read the actual state.

Case 7: data corruption while the drive remains visible

A visible drive can still have serious problems.

Possible evidence includes:

• corrupted files;
• filesystem errors;
• application read failures;
• unexpected checksum mismatches;
• health warnings;
• controller errors.

Do not assume that "the drive mounts" proves the data is trustworthy.

Availability and integrity are different properties.

A file can be readable and wrong.

Known-good comparisons narrow the path

Suppose a SATA SSD is missing from firmware.

You test:

original SATA cable + drive: not detected
known-good cable + same drive: detected

What changed?

The cable path.

That strongly supports the original data cable as the failure boundary.

It does not prove every other part of the storage system is perfect.

The claim should stay bounded to the tested path.

Protect data before destructive operations

Storage tools often offer actions such as:

• initialize;
• format;
• delete partition;
• rebuild array;
• reset metadata;
• secure erase.

Those operations can destroy recoverable information.

Before using them, ask:

• Is important data present?
• Is there a verified backup?
• Is this the correct device?
• Does the procedure require a destructive step?
• Have I preserved the evidence needed to explain the original failure?

Clicking through a warning is not a troubleshooting method.

Worked case: drive appears in firmware but not File Explorer

Evidence:

UEFI: 1 TB SSD detected
Windows Disk Management: device present, unallocated
File Explorer: no volume shown
SMART: no warning in supplied evidence

Is the drive dead?

No.

The device is detected by firmware and the operating system. The missing boundary is a usable partition, filesystem, and volume configuration.

Would creating a new volume be appropriate?

Only after confirming the drive is actually intended to be blank and no recoverable data is expected.

That last sentence is why data context matters.

Worked case: boot drive disappears intermittently

Evidence:

sometimes detected in UEFI
sometimes missing
SATA power: secure
SATA data cable: damaged latch
known-good cable: device remains detected across repeated boots

A strong bounded claim is:

In the tested configuration, replacing the damaged SATA data cable with a known-good cable restored consistent firmware detection across the repeated boot tests.

That is better than:

The storage system is fixed forever.

Build two storage incident records

Choose two different symptom families and record:

• user-visible symptom;
• firmware or controller detection state;
• operating-system detection state;
• SMART, LED, noise, or alarm evidence;
• interface and power path;
• first failed or suspicious boundary;
• strongest theory;
• competing theory;
• controlled test;
• result;
• data-protection action;
• next step;
• verification;
• remaining limitation.

Do not invent health data, SMART results, or backup status that the scenario does not provide.

If recovery state is unknown, write unknown.

That uncertainty should affect what you are willing to change.

What Week 3 should change in your head

Storage is not one box labeled "drive."

It is a chain:

media
form factor
interface/protocol
power
controller
health
OS structure
filesystem
workload
data integrity
recovery

When something fails, find the earliest broken boundary.

And before you repair the storage, protect what the storage was supposed to preserve.