An interrupted write
Power loss or a forced shutdown while NTFS was updating the MFT. The commonest cause on otherwise healthy hardware, and usually confined to whatever was being written.
Common
Unlike most Windows messages, this one is precise: a record in the master file table cannot be read. Understanding what that record is explains both why a single file vanished and why an entire folder tree can go with it.
Each segment is a one-kilobyte record covering a single file. A handful of unreadable ones is a local defect. Hundreds means the region holding the table itself is going, which is a different conversation.
The technical detail that makes everything else on this page make sense.
NTFS keeps a master file table — a database with one record for every file and folder on the volume, each typically 1KB. That record holds the name, the timestamps, the permissions, and a list of which clusters on the disk contain the contents.
For small files, NTFS does something neater: if the data fits inside the record itself, it is stored there rather than allocated separate clusters. A short text file may exist entirely within its own MFT record. That is efficient, and it means damage to the record destroys the file outright rather than merely losing the pointer to it.
For everything larger, the record holds pointers — so the record failing leaves the contents intact and unreachable. Which of those two situations you are in depends on file size, and it explains why some affected files recover perfectly and others do not.
The structural reason a small amount of damage produces a large amount of loss.
A directory in NTFS is a file whose contents are an index of what it holds — stored as a B-tree for fast lookup. It has its own MFT record like anything else.
So a single unreadable record belonging to a directory removes the index of everything beneath it. The files themselves are untouched, their own records may be perfectly intact, and there is no longer anything connecting them to a path. Windows reports the folder as unreadable and everything inside it disappears from view.
That is recoverable, and it is why recovery software often returns your files with correct contents but no folder structure — the records survived and the index tying them together did not.
Power loss or a forced shutdown while NTFS was updating the MFT. The commonest cause on otherwise healthy hardware, and usually confined to whatever was being written.
The table occupies a specific region, and sectors failing there produce this error while the rest of the disk reads perfectly. Position matters more than quantity.
Corruption introduced in transit rather than on the platter. Worth eliminating with a cable swap before assuming disk damage.
If new files start reporting the same error over days or weeks, the drive is deteriorating rather than damaged. Stop and copy.
The specific behaviour that matters with this error.
chkdsk exists to produce a consistent file system. Finding an MFT record it cannot read, it does not attempt to reconstruct what the record said — it removes the entry and marks the associated clusters free. The volume afterwards is coherent, which is exactly what it was asked for.
On a healthy drive after one interrupted write, that is a genuine fix and the file was already broken. Where bad sectors sit under the MFT, chkdsk can walk through the damaged region discarding record after record — each one a file or folder that could have been rebuilt from surviving structure.
NTFS keeps a partial mirror of the MFT’s first records, and file records carry recognisable signatures that allow them to be located directly in an image even when the table itself is damaged. A recovery works from those rather than by deleting anything, against a read-only copy. Single drives in Manchester are from £300 +VAT after a free 48-hour diagnostic.
That NTFS could not read a record in its master file table — the database holding one entry per file, containing the name, timestamps and a list of which clusters hold the contents. The record failed, not necessarily the file.
Because a directory is itself a file whose contents are an index of what it holds. One unreadable record belonging to a directory removes the index of everything beneath it — the files remain intact with nothing connecting them to a path.
Usually. For anything but very small files the record holds pointers rather than data, so the contents are intact and merely unreachable. Very small files stored inside their own record are the exception, and those are lost with it.
Only after checking SMART and copying off what you can. chkdsk removes records it cannot reconcile rather than reconstructing them — a genuine fix on healthy hardware, and destructive where bad sectors sit under the MFT.
Because the individual file records survived and the directory index tying them together did not. The contents come back correctly; the arrangement has to be rebuilt separately, and is not always possible.
Watch whether it spreads. One affected folder after a power cut is an event. The same error appearing on new files over days or weeks means the disk is deteriorating — check reallocated and pending sector counts.