Windows data loss rarely announces itself the same way twice. A workstation blue-screens with INACCESSIBLE_BOOT_DEVICE and never comes back. An external drive that held the company’s project archive suddenly shows in Explorer as RAW and Windows offers — helpfully, catastrophically — to format it. A file server’s D: volume throws “the file or directory is corrupted and unreadable” on every third folder. A laptop reports “boot device not found” after a fall. Or a Hyper-V host loses its storage and takes eleven guest VMs down with it.

Every one of those is a Windows data recovery case, and they route to very different kinds of work. This page is the hub for all of it: the NTFS and ReFS filesystems that hold Windows data, the error messages Windows shows when storage fails, and the server-side workloads — Hyper-V, Exchange — that turn a single volume failure into an organizational problem.

One thing to say plainly up front, because most people searching “Windows data recovery” find pages selling software: this is not a software page. Gillware is a data recovery laboratory. Recovery software has a legitimate place — a healthy drive with a recently deleted file is a fine software case — but software cannot fix a drive that clicks, reads slowly, drops off the bus, or returns errors. Running recovery software against failing hardware makes outcomes worse, because every hour of scanning is an hour of stress on a drive that may have limited hours left. Our work starts where software stops: physical drive failures, corrupted filesystem metadata that tools misinterpret, and the enterprise cases — servers, arrays, virtual machines — where the storage stack is too layered for a consumer tool to reason about. We’ve been doing this for more than two decades, in an ISO 5 Class 100 cleanroom in Madison, Wisconsin.

The two filesystems that hold Windows data

Almost every Windows recovery is ultimately a filesystem recovery, and Windows has two that matter.

NTFS data recovery — NTFS has been the Windows filesystem since 2001 and runs on effectively every Windows boot volume, every internal data drive, and the overwhelming majority of external drives that ship pre-formatted for Windows. Its central structure — the Master File Table — is both the reason NTFS recoveries are often highly successful and the single point whose corruption produces the most alarming symptoms: RAW drives, empty folders, “corrupted and unreadable” errors, files with correct names but zeroed contents. Our deep-dive covers how the MFT actually works, what deletion really changes, why chkdsk is sometimes the worst thing you can run, and how our lab reconstructs NTFS volumes when the metadata is damaged.

ReFS data recovery — the Resilient File System is Microsoft’s newer, checksummed, copy-on-write filesystem. You’ll find it on Windows Server Storage Spaces deployments, Hyper-V cluster shared volumes, Exchange database volumes, backup repositories (Veeam explicitly recommends it), and — since the Dev Drive feature — a growing number of Windows 11 workstations. ReFS fails differently from NTFS: there is no chkdsk equivalent, volumes appear as RAW after Windows version mismatches, and the recovery tooling ecosystem is far thinner. Our page covers where ReFS shows up, its distinctive failure patterns, and what recovery looks like on a filesystem most tools don’t understand.

The error messages: what Windows says when storage fails

Windows communicates storage failure through a vocabulary of error messages, BSOD stop codes, and OEM diagnostic codes — and each one narrows down what’s actually wrong. “Boot device not found” points at a different failure than “BOOTMGR is corrupt,” which points at a different failure than error 0xc0000185. A Dell error code 2000-0142 means the drive failed its self-test; a Lenovo error 1962 means the firmware can’t find anything bootable at all.

We maintain a dedicated page for each of the major errors, built around what the error actually means, what’s happening at the hardware or filesystem layer, and what to do — and not do — when the data on the machine matters. The Windows error message hub organizes all of them by symptom: machine won’t boot, drive not showing up, drive shows but won’t open, and errors during file operations. If you’re staring at a specific error right now, start there.

Encryption: BitLocker and the recovery-key question

An increasing fraction of Windows drives arriving at our lab are encrypted, most often with BitLocker — enabled explicitly on Pro, Enterprise, and Education editions, or enabled automatically as Device Encryption on modern Windows 11 devices set up with a Microsoft account. Encryption changes the recovery picture in one specific way: the recovery key becomes as important as the drive itself. With a key, a failing BitLocker drive recovers essentially the same as any failing NTFS drive — image the drive, decrypt block-by-block against the key, and extract from the resulting volume. Without a key, the AES ciphertext is cryptographically final, and no legitimate lab can recover the contents regardless of what services claiming otherwise advertise.

The important thing to know is that the key is present in eight cases out of ten. It just isn’t always in the place the owner remembers — often it’s in the Microsoft account of the person who first signed the machine in, which may be a spouse, family member, or predecessor rather than the current owner. Our BitLocker data recovery page walks through the six places to look for the key, the BitLocker key hierarchy (protectors → VMK → FVEK) that determines which unlock paths are still available, and the failure scenarios where BitLocker interacts with a physically damaged drive, an unexpected recovery screen after a firmware update, or a dead machine with a TPM-bound SSD. If you’re staring at a 48-digit recovery prompt right now, start there.

