Hardware · Storage
Hard drives & SSDs: disk that won't show, slow drives and early signs of failure
Storage problems come in two families, and this page is organized around that split. The first family is the missing drive: the disk was there and now it isn't — not in File Explorer, not in Disk Management, not even in BIOS. The second family is the misbehaving drive: it's there, but it's slow, it's disconnecting, it's throwing errors, or it's making a sound it never made before. The families look different to the user but they share one structure, and that structure is the whole method.
A drive can stop being visible at any of five layers: BIOS/UEFI, Device Manager, Disk Management, File Explorer, or the application that was using it. The layer where visibility stops is where the problem begins — a disk that BIOS never sees has a power, cable, or controller problem; a disk that Disk Management sees but Explorer doesn't has a partition, letter, or filesystem problem. Finding the boundary takes minutes and rules out half the possible causes at once. Everything below is built on that boundary check, across 72 topics: twelve on detection, twelve on partitions, twelve on connections and installation, twelve on slow hard drives, twelve on slow SSDs, and twelve on the early signs of failure.
One thing before the method: storage is the one component where diagnosis can destroy the thing you're trying to save. A drive that's failing may still be holding the only copy of your data, and some "fixes" — formatting, initializing, creating partitions, repeated intensive scans — write to exactly that data. So this page puts the data-safety rules before the troubleshooting, and every topic below carries the same discipline: read first, write only when it's safe, and stop when continuing costs more than it saves.
The model
Where a drive can hide: the five layers
Every storage symptom on this page is a question about the same stack. At the bottom sits the physical drive — platters and heads, or NAND and controller — speaking through its interface (SATA, M.2, USB) to the platform. BIOS/UEFI is the first software layer that talks to it; the OS's device stack is next; then the disk/partition layer that turns a physical disk into volumes; then the filesystem that turns volumes into files; and finally the applications reading the files. When any layer stops seeing the drive, everything above it goes dark — which is why "the drive is gone" from Explorer is true but useless as a diagnosis. You have to find the lowest layer that still works.
That's also why the drive's own reporting matters. A drive is not passive: its firmware maintains SMART counters (reallocated sectors, media errors, wear), it negotiates a link speed with the port, and it raises events in the OS log when reads fail. The diagram below shows the path data takes and where the evidence lives when something goes wrong.
Read this before anything else
Data safety first: the three rules
If the drive holds data you need and it shows any sign of failure, the job changes from "fix the drive" to "save the data."
Formatting, initializing, creating partitions, and repair-mode scans all write to the disk. On a healthy drive that's routine; on a failing drive with unsaved data, it's how recoverable data becomes unrecoverable. When in doubt, the safe default is to make an image or copy first and work from that.
The three rules, in the order they matter:
- Rule one — know before you touch. Before any operation, answer: does this disk hold data I need? "I think so" counts as yes. Everything about which actions are safe depends on this answer, and it's the only question that takes zero tools.
- Rule two — reads are safe, writes are decisions. Checking cables, ports, BIOS, Device Manager, Disk Management, SMART, and running read-only scans change nothing on the disk. Formatting, initializing, partitioning, and repair-mode scans all change something. The first class you can do freely; the second only on a drive you've confirmed is empty, or after an image exists.
- Rule three — mechanical sounds mean stop. A drive that clicks, grinds, or scrapes is failing physically, and every power-on cycle is a mechanical event that can make it worse. The response is preservation (imaging while it still cooperates, or professional recovery), not persistence. No amount of software patience fixes a head assembly.
Quick split: low-risk — checking cables/ports/power, BIOS detection, Device Manager, Disk Management (viewing), reading SMART, read-only scans. Potentially destructive — formatting, initializing, deleting or creating partitions, repair-mode filesystem operations, writing data to a failing disk, repeated intensive scans on a physically failing drive.
Start here
What problem are you seeing?
Pick the closest match and you'll get a short pointer to the topics that apply to that situation. The selector is a router, not a diagnosis — it sends you to the right sections; the sections do the work.
Quick reference
Symptom → cause → first check
The compact version of the whole page. "Risk to data" means the risk that the diagnosis or fix endangers the data — not the risk the drive itself is in, which is usually higher than the table suggests.
| Symptom | Common causes | What to check first | Risk to data |
|---|---|---|---|
| Drive gone from everywhere | No power, bad cable/port, failed drive | Cable, port, power, then BIOS | Low |
| In BIOS, not in Windows | Controller mode, driver, no partition table | Disk Management + recent BIOS changes | Low–Med |
| Unallocated space on an old disk | Lost partition table | Stop, image, recover from copy | High if you write |
| RAW volume / format prompt | Filesystem damage or media failure | Read-only scan, never Format | High if formatted |
| No drive letter | Letter lost or taken by a conflict | Assign a letter in Disk Management | Low |
| Intermittent disconnects | Cable, port, power, failing controller | Swap cable/port, read event log | Medium |
| Clicking / grinding noise | Head or bearing failure | Stop; preserve the data | High |
| SMART reallocations rising | Media degradation | SMART trend, then back up | High |
| HDD slowly stuttering | Bad-sector retries, heat | SMART + read-only scan | Med–High |
| SSD write speed collapsed | Fill level, TRIM, firmware, wear | Free space, TRIM, wear counter | Low→High |
| Files corrupting without cause | Media or filesystem damage | Pattern + SMART; image if growing | High |
| System freezes on drive access | I/O stalls, marginal connection | Event log + SMART | Medium |
The full index
All 72 topics, filterable
Every topic on this page, in order. Filter by category or jump straight to a title — each card links to its section below. A = detection, B = partitions, C = connections, D = slow HDD, E = slow SSD, F = failure signs.
72 topics
Category A · Topics 1–12
Drive detection & basic diagnosis
The "I can't find my drive" family. The thread through all twelve is the layer model: find the lowest layer that still sees the drive, and the problem lives just below it.
Hard drive not showing up in Windows
"Not in Explorer" is the top of the stack and the least specific statement a missing drive can make — the disk could be dead, unpowered, letterless, offline, or healthy-but-uninitialized. The first job is to find which layer it actually disappears at, and the tool is Disk Management (Win+X → Disk Management). If the disk appears there, it is alive and the problem is in the partition layer: no letter, offline, unallocated, or RAW, all covered below. If it isn't there at all, the problem sits under the operating system entirely.
Next, check BIOS/UEFI. A disk BIOS sees but Windows doesn't usually means a controller gap (AHCI vs RAID after a motherboard change, a missing storage driver) or a disk that simply has no partition table yet. A disk BIOS doesn't see puts you in the power, cable, and drive-failure territory — work through Category C before suspecting the drive itself. One physical note: a dead SATA drive gives zero feedback. No click, no hum, no light — the absence of sound is itself data.
SSD not showing up in Windows
An SSD removes the one clue an HDD gives you — sound — so a dead SSD and a healthy SSD look identical from the case: nothing. That makes the layer check matter more, not less. Run the same sequence as above: Disk Management first, then BIOS. An SSD that appears in BIOS but not in Disk Management points at the controller/driver gap or, for M.2 drives, at the slot itself (disabled, wired for a different interface, or not fully seated).
M.2 adds a hardware wrinkle that SATA never has: not every M.2 slot takes every M.2 drive. A Wi-Fi M.2 slot won't accept a storage drive at all, and some M.2 slots are SATA-only while your drive is NVMe (or vice versa). Verify the slot type and the connector key match the drive before concluding anything, and check the M.2 settings in BIOS. If the SSD is silent in every slot of every system you can test it in, the drive's controller is a realistic suspect — SSDs do fail at that layer, and they fail quietly.
External hard drive not showing up
External drives fail at three layers in rough order of likelihood: cable, port/power, then the drive. The enclosure presents two independent connections to test — the USB cable (which carries both data and power) and the USB port — so the correct first move is to swap the cable and move the port before any diagnosis. Listen while you do it: a 2.5-inch drive should spin up within a second of connecting, and a 3.5-inch one should be obviously alive. "Connected but silent" narrows the problem faster than any software check.
If it spins but doesn't appear, check Disk Management: an external drive that lost its letter or shows RAW is a data situation, not a hardware one, and the correct response is the opposite of the hardware response (stop and protect, rather than reseat and retest). If it doesn't spin at all, the power story decides: 3.5-inch drives need their AC adapter, and a 2.5-inch drive on a marginal port or hub may simply not be getting enough current. A drive that was fine and died around a power event (surge, yank-while-powered, a dead brick) should be treated as suspect from that moment, SMART check included.
External SSD not showing up
External SSDs have no motor, so there is no spin-up to listen for — the only sign of life is the enclosure LED, and a failed LED can mislead you in both directions. Start with the same two-swap test (cable, port), but weight the cable more heavily than with HDDs: USB-C cables are a bigger variable here, because a cable that carries power but not the correct data lines will connect, light up, and show nothing. "It's getting power" is not proof the cable is doing its job.
If swaps don't help, Device Manager is the next stop: an unknown USB device, or a storage controller with a warning icon appearing the moment you plug the drive in, localizes the problem to the bus or the drive's controller. Also note where it fails. A drive that works on one PC and not another is usually port power or USB negotiation; a drive that works nowhere, after a specific event (a drop, a surge, being yanked mid-session), points at the enclosure's controller or the SSD inside it. In that second case, the enclosure is the suspect as much as the drive, and a different enclosure is a cheap test worth doing before writing the drive off.
Second internal hard drive not detected
A second drive that BIOS never lists is almost always a connection or configuration problem rather than a dead disk, but the test order matters. Check the two cables (data and power) at both ends, move the drive to a different SATA port, and — if you can spare the time — boot with only the second drive connected. Isolating it removes the primary disk from the equation and makes the result unambiguous: detected alone means the pair was the problem (port, mapping, or power budget); still undetected means the drive, its cables, or both.
If it's detected alone but not with both drives installed, the usual culprits are a dead port, a SATA port disabled in BIOS, or — on systems configured for RAID — a port claimed by the RAID controller rather than the standard SATA stack. One caution before you move a drive between machines repeatedly: a drive that's already marginal gets stressed by every connect cycle, so if the second drive is old or has ever shown errors, do a quick SMART read before the next round of testing. The goal is a small number of decisive tests, not a long series of hopeful ones.
SSD not detected after installation
"Just installed it and it's not there" has a short, ordered list of common causes for fresh hardware work: the drive isn't fully seated, the M.2 screw is missing or the wrong length, the slot is disabled in BIOS, or the slot is wired for a different interface than the drive. Work the list in order of effort: reseat, check the screw, verify the slot's BIOS setting, try another slot. Each step takes under a minute, and together they account for most "installed but invisible" reports.
Two installation details cause silent failures worth knowing by name. First, a thermal pad applied before the drive is seated can wedge it a millimeter off the connector — enough to kill the electrical connection with no visible gap. The correct order is: seat fully, then pad, then screw. Second, on some motherboards populating the M.2 slot disables one or two SATA ports; if your boot drive vanishes the moment you install the M.2, that's the port mapping, not a dead disk. If the SSD survives all of this and is still silent in multiple slots across multiple systems, the failure is the drive's controller, and the conversation becomes warranty or replacement.
Hard drive not detected in BIOS or UEFI
BIOS is the lowest layer that can see a drive, so "not in BIOS" rules out Windows, drivers, and partitions in one move — the problem is physical: power, data connection, port, or the drive's own controller. This is where software diagnosis ends and part-swapping begins, and the method is to make each test mean something: a known-good SATA cable, a different power header, a different port, and if available a different system. A drive that spins but is never detected by any BIOS on any system has failed at the controller level.
Keep the sequence honest so you can interpret the results: power first (does it spin or show any sign of life?), then data (different cable, different port), then platform (another machine). The order matters because a cable test on a drive with no power tells you nothing, and a platform test before a cable test wastes a system. When the swaps are exhausted and the drive is still invisible, stop — further reseating is unlikely to help a failed controller, and if there's data on the drive the correct next move is preservation (imaging through whatever window remains, or professional recovery), not another round of the same tests.
Drive appears in BIOS but not in Windows
This gap — firmware sees the disk, the OS doesn't — means the Windows storage stack can't claim it, and there are three classic reasons. The first is a controller-mode change: the SATA mode flipped (AHCI to RAID, or a new motherboard with a different controller) and the OS driver no longer matches. The second is a missing or broken storage driver after an update. The third is structural: the disk has no valid partition table, so Windows has nothing to mount even though the disk is perfectly healthy. Each has a different fix, which is why identifying which one you're in matters more than acting quickly.
Apply the decision logic: if you recently changed the motherboard or the BIOS storage mode, restore the previous mode — that's the fix, and it's not a reason to reinstall Windows. If the disk is brand new, it may simply need a partition and filesystem (see "unallocated" below, and read the data warning before creating anything). If a disk that previously held data now appears in BIOS but has vanished from Windows, stop: that pattern is consistent with a lost or damaged partition table, and writing to the disk — initializing, partitioning, formatting — before imaging it can convert a recoverable situation into a permanent one.
Drive appears in Device Manager but not in File Explorer
Device Manager only tells you the OS detected hardware on the storage bus — it says nothing about whether the disk is usable. Every "present but unusable" state lives one level up, in Disk Management: no partition, no drive letter, offline, or a filesystem Windows can't read. So this symptom is a redirect: the interesting information is in Disk Management's view of the disk, because that's where the actual status lives and the actual fix begins.
While you're in Device Manager, spend thirty seconds on the warning icons, because two of them change the diagnosis. A disk controller or SCSI controller with a yellow triangle usually means a driver or port problem — the hardware is on the bus but the OS can't properly talk to it. A USB root hub or mass-storage device warning that appears when you plug in an external drive points at the bus rather than the drive's contents. Those icons move the problem from "partition issue" to "controller/port issue," which is a different category of this page entirely (Category C) with different fixes.
Drive appears in Disk Management but not in File Explorer
This is the most common "missing drive" of all, and usually the fastest to fix: the disk is healthy and present at the block level, but it has no path into Explorer. There are exactly four states to look for in Disk Management: unallocated (no partition at all), no drive letter (a partition exists but has no letter), offline (the disk is disabled), and RAW (a partition exists but its filesystem is unreadable). Each has a distinct fix — and three of the four are safe one-click operations, while the RAW one is where data-safety takes over.
Apply the data question before touching anything. If the disk was new or you know it held nothing important, the state tells you the fix directly: assign a letter, bring it online, or partition and format. If the disk previously held data and now shows unallocated or RAW, the contents may be perfectly intact — the damage may be only to the map — and the "obvious" fix (create a partition, click format) writes over exactly the space where recovery would have worked. In that case the first action is a backup or a full disk image, and the second is fixing the map on the copy.
Hard drive suddenly disappeared
"Sudden" is the useful word, because it means something changed in a narrow window, and that narrows the causes to things that happen: a Windows or driver update, a power event, a physical jolt, a cable working loose, or a drive crossing from failing to failed. The check order should match that list, cheapest test first: software changes (what updated or changed in the last few days), then connections (reseat both cables, change port), then the drive's health (SMART). Each step is faster and cheaper than the next, and skipping ahead is how people replace a $40 cable's problem with a $100 drive.
Two tools make the "sudden" question answerable. Disk Management plus the event log: if the disk is present but changed state (offline, missing partition), the log usually records what did it and when, with a timestamp you can match against updates and reboots. And honest timing: a drive that "suddenly" disappears the same week it started making new noises, developing new stutters, or throwing new read errors was not sudden — it was a failure that had been announcing itself for days. That distinction decides everything downstream: an event-driven disappearance is usually fixable; a failure-driven one is a data-preservation problem wearing a surprise costume.
Drive keeps appearing and disappearing
Intermittent detection is its own failure class, and it has a bad reputation for good reason: it usually means a physical instability — a marginal SATA or USB connection, a failing power header, a worn cable, or a drive whose controller is dropping off the bus — and it's one of the most data-dangerous states a drive can be in. Every dropout is a chance to corrupt whatever was being written at that instant, and the drive will usually keep working "fine" for days or weeks while quietly doing it. A flaky drive is a ticking clock, not a nuisance.
The triage splits by connection type. Internal: swap the data cable, try another port, try another power header, and read the event log for bus-reset or disk-error entries that timestamp the dropouts — the pattern in those entries (always at load, always after idle, always at the same moment) is diagnostic. External: cable, then port, then hub, then a different PC. If the drive survives all of that and still drops, treat it as failing: copy the data now, verify the copies actually open, and replace the drive. Don't wait for the dropout to become a permanent absence — intermittent is the phase where the data is still fully saveable.
Category B · Topics 13–24
Disk management & partition problems
This category is about the map rather than the territory: partition tables, drive letters, offline states, and the situations where Windows sees a disk but can't hand you a path to it. Most of these are quick and safe. Two of them — unallocated and RAW — are where data lives or dies, so they carry the page's heaviest warnings.
Drive has no drive letter
A partition with no letter has no path into File Explorer, and that's usually the entire problem. Windows fails to assign letters in a few predictable situations: a brand-new partition that was never assigned one, a letter that got consumed by a mapped network drive or a piece of software, or a disk that moved between machines and arrived without its old letter. The fix is a minute long: in Disk Management, right-click the partition, choose "Change Drive Letter and Paths," and assign a free letter.
What makes this topic worth isolating is that it's the safest operation on this page — changing a letter alters a label, not data — which is exactly why it's the first thing to try whenever a healthy-looking partition is invisible in Explorer. The follow-through matters: if assigning a letter fails with a conflict, that's the next topic (letter conflict), and if the partition refuses to open even with a letter, you're in the filesystem layer (RAW / can't open), which is a different problem with a different risk profile. Knowing which of the three you're in takes one attempt and one error message.
Fixing a drive letter conflict
Letter conflicts happen when two claimants want the same letter: a new partition and a mapped network drive, two USB drives that both default to E:, or backup and imaging software that reserves letters for itself. The symptoms are a partition that won't accept a particular letter, or a drive that "opens" the wrong volume. The fix is to move one of the claimants — unmap or reassign the network drive, or give the disk a letter from the far end of the alphabet that nothing else touches. Once the conflict is resolved, the assignment sticks, and no data is involved at any point.
There's a related trap that keeps recurring: software that hard-codes a letter. A backup tool that always writes to D: will misbehave the day your disk becomes E:, and a virtual-disk utility that creates a drive at startup will eat a letter you were counting on. If a letter keeps getting "taken" after reboots, the investigation is mapped drives (the Network section of This PC) and startup software that creates virtual disks. It's an unglamorous problem, but it's the one that makes a drive vanish from Explorer while remaining perfectly healthy in every other layer.
Drive shows as offline
"Offline" means Windows has deliberately taken the disk out of service — the disk is detected, but the OS has disabled it. The legitimate reasons cluster: a disk with a duplicate signature (two identical disks in the same system will collide), a BitLocker-protected disk after a controller or motherboard change, a group policy in effect, or a disk that keeps getting disabled because of repeated errors. The state is visible in Disk Management, and for a single healthy disk the fix is usually right-click → Bring Online.
Bringing a disk online is safe for its data — it's a policy change, not a format — which makes it a safe second action after the letter fix. But treat recurring offline states differently: a disk that flips back to offline by itself, repeatedly, is reporting something. Unstable connections and failing drives both do exactly this, because the OS disables disks that keep erroring. If your disk offlines on its own — especially under load — the offline state is a symptom to investigate (cable, power, SMART), not a setting to keep re-applying, and the "fix" that lasts is the underlying cause, not the click.
Drive shows as unallocated
"Unallocated" means the disk has no partition table entry the OS recognizes — either it's a brand-new disk that never had one, or a disk that used to have partitions and lost (or had overwritten) the table. The two cases need opposite responses, which is why identifying which one you have matters more than fixing it quickly. A new disk you just connected: partition, format, use — a minute of work, zero risk. A disk that previously held data: stop, and read the next paragraph before touching anything.
On a disk that had data, unallocated space usually means the partition map is damaged while the files themselves are still sitting on the platters or NAND intact. The danger is the obvious fix: creating a new partition writes a new table and a new filesystem over exactly the space where the old data lives, and at that moment the "easy" recovery is gone — the data is now under a fresh filesystem that will actively overwrite it with new writes. The safe order is the reverse: make a full image of the disk (or use a recovery tool that works read-only), then rebuild the partition structure on the copy and copy the files back. Slower, and worth every minute of it.
Drive shows as RAW
RAW is Windows' way of saying "there's a partition here, but I can't read its filesystem." The causes span a spectrum from benign to serious: a volume that was yanked or crashed with its metadata mid-write, a corrupted master file table on NTFS, a partition table that's out of sync with the actual data, or — the serious end — an underlying drive with failing sectors that happen to sit under the filesystem's metadata. RAW is a state, not a verdict: the data may be fully recoverable, or the disk may be dying, and finding out which is the entire job.
The rule for a RAW drive with data on it: never click "Format," and treat repair tools with the same care as the drive. The format prompt is Windows' lazy answer to an unreadable volume, and it destroys exactly what you're trying to save. The diagnostic that's safe is a read-only scan — chkdsk in scan-only mode reads the volume's structures without changing them, and its report tells you whether the damage is a few fixable structures or something widespread:
chkdsk D: /scanReplace D: with the RAW volume's letter. Scan-only mode reads the volume; it does not modify it.
Windows says "you need to format the disk"
This dialog is one of the most dangerous buttons in Windows, and it appears in more situations than most people realize: a brand-new disk, a partition with a damaged filesystem, a RAW volume, a disk formatted for another operating system, even a partition-table mismatch. In every one of those cases the dialog looks identical, which is precisely why the safe habit is to close it and go look at Disk Management first. The dialog tells you what Windows would do; it does not tell you what the disk needs.
Then the decision is the standard one from the safety rules. If the disk is new or you've confirmed it holds nothing you need, formatting is the correct, fast fix — do it. If the disk held data, formatting is the wrong fix by definition, because it is the deletion of that data. The alternatives, in rough order of preference: recover or re-assign the partition (if the table was the problem), run a read-only filesystem scan (if the filesystem is damaged but the disk is healthy), or image the disk and work from the image (if the disk itself is suspect). None of those paths require touching the original data, and that's the whole point: the format dialog is a suggestion, not a requirement.
Windows says "you need to initialize the disk"
Initializing writes a partition table structure — MBR or GPT — to a disk that currently has no valid one. On a brand-new disk it's a normal, harmless first step and nothing to worry about. On a disk that previously held data, which is when this prompt usually shows up, it's a warning shot: the partition table is gone or unreadable, and initializing overwrites whatever remains of it. The prompt is identical in both cases; the stakes are not.
So the decision mirrors the unallocated topic: is this a new disk or a lost one? New → initialize (GPT for anything over 2TB or any UEFI-booted disk, MBR only for legacy under-2TB cases), then partition, format, done. Data on it → don't initialize; image the disk first and recover the partition structure from the copy, exactly as in the unallocated case, because the two symptoms usually share the same cause (a damaged table). One more signal worth noting: if the initialize prompt keeps appearing on the same disk even after a successful initialize and partition, that's the drive itself misbehaving at the firmware level, and the conversation moves from "settings" to "health."
Partition exists but Windows can't open it
"Can't open" has four very different causes, and they produce different error messages, which is why reading the exact error matters more than reaching for a fix. Access denied is a permissions or ownership problem — common after a Windows reinstall on the same disk. Encryption prompts mean BitLocker or EFS is doing its job and the answer is a recovery key, not a repair. Corruption errors ("the file or directory is corrupted and unreadable," I/O errors) point at the filesystem layer. And errors that grow over time — one file today, five tomorrow — point at the disk itself. The wrong fix for the wrong cause (a "repair" for a permissions problem, or worse, a format) is how people lose data they could have kept in a minute.
Match the fix to the cause, in order of safety. Permissions: take ownership or restore permissions — no data risk, usually a few clicks. Encryption: find the recovery key; everything else is a detour. Corruption: a read-only scan first (the topic above) to gauge the damage before anything that writes, and on a healthy disk with minor damage, the standard repair is appropriate. Growing errors: stop — a mounted volume whose error count climbs is a failing disk wearing a "still works" disguise, and the response is backup-verify-replace, not another repair pass. The pattern of the errors is the diagnosis; the error message is just the doorway to it.
Partition table problems, explained
The partition table is the disk's map: a small structure (the MBR sector, or the GPT header and its backup copies) that records where each partition starts and ends and what it's for. Everything Disk Management shows you is read from that map. When the map is damaged — by a crash mid-write, bad sectors sitting under the table, a virus, or a botched repartition — the data on the disk is often still there, but Windows has lost the map and shows you unallocated space, a missing partition, a partition with the wrong size, or two partitions claiming the same space instead.
That produces the practical consequences people actually report: "my 1TB drive now shows 200GB," "a partition I never deleted is gone," "the disk shows unallocated but I know it had data." The rule for all of them is the same and it's non-negotiable: never write to the disk before you've preserved the current state, because a new map written over the old one is usually unrecoverable — the map is small and gets overwritten first, by anything. Recovery of a lost table is done from an image (or with tools that scan the original strictly read-only), and it's the image that makes every subsequent step safe. The map is cheap to lose once and expensive to lose twice.
GPT vs MBR for modern storage
MBR is the legacy partition format: it handles disks up to about 2TB, keeps a single copy of the partition table, and is what older BIOS systems boot from. GPT is the modern format: it handles arbitrarily large disks, keeps backup copies of the table (which is exactly why GPT disks survive table damage better), and is what UEFI firmware expects for a boot disk. The practical decision tree is short: over 2TB, GPT isn't optional; a boot disk on a UEFI machine, GPT is what the firmware wants; a legacy BIOS system under 2TB, either works.
The caution belongs to the conversion, not the choice. Converting between GPT and MBR on a disk with data is a write operation with real risk — it rewrites the table structures, and "convert" is not a free toggle you can reverse if something goes wrong mid-way. If a disk has data on it and you genuinely need the other format, the safe route is the page's standard: image, convert, restore. And if you're choosing for a new disk, default to GPT in nearly every modern case — there's no scenario where MBR is the better default for storage bought in the last several years, and GPT's backup tables are a small built-in insurance policy against the exact problem this category is about.
When a partition suddenly disappears
A partition that was there and isn't — the disk itself still present in Disk Management — is almost always one of four things, in order of likelihood: the letter was lost (fast, safe, one click), the partition went offline (safe policy fix), the partition table was damaged (the data-safety situation), or the underlying disk started failing and the volume got dropped (data-safety plus hardware). The Disk Management view separates the first two from the last two immediately: if the partition is still listed but unreachable, it's a letter or offline problem; if its space now reads unallocated or RAW, you're in table or media territory.
Work it in that order, because it's cheapest-first: check for the missing letter, then the offline state, then look at what occupies the space the partition used to hold. If that space is unallocated or RAW and the partition held data, you're in partition-table territory — stop writing, image the disk, recover from the copy. If the disk also shows SMART errors, was making noises, or the disappearance followed the same week as new read errors, you've found the deeper cause, and the priority flips from "restore the partition" to "get the data off a failing disk." The event log is the tie-breaker for the sudden part: it will often show the exact moment the volume was dropped and what was logged around it.
How to recognize a filesystem problem
Filesystem problems announce themselves in patterns rather than single events: files that won't open and report "corrupted and unreadable," Explorer taking seconds to read a folder that used to be instant, chkdsk reporting errors, Event Viewer entries from NTFS or the filesystem driver, or a volume that used to mount immediately now taking a while. A one-off error on one specific file is usually that file — an app wrote it badly, a transfer got interrupted. The same error spreading across files, or reappearing after you've fixed it, is the filesystem layer degrading, and that's a different animal with a different response.
The read-only scan is the diagnostic of record: it checks the volume's integrity without changing anything, and its report separates the two outcomes that matter. Small, fixable damage on a healthy disk — a few inconsistent structures after a crash — is a routine repair, and the standard repair mode is appropriate there. Widespread errors, or errors that correlate with SMART warnings and disk noises, mean the filesystem is being damaged from below, by the media, and no amount of repair at the filesystem layer fixes that — the response is backup, verify, and replace the disk. The scan tells you which of those two worlds you're in; acting as if it's the first when it's the second is the classic expensive mistake in this category.
Category C · Topics 25–36
Connection, power & installation
Detection problems that start below the operating system: cables, power, ports, slots, and the BIOS settings that sit between the hardware and everything above it. This is the category where the cheapest parts — a cable, a port swap, a BIOS toggle — clear the most "mysteries," which is why it comes before any conclusion about the drive itself.
Bad SATA cable symptoms
A bad SATA data cable has a characteristic signature: the drive is detected sometimes and not others, or it's detected but slow, or the link negotiates at a lower speed than both ends support — 3 Gbps instead of 6, which caps transfer rates near 280 MB/s regardless of how good the drive is. SATA cables are cheap, fail silently, and degrade without warning, which is why the cable is the first thing to swap. A known-good cable and a different port can clear a "mystery drive" in thirty seconds, and it's the single best cost-to-information test in storage troubleshooting.
The speed check is the subtle part of the diagnosis. In Device Manager, under the SATA controller, the reported link speed tells you what the cable and port actually negotiated: a SATA III drive reporting 3 Gbps on a 6 Gbps port points at the cable (or that port) rather than the drive. The swap logic makes the result unambiguous — if the problem follows the cable to a different drive, the cable is dead; if it follows the drive to a different cable and port, the suspect list moves down to the drive's ports or controller. Two cables, two ports, one comparison: that's the whole test.
Bad SATA power connection symptoms
Power problems disguise themselves as detection problems, and the symptom set is recognizable: a drive that doesn't spin at all, a drive that spins down at random, a drive that's detected at boot but drops under load, or a drive that's fine in one system and dead in another. The SATA power connector has to deliver everything the drive needs, and a worn header, a bent pin, a loose connection, or a failing PSU rail will all degrade it. If a drive behaves "almost fine," suspect the power before the disk — marginal power produces exactly that quality of unreliability.
The test is simple and safe: a different power header from the same PSU, then — if available — a different PSU. One nuance that trips people up: a 3.5-inch desktop drive is the most power-hungry consumer of this connection, so it's the most likely to expose a marginal header; a 2.5-inch drive or SSD working fine on the same header does not clear the header, because it's drawing less current. If the drive is dead on a known-good PSU with good cables, the suspicion moves to the drive's own controller — and at that point, with data on it, the conversation is preservation, not more socket-testing.
Faulty USB cable and external drive problems
The USB cable is the single most common cause of external drive problems, and it fails in two different ways that produce different symptoms: the power lines degrade (the drive won't spin up, or drops under load) and the data lines degrade or were never full-capability to begin with (the drive is detected but slow, or not detected at all). A cable that's fine for a mouse or a phone is not automatically fine for a spinning disk, and "it's a USB cable" is not a dismissal — for external storage, the cable is a first-class component. When an external drive misbehaves, the cable swap is the statistically correct first test, not a superstition.
There's also a specification trap worth naming: a cable that physically fits may be USB 2.0 internally, capping a USB 3 drive at roughly 35 MB/s — a number people then diagnose as "my drive is dying" when the drive is perfectly healthy through a narrow pipe. If transfer speed is the complaint, confirm the cable and the port both support the speed you expect, then retest. And for USB-C specifically: a cable that charges but doesn't carry data is a real and common defect class, so an LED lighting up is not proof the cable is doing its job. The cable gets swapped first because it's the cheapest thing in the chain and the most likely to be the whole problem.
USB port problems that make drives disappear
Ports fail and degrade in ways that are indistinguishable from drive failure by symptom alone: a dying port drops devices under load, a front-panel port with a loose internal ribbon cable is intermittently dead, and a port with marginal power delivery will spin a drive up and then let it brown out seconds later. The test is movement: the same drive on a different port, preferably a rear motherboard port (direct, well-powered, no intermediate wiring) rather than a front panel or a hub. If the drive is solid on the rear port and flaky on the front, the port is the diagnosis and the drive is exonerated.
Two software-layer port issues are worth ruling out because they're free to fix and commonly overlooked. The first is USB selective suspend, a power-saving feature that can put an external disk to sleep at the worst moment; disabling it for the port (or the system) is a one-setting test. The second is the event log: a USB root hub reporting resets or errors gives you a timestamped record of bus instability that you can correlate with the dropouts you experienced. And note the reversal case: a drive that drops on every port of every machine you try is telling you the drive or its enclosure is failing, not the ports — the direction of the evidence flips when the swaps stop helping.
External drive not getting enough power
Power budget is the least visible requirement of external storage, and it produces the most confusing symptoms. A 3.5-inch drive needs its AC adapter, full stop — there's no bus-power mode for it. A 2.5-inch drive runs from the USB bus, but its spin-up current draw is a peak that a marginal port, a long cable, or an unpowered hub may not sustain; the classic signature is a drive that clicks, spins down, and reconnects, or works on a desktop but not on a console or a laptop's busy port. If a drive is unreliable in exactly the ways power starvation produces — flaky at spin-up, fine at idle — the fix is power: a powered hub, a Y-cable with a second power input, or a direct rear port.
The diagnostic shortcut is comparison: a drive that's flaky on one machine but solid on another is a power or port difference between those machines, not a dying disk, and the fix is the better-powered connection. A drive that was solid everywhere and went flaky after a firmware or OS update is a different animal — a controller or driver issue, not a power one — and the two shouldn't be confused, because the first is fixed with a $15 powered hub and the second with software. One last note: a drive that experienced a power surge, or was yanked while powered, deserves a full SMART check before you trust it with new data, because power events are exactly the kind of event that starts a quiet failure.
USB hub problems with external storage
Hubs are where external storage problems go to hide, because a hub adds a layer of negotiation and a point of failure between the drive and the machine it's trying to talk to. An unpowered hub splits a single power budget across every downstream port, and a spinning hard drive is a large share of that budget; a powered hub fixes most of it, but hubs also fail on their own — a hub's controller degrading will drop everything hanging off it, which looks, from the drive's perspective, exactly like the drive is failing. If a drive is flaky and the chain between it and the PC includes a hub, the hub belongs on the suspect list ahead of the drive.
The rule that resolves most hub issues is a sentence long: for anything with a spinning motor, use a powered hub or a direct rear port, and stop debating. The other tells that the hub — not the drive — is the problem: multiple devices dropping at the same time (that's the hub's controller, not several coincidental drive failures), a drive that's solid when plugged directly but flaky through the hub, or a hub port that runs noticeably hot. Hubs don't fail often, but when they do, they fail in a way that's easy to misattribute to the drives hanging off them — which is how healthy drives get "diagnosed" as dying by their own hub.
NVMe SSD not detected after installation
NVMe detection problems are almost always slot problems rather than drive problems, because NVMe has no cable to get wrong — the slot is the interface. The short list of what goes wrong: the M.2 slot is disabled in BIOS, the slot is wired for SATA (and therefore can't see an NVMe drive), the slot is the Wi-Fi slot, or the drive isn't fully seated — the NVMe connector is fiddly, and a millimeter short reads as "no device present" with zero other symptoms. Every one of those is checkable in minutes, and together they explain most "installed NVMe, sees nothing" reports.
The verification path runs BIOS-first, because an NVMe drive should appear in the BIOS storage list before any operating system is involved — "not in BIOS" localizes the problem to the physical layer or the slot configuration, and rules out Windows in one move. Then: check the motherboard manual for which M.2 slots support NVMe and whether any enablement setting exists, reseat the drive with the correct screw, and try a different slot. If the drive is silent in every NVMe slot of every system available for testing, the drive's controller has failed — and that's a warranty or replacement conversation, not a troubleshooting one. The swaps have done their job by telling you the drive is the constant in every failure.
M.2 SSD installation mistakes
M.2 sounds simple — a stick, a slot, a screw — but it has four failure modes that all produce the identical symptom, "not detected." Wrong notch: the connector key on the drive must match the slot's key; a B-key drive in an M-key slot won't seat, and near-matches seat partially, which is worse than not at all because it looks installed. Insufficient seating: the drive goes in at a slight angle and the screw is tightened before the connector is fully engaged. Wrong screw: too long and it crushes the board or the drive edge; missing and the drive lifts off the connector under thermal expansion. Thermal pad installed first: the pad wedges the connector a millimeter off, killing the connection with no visible gap.
The correct order, every time, is: remove the thermal pad if one is present, seat the drive flat until the connector is fully engaged, apply the pad, then install the screw. And before you start, check the slot's identity — the motherboard manual states which M.2 slots take NVMe (M key), which take SATA (B or B+M key), and which are for Wi-Fi, and on many boards populating the M.2 slot disables one or two SATA ports. That last fact is the reason a "dead SATA drive" sometimes appears to die the exact moment you install an M.2: the port was mapped away, not broken. Getting the slot, the seat, the pad, and the screw right in that order makes most M.2 installation problems simply not happen.
SATA SSD installation mistakes
SATA SSDs use the same two-connector interface as hard drives, so the installation mistake list is the cable-and-connector family: the data connector oriented wrong (it's keyed, but people force it), a connector that's only half-engaged, the power connector loose, or a cable bent at the connector where the pins sit. None of these makes a sound — an SSD has nothing to spin, so there's no click to confirm the connection — which means the only symptom is "not detected," the exact symptom that gets blamed on the drive. The silence that should reassure you ("SSDs don't fail like HDDs") is also the silence that gives you zero physical feedback while you're testing.
The test order is the same as for any SATA device, and it's short: reseat both connectors, swap the cable, change the port, then check the negotiated link speed in Device Manager — a SATA III drive reporting 3 Gbps is a cable or port problem, full stop. The one SSD-specific adjustment to the method: because there's no spin-up, "is it getting power?" can't be answered by the senses, so it has to be answered by the test (a different power header, a known-good PSU). If the drive fails that whole sequence across multiple systems — good cables, good ports, good power, correct speed — then the drive's controller is the failure. SSDs do fail at that layer, they just fail without the drama that makes an HDD's failure obvious.
BIOS storage settings that can affect detection
Several BIOS/UEFI settings sit between a physical drive and its detection, and they're all in the storage section: individual SATA ports that can be enabled or disabled, the SATA operation mode (AHCI, RAID, or the legacy IDE), M.2 slot configuration (some boards let you choose whether a slot operates in PCIe or SATA mode), and occasionally boot-related restrictions that affect visibility. A drive that is physically healthy but invisible is sometimes one of these toggles, and checking them is free — which puts them ahead of any hardware conclusion, even though they're less exciting than a bad cable to find.
The mode setting is the big one, and the one most people touch by accident, so it gets its own caution: switching between AHCI and RAID changes the driver stack the operating system expects, which can make an installed OS unbootable or make existing disks invisible — that's the next topic in depth. The safe habits that cover most of this topic: don't change the storage mode on a working system without a specific reason; if a drive is missing, check the port enablement and M.2 settings before touching the mode; and if a mode change is genuinely required, plan the OS side first, because the BIOS half is the easy half and the Windows half is where the surprises live. A BIOS change that fixes one drive by breaking the boot disk is not a fix.
AHCI, RAID and storage controller problems
AHCI and RAID aren't just BIOS options — they select the storage driver the operating system uses to talk to the disks, and the two driver stacks are not interchangeable after installation. A system that booted in AHCI and gets switched to RAID (or the reverse) often won't boot, or boots but can't see its old disks, because the driver that spoke to them is no longer loaded. This is the most common "all my drives disappeared after a BIOS change" scenario, and it's a driver problem wearing a hardware costume — the drives are fine, the translator is missing.
The fix depends on direction, and knowing the direction is the whole diagnosis. If you changed the mode and want to go back, change it back — the disks return and the OS boots, and the lesson is that the mode is a system-wide commitment. If you deliberately switched (say, to enable a RAID feature), the operating system side needs the matching driver loaded before or during the switch; on an existing system the least-risky route is usually restoring the old mode and performing the switch properly — with the driver in place — rather than improvising a half-migration. The rule to keep: controller mode is a whole-system decision, not a per-drive one, which is why a surprise in one disk's visibility is usually the mode telling you about all of them at once.
Drive not detected after moving it to another PC
A drive that moves between machines and stops being detected has a short list of cross-machine differences to work through: the storage controller mode (the old PC ran AHCI, the new one is RAID, or the new board uses a different chipset with a different driver), the M.2 slot's mode setting, or simply a bad cable in the new machine. Each is checkable without touching any data, and each is more likely than a drive that died in transit — drives don't usually fail from being moved, connections and settings do.
If the moved drive is a boot drive, add a layer that pure data disks don't have: even when it's detected, an old boot disk attached as a secondary drive to a different system may need its boot record adjusted to the new machine, and that adjustment is a careful, specific procedure — not "initialize it to make it work." A moved boot disk that now shows unallocated or RAW is a partition-table situation (see Category B), and the response is the standard image-first one, because re-initializing a moved boot disk is exactly how people destroy an old system's data while trying to "fix" it. The practical habit: plan a drive move before making it — mode, slot, and boot role checked in advance — because a ten-minute pre-check is what separates a smooth move from a data incident.
Category D · Topics 37–48
Slow hard drives
Slow HDDs split into two populations, and telling them apart is the whole category: drives that are slow by class or environment (normal, stable, fine) and drives that are slow because of damage (progressive, with SMART evidence, not fine). The fixes are opposite — one is optimization and patience, the other is backup-and-replace — which is why the distinction comes first in every topic below.
Why is my hard drive so slow?
"Slow" needs a baseline before it's a diagnosis. A healthy 7200 RPM hard drive does roughly 100–200 MB/s on large sequential transfers and opens a random file in a few dozen milliseconds; far below that, something is wrong; near those numbers, the drive is fine and the complaint is about something else — the files, the workload, or the expectations. The first step is always to measure what "slow" actually is, and a several-GB file copied in Explorer gives you a usable number in seconds, no tools required.
Once you have a number, the causes sort themselves in rough order of frequency. The drive is old and developing bad sectors (slow and getting worse — the failure population). The link is negotiated low (a degraded SATA cable caps you near 280 MB/s and does it silently). The environment is hot (a stifled case degrades performance and ages the drive). The workload is inherently slow for the class (small random files are slow on any HDD, healthy or not). Or Windows is using the disk heavily in the background (indexing, updates, a scan). Measuring first tells you which bucket you're in — and only one of those five buckets is a dying drive, which is the only one that changes your life this week.
Hard drive suddenly became slow
Sudden is the signal, because a drive that was fast and is now slow changed something, and finding the change is the diagnosis. The candidate changes: it started developing bad sectors (the read retries are the slowdown), it started running hot, its link speed dropped (a cable working itself loose does exactly that), or the system changed around it (a Windows update that turned on heavy indexing, a new process hammering the disk). The suddenness rules out "old drive, normal aging" — that's gradual by definition — and points at an event with a date on it.
The triage is three checks, each a few minutes, each pointing at a different fix. Link speed in Device Manager: a drop from 6 Gbps to 3 Gbps is a cable or port event, fixed by swapping the cable. SMART: a jump in reallocated or pending sector counts is a hardware event, and it changes the priority from "fix the speed" to "save the data." Timeline against system changes: a match between the slowdown's start date and an update or installation is a software event, and the fix is on the Windows side. Whichever check lights up tells you which category of this page you're actually in — the three look identical from the user's chair and are completely different problems under the hood.
HDD running at 100% usage
100% disk usage in Task Manager means the drive's request queue is always full — something is reading or writing continuously. Sometimes that's legitimate and temporary: a large copy, a Windows update, an antivirus scan, a defrag pass — all of which finish and the number drops. The problem case is 100% at idle, with nothing you started running, and the persistent version has a few classic residents: the search indexer working over a slow or degrading drive, SysMain (the old Superfetch) thrashing, a stuck read retrying on a bad sector, or a drive so degraded that ordinary operations back up into a queue. The number alone doesn't say which; what the drive is doing does.
The way to separate them is to watch the pattern, not just the percentage. A drive stuck at 100% with reads hammering a small area repeatedly is a bad-sector retry — hardware, and the same mechanism as every other failure sign on this page wearing a "performance" costume. A drive busy with many varied operations is software — indexing, updates, or (worth checking, without drama) something you didn't authorize. A drive that hits 100% only during specific operations is just slow at that workload — the class, not a failure. Two tools make the pattern visible: the Resource Monitor's disk-activity view (which files and processes) and the event log (I/O timeout entries, which are the drive telling you reads are failing, not just slow).
Slow file transfers from an HDD
Transfer speed has a ceiling set by the interface before the drive's own speed enters the conversation: SATA 6 Gbps is the modern ceiling (real-world ~150–200 MB/s for HDDs), a SATA link negotiated at 3 Gbps is half that, and USB 2.0 is roughly 35 MB/s no matter what's attached. So the first question for a slow transfer is "what ceiling am I actually running under?" — and a drive that's fast on one port and slow on another has an interface problem, not a drive problem, which the swap test proves in a minute.
Within the correct ceiling, the shape of the slowness carries the diagnosis. Large-file speed reflects the drive's media and its link: a large-file transfer running at a fraction of the class expectation points at bad sectors, a dropped link, or failing platters. Small-file speed reflects seek behavior: slow small-file opens on an old drive are often just age, layout, and fragmentation (the next topic), which is normal for the class and not a failure. Benchmark against the class, not against an SSD — an HDD doing 120 MB/s of large files and opening files in 30–50 ms is a healthy HDD, and "slower than my old SSD" is a class difference, not a defect. The number plus its shape is the measurement that matters.
External HDD transfer speed is extremely slow
The classic case: an external HDD that used to do 100+ MB/s now crawls at 20–35 MB/s. That number is the fingerprint of USB 2.0, and the cause is almost always the chain rather than the disk: a USB 2.0 cable in a USB 3 port, a USB 2.0 port, a hub that caps the bus, or a USB-C connection that has negotiated down to the lowest common speed. The drive is fine; the pipe got narrower. The fix is to restore the pipe — a cable rated for the drive's speed, a direct rear USB 3 port, no hub — and the speed should jump back to the drive's class when the chain is right.
Only after the chain is verified do you look at the enclosure and the drive. A failing enclosure controller throttles transfers and is tested by trying the drive in a different enclosure (if it's a removable 2.5-inch in a USB case). A drive with developing bad sectors drags the large-file number down from the inside, and that's the case where the speed problem is actually a health problem — the tell being that the slowness is progressive and SMART shows the sector counts moving. The order matters because the pipe is the common cause and the drive is the scary one: don't replace a disk, or pay for recovery, that a ten-dollar cable would have cleared. Measure the chain first, the components second.
HDD takes a long time to open files
Opening a file is a seek-plus-read operation, and it's where a mechanical drive's age shows first, because the read head has to physically travel to the data. On a drive with bad sectors, any open that touches a damaged area triggers a firmware retry that the user experiences as a hang of seconds. "Files take 5–20 seconds to open" on a drive that used to open them instantly is one of the earlier — and more honest — failure signals an HDD gives, because it's the retry mechanism announcing itself directly to the person using the machine.
The three causes are separable by their pattern. If all files are slower — small ones, fresh copies, everything — it's the drive's media or its overall health, and SMART plus a read-only scan will confirm it. If specific files or folders are slow, it's their location on the platter (or, for a single file, the file itself), which is a layout problem, not a health one. If the slowness comes and goes with load and temperature, it's the environment. The drive-health version is the one that should change your behavior: it's confirmed by rising reallocated or pending sector counts, and its answer is backup-and-replace, not optimization. The layout and environment versions are the ones that are fine to live with, optimize, or ignore — the pattern is what keeps the three from being treated as the same problem.
HDD causes Windows to freeze
A system-wide freeze tied to disk activity is the drive stalling an operation the OS cannot proceed without: a read that's retrying on a bad sector, the pagefile living on a drive that's choking, or a filesystem operation waiting on a volume that's degrading. The tell is the freeze pattern itself — the whole UI locks, the cursor freezes, the machine is unresponsive, and it resolves after seconds to minutes when the drive gives up or finally succeeds — rather than one application hanging while the rest of Windows stays alive. A whole-system stall is a storage-stack stall; the layer below the apps is where the wait is happening.
The correlation is the diagnosis, and it runs two ways. If the freeze always follows access to a particular drive — open its folder, the machine locks — that drive is the culprit, stated plainly. If the freezes are random, the event log is the second route: disk I/O timeout and NTFS error entries timestamped around the freeze moments point at the same conclusion from the other direction. A drive that freezes the OS is a drive failing at the I/O layer, and the correct response is the failure protocol — back up, verify the backup, plan the replacement — not performance tuning. Tweaks, drivers, and registry fixes will not fix a retrying platter; the freeze is the drive's voice, and it's saying the media is going.
Slow HDD vs failing HDD
This is the distinction the entire hard-drive half of the page boils down to. A slow-but-healthy HDD is slow because of its class (mechanical seeks, small-file workloads, an older interface) or its environment (heat, a shared or negotiated-down bus) — and its slowness is stable, week to week, month to month, with clean SMART data. A failing HDD is slow because of damage — bad sectors, retry loops, a weakening motor — and its slowness is progressive, getting worse over weeks, with SMART data (reallocated sectors, pending sectors, spin retries) that is not clean. Same symptom from the chair; opposite problems under the hood; opposite correct responses.
The practical test is two-part, and both parts are free. Measure the trend: stable slow across months is "old drive, normal life — buy an SSD if you're impatient"; slow that measurably worsens over weeks is damage, and the conversation is data. Read SMART: clean attributes with slow performance is the healthy population; rising reallocated or pending counts is the failing population, full stop. Benchmark numbers alone prove neither — a fast drive can be failing (the bad sector it hasn't hit yet) and a slow drive can be perfectly healthy (the class, the heat, the cable). The trend plus SMART together are the reliable verdict, and they're what separate "upgrade your storage" from "back up tonight."
How to test hard drive read and write speed
The usable home test is a large-file copy: move a several-GB file to the drive, read the transfer rate Explorer reports, and compare against the drive's class — roughly 100–200 MB/s for a healthy HDD, 450–550 for a SATA SSD, 2000+ for NVMe. Dedicated benchmark tools add detail (small random operations, queue depth), but for health purposes the large-file sequential number is the one that matters, because it's the one bad sectors drag down, and it's the number that matches real usage (backups, video, large documents) rather than synthetic workloads.
Two cautions keep the test honest. Test through the same path the problem appears on: a drive that's fast internally but slow over USB has a chain problem, and an internal benchmark will happily miss it — the test has to reproduce the complaint, not just measure the drive. And a single benchmark cannot prove health in either direction: a drive can pass a burst test and still hold a bad sector it hasn't been asked to read, and a slow drive can be perfectly healthy by every measurement. Benchmarks measure performance; SMART attributes and a full read-only scan measure health. They answer different questions, and the useful habit is to run each for what it's actually for — speed for the speed complaint, SMART and scans for the getting-worse complaint.
When HDD fragmentation actually matters
Fragmentation is data scattered across the platter so that one file needs many head movements to read. On modern systems it's mostly managed automatically — Windows' scheduled optimization runs on HDDs and is correctly disabled for SSDs — so "defragment to fix my slow drive" is usually not the answer people hope it is. Fragmentation genuinely matters in a few specific situations: a drive holding many large media files that get rewritten often, a drive that's very full (little free space to consolidate into), and a drive that's already marginal, where the extra seeks amplify existing slowness. In those cases, a defrag pass can recover real time.
Where it doesn't matter is a longer list. An SSD: defragmenting one is pure write-wear for zero benefit — never do it; TRIM is the SSD's equivalent and it runs automatically. A drive whose slowness is tied to specific files or is progressive over time: that's media damage, not layout, and defragmentation is a placebo that delays the correct answer. A healthy modern drive under normal use: the automatic schedule already handles it. If you do suspect layout, the built-in defragment and optimize utility reports the drive's state and performs the safe case for you — but if the slowness is progressive or SMART is dirty, the defrag will "complete successfully" and change nothing, which is itself the answer: the layout was never the problem.
HDD performance problems caused by heat
Heat's role in hard-drive performance is subtler than the popular story, and getting it right matters for diagnosis. HDDs don't throttle the way a CPU does — there's no governor that cuts speed at a temperature — but sustained high temperatures accelerate every failure mechanism a drive has: the platter lubricant degrades faster, the electronics age faster, and the drive's own read error rate climbs. So heat is less a direct speed-killer and more a multiplier on the other failure signs. A hot drive that's also getting slower should be read as a failing drive in a hot environment, not as a performance issue with a thermostat fix.
The practical checks are environmental and free: is the drive running hotter than its neighbors (SMART exposes a temperature attribute; a hand or an IR reader is a rougher but usable proxy), is the case airflow starved (dust-clogged intake, a dead case fan, a blocked rear vent), and is the drive's position a hot spot (directly above the GPU, in a sealed bay with no intake)? Fixing the environment — airflow, dust, repositioning — is safe and worth doing regardless, because a cooler drive is a longer-lived drive. But the honest limit: if the temperature is high and the SMART data is already dirty, the environment fix slows the decline; it does not reverse it. Heat management is maintenance, not repair — the distinction that keeps a real failure from being misdiagnosed as a fan problem.
HDD performance problems caused by bad sectors
Bad sectors are the mechanical drive's signature failure mechanism, and they attack performance before they attack data — which is why a "slow drive" is often a "failing drive" in its early, polite phase. Each damaged sector makes the drive's firmware retry the read (the user feels it as a stutter or hang), and when the retry finally succeeds the firmware moves the data to a spare area and re-maps the address (the user feels nothing; SMART records one more reallocated sector). A drive accumulating bad sectors therefore gets slower in a very characteristic way — the stutters get longer and more frequent, the "freeze then continue" moments multiply — long before it stops working at all.
The detection path has two views of the same damage. From the drive's side, SMART's reallocated sector count (data already moved off bad areas — any rise is news) and current pending sector count (sectors the drive is retrying right now — these are your stutters, about to become reallocated or about to start dropping data). From the filesystem's side, a read-only scan surfaces the same damaged areas as I/O errors. When the two views agree, the diagnosis is a drive with growing media damage, and the response is the standard one: stop using it for anything irreplaceable, back up what matters, verify the backup opens (a copy made while the drive was throwing read errors may have copied the errors), and plan the replacement. A drive with rising sector counts doesn't get fixed by software. It gets retired with dignity.
Category E · Topics 49–60
Slow SSDs
SSD slowness is mostly about operating conditions — fill level, TRIM, firmware, temperature, interface — which makes it the most fixable slow-drive category on this page. The topics below work the conditions first, and end where the conditions stop explaining the slowness and the media starts showing it.
Why is my SSD so slow?
The first question is "slow against what," because an NVMe drive doing 500 MB/s is perfect for a SATA-class path and terrible for its own class, while a SATA SSD doing 400 MB/s is exactly where it should be. Measure against the interface's ceiling — SATA: ~550 MB/s; NVMe: 2000–7000+ depending on generation — not against the marketing number, and find out which ceiling you're actually running under. The most common "my SSD is slow" turns out to be an interface mismatch: a drive in the wrong slot, a cable negotiated low, or expectations imported from a faster class of drive.
Within the correct interface, the usual suspects line up in a testable order. The drive is nearly full (SSD performance degrades as free space runs out — see the free-space topic). TRIM isn't running (write performance decays over time as the drive accumulates deletions — one-line check). The firmware is an old or known-bad revision (vendor release notes). It's thermally throttling (NVMe drives cut speed to protect themselves when hot). Or, less commonly, the NAND or controller is starting to fail (the final topic in this category). Each has a distinct check, each takes minutes, and the good news of the SSD half of this page: four of the five are fixable without replacing anything.
SSD suddenly became slow
Sudden slowness on an SSD is almost always one of three events, and all three are reversible — which is exactly why "sudden" is good news on a solid-state drive. The free space dropped below the comfortable line: a big install, a video project, a game library filled the drive and write performance fell off a cliff, sometimes within hours. TRIM stopped running: a Windows hiccup, a filter driver, or the drive crossing a state where it needs a manual trigger, and the write decay set in. Or the firmware changed: an update landed — sometimes automatically — right when the slowness started, and the new revision is the problem.
The triage follows the list in order of likelihood and ease. Free space first: free up 10–20% and retest — if the speed comes back, that was the whole story, and the permanent fix is behavioral (keep the headroom). TRIM second: verify it's enabled and has run — it's a one-line check, and if it's off for some reason, turning it on and letting it do a pass often restores the lost performance. Firmware third: compare your revision against the vendor's release notes, and if a known-bad revision matches the timing, the update path is the fix. If none of the three and the slowness persists — especially with SMART error attributes moving — you've moved out of conditions and into media, and the last topic in this category takes over. But test the conditions first, because they're the common case and the cheap ones.
SSD running out of free space
SSDs need free space the way a parking lot needs empty spots, and the mechanism is worth understanding because it explains the symptom exactly. The controller performs wear leveling and garbage collection using spare and free blocks: it writes new data to fresh blocks and erases old ones in the background. As a drive approaches 100% full, that process starves — there are no fresh blocks to write into and nothing to erase without disturbing live data — and write performance degrades, sometimes dramatically. This is a design characteristic shared by every SSD, not a defect in yours: the fix is behavioral, and it's to keep roughly 10–20% free.
The symptom pattern is specific and useful for diagnosis: a write-speed decline that tracks the fill level, often with reads staying normal — which is what distinguishes fill-induced slowness from media failure (which usually shows on reads too, and comes with SMART error counts). The fix is freeing space, plus letting TRIM run (automatic in modern Windows, or a manual re-TRIM if it hasn't run since the drive filled) — and the performance typically recovers once the headroom is back. For a drive that lives near full by necessity — a small boot SSD in a laptop — the honest responses are a bigger drive or moving bulky data elsewhere, because running an SSD at 99% full is a performance and longevity tax paid continuously, and it's the kind of slow that "fixes" itself for a week after every cleanup and then returns.
SSD performance and TRIM, explained
When a file is deleted, the SSD's blocks still hold the old data — and a NAND block cannot be written until it's erased. TRIM is the operating system telling the drive which blocks are no longer in use, so the controller can erase them in the background and keep a pool of fast, ready blocks for writes. Without TRIM, the drive does that erase work in-line, at write time, every time: each write first pays the erase cost for the block it's overwriting, and the whole drive gets slower as it ages and churns. TRIM is the difference between an SSD that stays fast and one that slowly becomes a very expensive, very quiet HDD.
The practical state on modern Windows: TRIM is enabled by default for SSDs and runs on a schedule, so the check is quick — and worth doing, because if it's off for some reason (a misdetected drive type, a filter driver, a setting change), turning it on and letting it run is often the entire fix for a write speed that's been decaying for months. The one caution that belongs with this topic: TRIM on a drive that's also failing can surface the failure, because the erase work stresses the weakest NAND. If a TRIM pass is followed by new SMART error counts, read that as information about the drive, not a fault in TRIM — the mechanism did its job and the media answered honestly. The check command is read-only:
fsutil behavior query Disable-TrimReports whether TRIM is disabled per volume (0 = enabled). Read-only query; it changes nothing.
SSD write speed dropped dramatically
A dramatic write drop has a specific pattern to check for before any alarm: the burst-then-cliff. Many SSDs — especially DRAM-less and budget models — write at top speed into a fast SLC cache, then fall to a much lower sustained speed once the cache is exhausted. If the "drop" happens after a certain amount of data in a single transfer — 3000 MB/s for a gigabyte, then 300 — that's the design working as documented, not the drive failing. A benchmark that shows both numbers is a normal drive doing a long copy; the alarm should be reserved for what the sustained number does over time.
The disease versions of the drop have different shapes, and the shape is the diagnosis. The sustained number itself declined from what this drive used to do: that's the fill/TRIM/firmware family — work the sudden-slowness list and one of the three will usually own it. The drop is accompanied by reads slowing too: that's media — the NAND is degrading, and the SMART error attributes will show it; the last topic in this category covers that transition. The drop is total — the drive refuses writes outright: that's a controller problem or an end-of-life state, and on many drives it's a deliberate protective "read-only" mode the controller enters when it can no longer trust the media. The first step that separates all three is a long-file copy that shows you the whole curve, because a short benchmark only shows the cache and can't tell the three apart.
SSD slows down during large file transfers
Large transfers stress exactly the parts of an SSD that have limits, which is why "slow on big files" is more often a limit being hit than a failure happening. The SLC cache exhausts after a while (the sustained number takes over). The interface has a ceiling (a SATA drive cannot exceed ~550 MB/s no matter what's attached). DRAM-less drives lean on host memory for their translation table and degrade under queue pressure that a DRAM-equipped drive absorbs. And a sustained transfer is a thermal event — the controller heats up, and past its limit it throttles. Four different mechanisms, one visible symptom, and the first job is identifying which limit you've hit before calling the drive bad.
The separation method: compare the number against the drive's class and interface ceiling (at or near the ceiling? then the drive is doing its job and the fix for wanting more is a faster class, not a repair). Check the fill level and TRIM state (the two fill-related causes, both fixable in minutes). Measure or feel the temperature during the transfer (the thermal cause, fixed with the pad and airflow). And note whether reads are affected at all — if only writes slow while reads stay at class speed, the media is almost certainly fine. Most "my SSD chokes on big files" reports end at one of those four checks with the drive fully exonerated, which is the reassuring pattern of this whole category: the conditions are common, the checks are cheap, and the drive is usually the innocent party.
SSD health, wear, and remaining life
SSDs wear in a way HDDs don't, and the drive tracks its own consumption honestly: every NAND cell has a finite number of program/erase cycles, and the firmware reports the cumulative consumption as a "percentage used" or wear counter, plus total bytes written against the drive's rated endurance (TBW). Reading these is the SSD's equivalent of checking an odometer — and like an odometer, the number means something different at different ages. A drive at 10–30% used after a couple of years of normal use is exactly where it should be; a drive reporting 90%+ used is near the end of its rated life and deserves a replacement plan even if it's still fast today.
The reading discipline has two parts. Context: high wear on an old, heavily-used drive is normal history; high wear on a new, lightly-used drive is not, and points at a workload problem (constant rewriting) or a reporting problem — check which before reacting. And the crucial distinction: the wear counter measures endurance, not health. A drive can be barely worn and broken (a failed controller, a bad power event), and it can be heavily worn and perfectly fine — the counter and the error attributes answer different questions. "Health 100%" on a drive that's throwing read errors is the number to distrust; "82% used" with clean error counts on a four-year-old drive is the number to shrug at. Endurance from the wear counter, health from the error attributes — and you need both to know where the drive actually is.
SSD firmware and performance problems
SSD firmware is the drive's own operating system — the code that manages the NAND, the cache, the wear leveling, and the interface — and like any OS it has bugs, some of them performance bugs that affect specific workloads, specific fill levels, or specific host systems. A known-bad firmware revision is a real, documented cause of "this drive is suddenly doing something weird," and the vendor's release notes (the support page for the exact model) are the place to check whether your revision carries a known issue and whether a fix exists. It's an under-checked cause because it's invisible from Windows until you look for the revision number.
The update decision has a risk side that's worth stating plainly. On a healthy drive, a firmware update is low-risk — the drives are designed for it, it's how vendors ship fixes, and it runs from the vendor's tool — so if your drive's problem matches a documented fix, the update is the fix. On a drive that's already showing media errors, the same update is a write workload across the entire drive, which stresses weak NAND: updating a failing drive as a repair attempt can be the thing that finishes it. The rule: check the revision, read the notes, update a healthy drive to fix a known bug, and never firmware-update a drive showing failure signs hoping for the best. The firmware is a tool for fixing the living, not resuscitating the dying.
NVMe SSD running hot and throttling
NVMe drives run hot by design — the controller and NAND share a small footprint with little thermal mass — and they throttle by design too: past a thermal limit, the firmware cuts speed to protect the silicon. So "my NVMe is hot" needs numbers before it needs a verdict: 40–65°C under load is normal operating territory for many drives, and the throttling range typically starts somewhere around 70–90°C depending on the model. A throttling drive isn't broken — it's doing its thermal protection exactly as engineered — but persistent throttling means the cooling path needs work, and it means you're not getting the drive you bought.
The cooling chain for an M.2 drive has three links, and the first is the most commonly broken. The thermal pad between the drive and the heatsink: wrong or missing pad is the classic culprit — too thick and it prevents contact (or keeps the drive from seating fully, which is a detection problem in disguise); too thin or compressed out and there's no interface. The heatsink's own airflow: a passive heatsink in a case with no air moving across it does less than its size suggests. And the case ambient: a stifled case raises every component's floor temperature. The method: measure under a sustained load (a long transfer or a benchmark), compare against the drive's published thermal limits, fix the pad, airflow, or ambient, and retest. A drive that throttles even with a correct pad in a well-ventilated case is the rare case — but the pad is the common one, and it's a five-minute check.
SATA SSD vs NVMe SSD: performance problems differ
The two classes fail and slow down differently because the interfaces are different, and the diagnostic order should follow that. A SATA SSD's ceiling is ~550 MB/s and its thermal and electrical margins are forgiving; its performance problems are the fill, TRIM, and firmware family, and thermal is a late suspect at best. An NVMe drive's ceiling is several times higher, its thermal density is far worse, and its problem list adds two entries SATA never has: thermal throttling as a primary cause, and slot/interface issues (an NVMe drive in a SATA-only M.2 slot runs at SATA speed — "five times slower" with nothing wrong with the drive — plus PCIe lane and slot-configuration quirks).
The diagnostic difference in practice, as two checklists. Slow SATA SSD: fill level, TRIM state, firmware, then health — work the list and stop when the number recovers. Slow NVMe: add two earlier steps — confirm the slot and the link first (the wrong-slot case is the great mimicker, and a slot check is free), then confirm the thermal path before the conditions, because throttling is the one NVMe-specific cause that looks identical to everything else from the benchmark's chair. One last note on cross-interface comparisons: "my old SATA SSD was faster" is only true if they were tested the same way — short bursts favor caches, sustained transfers favor interfaces, and a comparison that mixes the two is comparing different numbers. Same drive, same test, same conditions — that's the only comparison that means something.
How to test SSD read and write speed
The SSD version of the speed test has the same shape as the HDD version but different expectations, and the extra step is the one people skip. Measure a large-file copy against the interface ceiling — SATA: 450–550 MB/s real-world; NVMe: 2000+ depending on generation — and then do the long transfer that exposes the sustained number, the one after the SLC cache exhausts. A short 1-GB benchmark shows the cache; a 10-GB transfer shows the drive. Real usage — backups, video, large installs — lives in the sustained number, which is the one that matches the complaints this category is about.
The health angle is where SSDs differ from HDDs, and it changes what the test is for. SSDs don't stutter on bad sectors the way platters do — there's no retry-hang signature — so a speed test is less of a health signal here and more of a performance signal. The health lives elsewhere: the wear counter and the error attributes (the health topic), and the write behavior under fill (the free-space topic). The useful combination for an SSD is three measurements, each answering one question: the speed test confirms the drive meets its class (interface, cache, thermal), the wear/health counters confirm it's meeting its life, and the fill/TRIM state confirms the operating conditions are normal. All three normal and the drive still feels "slow"? It isn't — it's the class you bought, and the fix for that is a different drive, not a repair.
When an SSD's slow performance indicates failure
SSDs fail less noisily and, in terms of performance, less gradually than people expect, and knowing the shape of the endgame is what turns "slow" into "dying." The classic sequence: NAND wears out area by area, the controller's spare blocks run low, and then the drive degrades in specific ways — write performance collapses (no healthy blocks left to wear-level into), the drive locks into read-only mode (a deliberate protective state on many controllers, which is why a "read-only SSD" is a failure mode, not a setting), or it vanishes from the system entirely. The warning that belongs to this topic: slowness that looks like fill or TRIM but doesn't respond to fill and TRIM is the media showing itself. The conditions were tested, the conditions were fixed, and the slowness stayed — that's the handoff from Category E's fixable world to Category F's preserve-the-data world.
The tell that separates operating condition from failure has two parts, and both must be present to call it. The fixes that work for conditions — free space, TRIM, firmware, cooling — have been applied and the slowness persists. And the counter evidence is there: media error counts in SMART that are non-zero and climbing, a percentage-used anomaly, or the read-only state appearing. When both are true, that's a failing SSD, and the correct next step is the same protocol as for a failing HDD — back up, verify the backup, replace — with one SSD-specific urgency: a dying SSD can take the data with it quickly and without the long audible warning an HDD gives, so "back up this weekend" becomes "back up now." The silence that makes SSDs convenient in life is what makes their endgame a race, and the slowness is the starting gun.
Category F · Topics 61–72
Early failure symptoms
The failure signs, and the decision rules for reacting to them. The through-line: mechanical drives fail loudly and gradually — listen. SSDs fail silently and in the counters — watch SMART. And in both cases, the moment the data is genuinely at risk, the job changes from troubleshooting to preservation, and the stop rules in this category override every other advice on the page.
Ten warning signs a hard drive may be failing
Mechanical drives rarely fail silently, and their warning signs cluster into a recognizable set. In rough order of seriousness: (1) clicking or grinding noises; (2) repeated spin-up attempts or beeping; (3) SMART reallocated sector counts rising; (4) pending sector counts appearing; (5) new and growing read errors; (6) files corrupting without an explanation; (7) progressive slowness with stutters; (8) the system freezing when the drive is accessed; (9) the drive disconnecting under load; (10) the drive running hot and getting hotter. Each one has its own topic on this page; this list exists so you can count them, because the count is what drives the decision.
Two rules turn the list into a response. Count matters: one sign, mild and stable for months, is "investigate soon and keep an eye on the SMART trend" — a conversation for a weekend. Several signs, or any sign that's worsening week to week, is "back up now and plan the replacement" — a conversation for today. And noise trumps everything on the list: a drive that's making mechanical sounds (clicks, grinds, scrapes) is past the software-diagnosis stage, and the priority is data preservation — imaging while it cooperates, or professional recovery — not troubleshooting, because continued power cycles on a mechanically failing drive make the data problem worse, not better. The signs are symptoms; the rules are the treatment.
Early signs of SSD failure
SSDs don't creak, so their early signs are all in the data, and the discipline is to actually look at the data. The set: media error counts appearing in SMART (the NAND is losing cells it can no longer correct), write performance that declines and doesn't respond to the usual fixes (free space, TRIM — the controller is running out of healthy blocks to work with), the drive occasionally refusing writes or locking into read-only mode (the protective state), and — the late sign — the drive vanishing from the system entirely. The absence of any physical symptom is not the absence of failure. It is the failure mode, which is why "it makes no noise" is no comfort at all on a solid-state drive.
The practical watch items, in order of value. The media and uncorrectable error attributes in SMART: any non-zero count that's climbing is the signal, and it's the SSD equivalent of an HDD's rising reallocated sectors. The write-behavior pattern: does the conditions checklist (fill, TRIM, firmware, thermal) actually fix the slowness, or does the slowness survive the checklist — survival is the media talking. And the trend over time: a snapshot of the health counters every few months shows the direction, which a single reading can't — one quiet reading is nothing, three quiet readings followed by a dirty one is a diagnosis with a date on it. An SSD showing the error attributes doesn't need to be "fixed" any more than a clicking HDD does. It needs to be replaced with the data moved, and the timeline for that move is set by how fast the error count is climbing, not by when it's convenient.
Hard drive clicking sounds
A rhythmic click — click, pause, click — is the drive's read/write heads repeatedly seeking and failing to lock onto the platter, and it's the sound that gives "click of death" its name. Mechanically, it usually means the head assembly or the actuator that moves it is failing, or the drive's firmware is stuck in a seek-retry loop it can't escape. It is not a sound that software fixes — no scan, no chkdsk, no driver will stop a head that can't park — and it's the single clearest "stop powering this drive on and off" signal a disk can give. The click is the drive telling you the mechanism is failing, in the one language that doesn't require a SMART reader.
Why the power cycling is the danger, specifically: each spin-up is a mechanical event, and a head assembly that's already marginal gets more marginal with each one — the click of death gets worse with attempts, not better, which is the opposite of how electronic problems behave and the reason the standard troubleshooting instinct ("try it again, try it a different way") is actively harmful here. So the correct response to a clicking drive with data on it is to stop, and then choose the preservation path. If the data is backed up or unimportant, the drive is a replacement and the click was the whole diagnosis. If the data matters, the move is professional data recovery — clean environments, donor parts, the tools for exactly this failure — or, if the drive still occasionally mounts, a careful image made in that window, with the working expectation that "occasionally" will stop being true. The click changes the job from repair to rescue.
Hard drive grinding or scraping sounds
Grinding or scraping is a harder sound than clicking — it's heads making contact with platter surfaces, or the spindle bearing degrading — and it indicates physical damage to the media or the mechanics rather than a failing actuator that's still clearing the platters. A drive that scrapes has already damaged its own data surface in the places the heads touched, which changes the math in a way the clicking drive didn't: even a perfect recovery can't bring back what the heads physically overwrote, and the quality of any recovered data depends on how much contact happened. If the distinction between the two sounds matters, this is the one: clicking is the mechanism failing; scraping is the mechanism failing and touching the data.
The response is the strictest version of the stop rule on this page: power it off, leave it off, and don't power it on "just to check" — every check is another pass of damaged heads over damaged platters. If the data is irreplaceable, that's a professional recovery situation, with honest expectation-setting: a scraped-platter recovery is the expensive, uncertain end of the recovery spectrum, and the labs that do it will price it accordingly, because the difficulty is in the media, not the method. If the data is backed up or replaceable, the drive is e-waste, full stop. And the lesson that makes the next one cheaper: the grinding was preceded — often by weeks — by the earlier signs on the ten-signs list. The drives that grind are the drives whose clicking, stutters, and SMART warnings got answered with "it's still working."
Hard drive beeping or repeated spin-up attempts
A drive that beeps, or spins up, stalls, retries, and repeats, is failing its own self-test at power-on — the firmware can't bring the drive to a ready state, so it restarts the attempt. The causes sit in the same mechanical territory as the clicking drive (heads, actuator, firmware stuck in its recovery loop), and the repeated attempts are the drive's own retry mechanism doing damage with every cycle it performs. A beep that's rhythmic and persistent is the drive telling you it can't start — not that it's about to, not that a reboot will fix it, but that the start sequence itself is failing. It's a rarer sound than clicking and a more urgent one, because the failure is happening at the moment of power-on rather than during use.
The stop rule applies with extra force, because the damage is happening on every boot attempt: a beeping drive in a machine set to boot from it is power-cycling itself into worse shape every time someone tries to start the computer. The paths are the same as for the clicking drive — professional recovery, or a careful image if the drive occasionally reaches a ready state — but the planning assumption should be that the window is closing, because a drive that can't complete its self-test reliably is a drive whose cooperation is intermittent by definition. Two honest caveats keep the diagnosis fair: a marginal power supply can mimic some spin-up failures, so one gentle power-side check (different header, known-good PSU) is reasonable — one try, not a reboot loop; and a beeping drive whose data isn't critical is a replacement, with the beep as the entire diagnosis. The drive has already told you the answer. The discipline is in not re-asking it.
Files becoming corrupted without an obvious cause
File corruption has three layers to separate, and the pattern of the corruption is what separates them. The file itself: a bad write, an app bug, an interrupted transfer — isolated, one-off, and fixed by re-copying the file from its source. The filesystem: the structure holding the files is damaged, and the corruption follows a pattern — a folder, a volume, a type of file — and re-copying helps until it doesn't. The media: the platters or NAND are failing, and the corruption grows — appears on files you didn't touch, on files that were fine yesterday, and reappears after you repair it. One file, once, is the file. Many files, growing, is the drive, and the response is a completely different one.
The test that separates them is deceptively simple: repair or re-copy the affected files, and watch. If they stay healthy for weeks, it was a one-off and you can close the book. If the same files corrupt again, if new files start corrupting, or if the corruption follows a whole volume, the layer is below the files — filesystem or media — and the response is a read-only scan plus a SMART check, with the working assumption that a drive corrupting data is a drive that's failing and everything important on it should be getting off now. "Corruption without an obvious cause" is the most under-reacted-to warning sign on this list precisely because the files still mostly work — the drive keeps serving data around the damage, which reads as "it's fine" until the day the damage hits the one file that had no backup. The growth pattern is the diagnosis; the backup is the treatment; the drive's retirement is the cure.
Frequent read errors
Read errors — the event log entries for disk read failures, the "device not ready" messages, the Explorer hangs that resolve into an error dialog — are the filesystem layer reporting that the media layer isn't delivering. A single read error on an otherwise clean drive, once a month, is noise; every disk has an occasional bad read it retries and clears. Frequent read errors, especially with a date pattern — more this week than last, more under load than at idle — are the drive's firmware retrying damaged sectors and mostly winning, which is exactly the state where the data is still readable and the drive is still failing, and the readability is the retry mechanism doing its job rather than the media being healthy.
The correlation work takes minutes and produces the diagnosis. The event log shows the errors and their frequency and timestamps. SMART shows whether they correspond to reallocated or pending sectors — they usually do, and the match is the confirmation. A read-only scan shows how widespread the damaged area is — a cluster in one region or scattered across the platters, which matters for both prognosis and recovery planning. When the three sources agree, the diagnosis is a drive with growing media damage, and the response is the standard protocol: back up, verify the backup — a copy made while the drive was throwing read errors may have copied the errors, and an unverified backup of a failing drive is a false sense of security — and replace. The verification step is the one people skip, and it's the one that converts "I copied it" into "I actually saved it."
Bad sectors, explained
A sector is the drive's smallest addressable unit, and a "bad" sector is one the media can no longer reliably read or write. Drives ship with a pool of spare sectors, and the firmware's job is to keep the damage invisible: when a sector starts failing, the drive retries the read (you feel it as a stutter), moves the data to a spare sector, and re-maps the address so software never knows (SMART records one more reallocated sector). A drive that accumulates a handful of reallocated sectors over five years of life is normal — media wears. A drive whose reallocated count is rising, especially quickly, is a drive that is actively losing media, and the difference between those two statements is the difference between a healthy old drive and a failing one.
The three sector states that matter, in escalating seriousness, are the vocabulary for reading any SMART report. Reallocated: the drive has already given up on those sectors and used spares — past tense; the count's trend is what you watch, not its absolute value. Current pending: the drive is retrying these right now and hasn't decided what to do with them — present tense; these are your stutters, and each one is about to become a reallocation or start dropping data. Uncorrectable: the data there is gone — the damage has already happened, and no amount of scanning brings it back. Seeing pending or uncorrectable in SMART is not a "maybe" state to monitor from a distance. It's the drive telling you the media is failing, in the drive's own instrumentation, and the response is data first — copy, verify, move on — questions about the drive second. The sectors don't negotiate.
SMART errors, explained
SMART is the drive's self-monitoring system: a set of attributes the firmware maintains that report the drive's own view of its health, from the inside, over its whole life. The attributes worth knowing, by drive type. On HDDs: reallocated sector count (spares used — the trend is the story), current pending sector count (sectors being retried now — any non-zero deserves attention), and spin retry count (motor and head retries at startup — rising counts are mechanical trouble). On SSDs: media error count (uncorrectable NAND errors — the SSD's reallocated sectors), percentage used (wear against rated life — the odometer), and uncorrectable error count (data already lost). Each attribute has a raw value (the actual count — what you read) and a normalized value (the drive's scaled score — what the threshold logic uses), and the raw value is the one that carries information.
How to read it without panicking or ignoring, because both failure modes are common. A non-zero reallocated count on a five-year-old drive with a stable count is history, not an emergency — the drive banked those sectors years ago and has been fine since. The same count going up this month is an emergency, same number, different derivative. A pending sector count of zero is normal; any non-zero is "the drive is retrying sectors right now," present tense, and it deserves the backup conversation this week, not next quarter. And the threshold model — the normalized value crossing its limit, the "failed" flag — is the drive's own "I'm done" signal, which means by the time an attribute crosses its threshold the drive is already failed; the useful SMART work happens months earlier, reading raw counts and their trends. The quickest home view of the picture:
Get-PhysicalDisk | Format-TableShows each disk's health status, media type, and size. For per-attribute SMART detail, use a SMART utility or the vendor's tool.
Computer freezes when accessing a drive
A freeze specifically triggered by accessing a drive — open the folder, the whole system locks — is the OS waiting on a disk read that's retrying or stalling, and it's one of the more specific failure signals available because the trigger and the cause are connected in a way you can reproduce. The whole system freezes, not just the application, because the wait is in the storage stack, below the apps: Windows can't proceed with anything that touches that volume, and much of it touches that volume. The pattern to confirm is simple — the freeze follows access to that particular drive, reliably, and the event log around the freeze moments shows disk I/O timeouts or filesystem errors.
The diagnosis runs the familiar path, with one important branch. SMART for the media state: dirty or rising, and the drive is failing — backup-verify-replace, with the timeline set by how often the freezes happen (daily freezes are a this-week replacement, monthly freezes are a this-month one). The event log for the error pattern: the timestamps and the error types confirm the I/O layer is the stall point. And the branch that keeps an innocent drive from being condemned: if SMART is clean and the freezes are tied to one drive in one machine, widen the search to the connection — cable, port, power (Category C) — because a marginal SATA connection or a starving power header produces exactly this symptom with the drive itself perfectly healthy. The trigger-connection is what keeps the two diagnoses apart: same freeze, different machine behavior, different culprit, and a very different $10-vs-$100 conclusion.
Drive disconnects under load
A drive that's fine at idle but drops under load has a signature that points at power and thermal before it points at data paths, and the reason is physical: under load, the drive draws more current (active heads, controller at full speed, spin-up peaks) and runs hotter, and a marginal power connection, a failing PSU header, weak USB power delivery, or a thermal limit will all reveal themselves exactly there. The symptom set is recognizable — disconnects during large transfers, after a few minutes of sustained work, or when other drives are working too — and reliability when the drive is barely doing anything. "Fine until I ask it to do something" is the power-and-heat family announcing itself.
The triage follows the load chain in order. Power first: a different SATA header, a powered hub or direct rear port for externals, a different PSU if one's available — the under-load dropout of a marginal header is cured by a good header, full stop. Then the data path: cable and port, because a marginal SATA or USB connection also drops under the electrical stress of load and looks identical from the user's chair. Then the drive's own state: a controller that's failing often drops off the bus under precisely the stress that load applies, and that's the case where every external test passes and the dropouts continue. The event log is the tie-breaker — bus-reset entries timestamp the dropout and name the bus, which separates "which port" from "which drive." And the outcome that matters: a drive that survives every connection and power test but still drops under load is a failing controller, and at that point it's a data-preservation conversation, not a settings one — copy, verify, replace.
When you should stop troubleshooting a failing drive
The stop line exists because some failures get worse with the troubleshooting, and a method that's correct for a healthy drive is wrong for this one. The conditions that cross it: any mechanical sound — clicking, grinding, scraping; the drive is a physical problem and power cycles are the damage. Irreplaceable data combined with any sign of media failure — the risk of another repair attempt now exceeds the information it would produce. A drive that's dropping sectors faster than you're copying them — you're racing a loss, and the race is decided by the media, not your speed. And the point where the cost of professional recovery stops being justified by the value of the data — an honest calculation, and the only stop condition that's about money rather than physics. Each is a "stop" for a different reason, and they all point the same direction: preserve, don't fix.
What "stop" actually means, concretely, because the vague version doesn't survive contact with a failing drive. Power the drive off and leave it off — the single most valuable action available, and the one most often not taken. If the data matters, the path is professional data recovery (clean rooms, donor parts, the tools a failing drive needs), or — if the drive still cooperates — a single careful image, made once, verified, with the expectation that the window is temporary. Not repeated scans, not repair passes, not "one more try." And if the data doesn't matter, the drive is a replacement, and the troubleshooting you just finished was the diagnosis — it told you what the drive is, and that's enough. The through-line of the entire page in one sentence: a failing drive is a data problem wearing a hardware costume, and the moment you accept that framing, the stop line draws itself. You stop when continuing costs more data than it saves.
Guided route
Diagnostic decision tree
Answer the questions in order and the tree will route you to the topics that match your situation. It's a navigator, not a diagnosis — and it never recommends a destructive step on its own; where data is at risk, it points at the safety rules instead.
Step 1
Reading the health signals
Drive health and warning severity
Every symptom on this page lands in one of four severity bands, and the band — not the symptom's name — decides the response. A "RAW" that's a fresh disk you mis-partitioned and a "RAW" that's a five-year-old photo drive are the same word and completely different emergencies. The bands below are the page's decision scale.
| Severity | What it looks like | What to do |
|---|---|---|
| Informational | SMART clean, slow within the drive's class, one-off errors that don't repeat | Note it, keep backups current, recheck in a few weeks |
| Investigate soon | One new sign: a small reallocation rise, a new noise, a speed drop, a letter lost | Run the matching diagnosis from this page; snapshot SMART for the trend |
| Back up immediately | Multiple or worsening signs: rising sectors, growing corruption, freezes on access, RAW on an old disk | Copy and verify the data now; plan the replacement; keep the drive off heavy duty |
| Stop troubleshooting | Mechanical sounds, read-only SSD, sectors dropping faster than you can copy | Power off; preserve (professional recovery or one careful image); replace |
The SMART attributes that carry the diagnosis, by drive type — the short version of topic 69, as a reference table:
| Attribute (type) | What it measures | What to watch |
|---|---|---|
| Reallocated Sector Count (HDD) | Sectors moved to the spare pool | Any rising trend — not the absolute count |
| Current Pending Sector Count (HDD) | Sectors being retried right now | Any non-zero value |
| Spin Retry Count (HDD) | Motor/head retries at startup | Any rising trend — mechanical trouble |
| Media Error Count (SSD) | Uncorrectable NAND errors | Any non-zero, especially climbing |
| Percentage Used / wear (SSD) | Wear against rated life | 80–90%+ → start the replacement plan |
Know your drive
HDD vs SSD: why the failures look different
Half the confusion in storage troubleshooting comes from applying one drive type's intuition to the other — waiting for a sound from an SSD, or expecting an SSD to stutter the way a platter does. The table is the quick reference; the two columns are the two different animals this page keeps diagnosing.
| HDD | SSD | |
|---|---|---|
| Storage medium | Spinning platters, moving read/write heads | NAND flash cells, no moving parts |
| Noise | Audible — seek, spin, and failure sounds | Silent — failure is invisible by sound |
| Typical sequential speed | 100–200 MB/s | ~500 (SATA) to 7000+ (NVMe) MB/s |
| Random access | Mechanical seek — milliseconds | Electronic — microseconds |
| Failure style | Usually gradual and audible; sector-based | Often sudden and silent; cell/wear-based |
| Bad-sector behavior | Retry stutters, reallocated spares | Wear leveling, media error counters |
| Heat | Moderate; heat accelerates wear | Runs hotter; throttles when it gets too hot |
| SMART focus | Reallocated/pending sectors, spin retries | Media errors, % used, TBW |
| Defragmentation | Yes — it helps layout | Never — pure wear; TRIM instead |
| Recovery consideration | Clicking drive → stop; professional recovery | Read-only lock or total loss → stop; data can go faster |
The one row that matters most is the failure-style row, because it explains the two different disciplines this page teaches: with an HDD, listen and watch for the gradual — the sounds and the stutters are the warning system, and they're usually generous. With an SSD, watch the counters — there's no warning system you can perceive, the SMART attributes are the entire early-warning infrastructure, and the drive can be healthy one week and read-only the next. Same symptoms from the user's chair ("it's slow," "it's gone"), two different monitoring strategies, and the strategy is chosen by the drive, not by preference.
Work through it
Troubleshooting safety checklist
The discipline of the whole page, as tickable items — the checks that separate a careful diagnosis from a data incident. Your progress is saved in this browser, so you can work through it across sessions.
The stop rule, in full
When to stop troubleshooting
Topic 72 gives the decision framework; this section states the rule plainly, because it's the one that saves data. Troubleshooting is a series of tests, and every test has two costs: the time it takes, and the stress it puts on the drive. On a healthy drive the second cost is zero and you test freely. On a failing drive the second cost is real — scans stress weak media, power cycles stress failing mechanics, and writes endanger the data you're trying to save — so the correct question isn't "what's the next test?" but "does this test cost more than it tells me?"
The conditions where the answer is no, and you stop: mechanical sounds of any kind — the drive is a physical problem and every power-on is damage. Irreplaceable data plus any media-failure sign — the risk of another attempt now exceeds its information value. A drive degrading faster than you can copy it — the race is decided by the media, and you can't out-copy a platter that's dropping sectors. And the honest money case — where professional recovery costs more than the data is worth, in which case the drive is a replacement and grief is the appropriate response for a week. Stopping is not giving up; it's the point where the method correctly ends and preservation takes over. The page's entire safety architecture exists so that you can stop on purpose, at the right moment, with the data still saveable — rather than stopping by accident, at the wrong moment, when the drive decides for you.
When the data is the problem
Data recovery considerations
"Recovery" means two very different things at two different stages, and confusing them is how people lose data they could have kept. The first is preservation: getting the data off a drive that's still working — a backup, a copy, a disk image. This is cheap, fast, available to everyone, and it should have happened before the problem did; when it hasn't, it's still the first move, while the drive cooperates. The second is recovery in the trade sense: extracting data from a drive that no longer cooperates — failed controllers, damaged platters, dead NAND — which is a specialized service with clean rooms, donor parts, and pricing to match.
The decision between them runs on three questions. Is the drive still readable — does it mount, can you copy from it, can you make an image? If yes, the answer is preservation, at home, today: copy the important files and make a full image (the image is what a recovery tool or a partition rebuild works from, and it's what makes every later step safe). If the drive won't mount but is electrically alive, a careful image attempt — one pass, no repeated intensive scans — is still reasonable, with the expectation that the window is temporary. If the drive is mechanically failing (sounds, won't spin up, read-only lock), home attempts stop being reasonable and the trade sense of recovery is the only path left — and it's worth it only in proportion to what the data is worth. The through-line: the earlier you act, the cheaper the option set, and the one action that's available at every stage, on every drive, in every state, is the copy made while the drive still answers.
Make the next one survivable
Prevention and backup guidance
Every drive fails eventually — it's a mechanical or electronic part with a finite life, and "prevention" of failure is a myth. What you can prevent is the data loss that failure causes, and that's a solvable problem with a short answer and a few supporting habits. The short answer: the 3-2-1 rule — three copies of anything irreplaceable, on two different media, with one copy off-site (a cloud service, another machine, another building). A drive dying with 3-2-1 in place is an inconvenience; the same drive dying without it is an event you remember for years.
The supporting habits, each of which this page's topics connect to a specific failure mode. Check SMART monthly on drives holding irreplaceable data — a two-minute read that turns a silent failure into an early one. Keep 10–20% free on SSDs, so the performance and endurance tax never starts. Use decent cables on the boring connections — the SATA and USB cables are where the cheapest failures live. Protect against power events (a surge protector at minimum, and never yank a powered drive). Snapshot the health counters now, so next year's reading has a baseline to compare against. And set a replacement expectation: a drive that's five-plus years old, or past its rated TBW, or showing any trend on SMART is a drive on a replacement timeline, not a drive to keep diagnosing. None of this is dramatic. All of it is the difference between the two endings this page keeps describing.
FAQ
Storage questions, answered
My drive isn't showing up — what should I check first?
Work from the bottom up: does BIOS/UEFI see it? Does Disk Management? The layer where it stops appearing tells you whether the problem is physical (power, cable, port), the controller (AHCI/RAID, drivers), or the partition layer (letter, offline, unallocated). Start with the two swaps that clear most cases — a known-good cable and a different port — before suspecting the drive.
Does a clicking hard drive mean the data is gone?
Not necessarily, but it means stop. Clicking is usually the head assembly failing to lock onto the platter, and each power cycle makes it worse. If the data matters, the move is preservation — professional recovery, or a careful image if the drive still occasionally mounts — not more troubleshooting. If the data is backed up, the drive is a replacement.
Can I fix a RAW drive without losing data?
Sometimes. RAW means the filesystem layer is unreadable, and if the damage is a few corrupted structures on a healthy disk, a careful read-only diagnosis followed by a repair can save the data. If the drive is also showing media failure (SMART errors, noises), no software fix is safe — the data path is imaging or professional recovery. The one action that's always wrong on a RAW drive with data is clicking Format.
Should I run chkdsk on a failing drive?
Be careful with the mode. A read-only scan (/scan) only reads and is a reasonable diagnostic. Repair modes (/f, /r) write to the drive, which on a physically failing drive is a risk: intensive reads can stress weak media, and writes can overwrite data you haven't saved yet. If the drive is making noises or SMART is climbing, back up first and run scans on a copy, not the original.
How full is too full for an SSD?
Keep roughly 10–20% free. SSDs need spare and free blocks to wear-level and to keep write performance; as a drive approaches 100% full, writes slow down and endurance math gets worse. If your drive is near full, freeing space (plus a TRIM, which Windows normally runs automatically) usually restores the speed.
Will defragmenting fix a slow SSD?
No — and don't defragment an SSD at all. Defragmentation is a write workload, and on an SSD it consumes finite write endurance for zero performance benefit; SSDs use TRIM instead, which Windows runs automatically. If your SSD is slow, check free space, TRIM state, firmware, temperature, and health — not fragmentation.
How often should I check SMART?
For a drive with data you care about, a monthly glance at the key attributes is cheap insurance: on HDDs, reallocated and pending sector counts; on SSDs, media errors and the percentage-used wear counter. The trend matters more than any single reading — a stable non-zero count on an old drive is history, a rising count is an emergency.
When is professional data recovery worth it?
When the data is irreplaceable and the drive is failing at the physical layer — mechanical sounds (clicking, grinding), a drive that won't complete spin-up, or media damage that home tools can't image. Professional labs have clean environments, donor parts, and the tools a failing drive needs. When the data is backed up or replaceable, recovery isn't worth it and the drive is a replacement — the decision is about the data, not the drive.