Windows Server, Hyper-V, and Exchange

The server side of Windows recovery is its own discipline, because the failure is almost never just a filesystem — it’s a filesystem with a workload on top whose internal consistency matters as much as the files themselves.

Hyper-V recovery — when a Hyper-V host’s storage fails, every guest VM is a filesystem-within-a-file. VHDX containers have their own internal block allocation tables, their own log, and their own corruption modes — separate from whatever happened to the NTFS or ReFS volume underneath, and separate again from the guest OS filesystem inside the container. Recovery is a three-layer problem, and checkpoints (AVHDX differencing chains) add a fourth: a checkpoint chain broken by a well-intended file cleanup is one of the most common self-inflicted Hyper-V disasters we see.

Exchange Server recovery — on-premises Exchange stores everything in EDB databases with strict transactional consistency requirements. A dirty shutdown, a lost transaction log sequence, or a volume failure mid-write produces a database that Exchange refuses to mount — and the difference between a clean recovery and a mailbox-by-mailbox salvage operation is usually determined by what gets run against the database in the first hours after the failure.

The engagement model for server-side cases is the same one we use across all complex work: free initial consultation, and terms agreed in writing before any work begins.

Where we see Windows data loss in the lab

In rough order of frequency across our Windows caseload:

• Failed laptop and desktop drives — mechanical hard drive failures (clicking, not spinning, not detected) and SSD controller failures on consumer machines. The machine reports “boot device not found,” a 3F0 error, error 1962, or simply a black screen. The recovery is hardware-first: the drive comes out, gets repaired to imaging condition in the cleanroom, and the NTFS volume is extracted from the image.
• External drives dropped, failed, or corrupted — the WD My Passport that fell off the desk, the Seagate expansion drive that started asking to be formatted, the easystore that vanished from Explorer mid-copy. These blend hardware failure with NTFS corruption in every combination.
• RAW volumes and filesystem corruption — the drive is healthy but Windows can’t read the volume: RAW filesystem prompts, “corrupted and unreadable,” empty folders, chkdsk runs that made things worse. Pure metadata reconstruction work.
• Windows Server storage failures — RAID arrays that dropped members, Storage Spaces pools that won’t attach, and the Hyper-V and Exchange workloads on top of them.
• Deleted files and formatted volumes — the quick-format that hit the wrong drive, the user profile deleted during a repair, the “reset this PC” that removed more than expected.
• BitLocker complications — any of the above, plus encryption. Recoverable when the recovery key exists; cryptographically final when it doesn’t. Worth checking your Microsoft account for stored keys before assuming the worst.
• The SQL Server database goes into Recovery Pending, Suspect, or Emergency mode after underlying storage failure. DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS reports irreparable corruption. See our SQL Server data recovery page.
• A Storage Spaces pool goes read-only after a drive is pulled without being marked Retired. A virtual disk detaches after the journal SSD fails. An S2D cluster refuses to accept drives from a rebuilt node. See our Storage Spaces data recovery page.

What to do right now if data is on the line

• Stop using the affected drive or machine. Every boot attempt spins failing hardware; every write to a corrupted volume overwrites potential recovery targets.
• Don’t run chkdsk yet. On a healthy volume with minor inconsistencies, chkdsk is fine. On a badly corrupted volume or failing drive, chkdsk “repairs” by discarding what it can’t reconcile — and its repairs are not reversible. The NTFS page covers this in depth.
• Don’t format, even when Windows offers. The “you need to format the disk before you can use it” prompt is Windows failing to read the volume, not advice worth taking.
• Don’t run recovery software against a drive making noises or performing slowly. Hardware symptoms mean imaging comes first, on equipment built for failing drives.
• Note the exact error text or stop code. It meaningfully narrows the diagnosis before the hardware arrives.
• Call us or start a case. The consultation is free, and we’ll tell you honestly whether your situation is a software case, a lab case, or not recoverable at all.

How the engagement works

Single-drive Windows recoveries — the failed laptop drive, the dropped external, the RAW USB drive — fit our standard risk-free model: free evaluation, flat-rate quote in writing before any work begins, payment only on successful recovery.

Complex Windows cases — multi-drive server arrays, Storage Spaces pools, Hyper-V hosts with multiple guests, Exchange databases with broken log sequences — can involve engineering hours that aren’t predictable in advance. On those, the engagement is the same structure we use across all complex work: free initial consultation, an evaluation phase that may be free or fixed-price depending on what imaging requires, and any engineering charges explained clearly and in writing before work begins. You decide whether to proceed. No surprise billing.