A retailer’s Seagate Expansion portable drive started launching Windows’ CHKDSK the moment it was plugged in, then handed back folders full of missing and scrambled files. That behaviour is NTFS flying a distress flag — a volume marked ‘dirty’ over a damaged Master File Table and a scatter of unreadable sectors. Left to run, CHKDSK would have made it worse. We stopped it, imaged the drive with bad-sector handling, and rebuilt the file system from the copy.
A high-street retailer relied on a single Seagate Expansion portable drive for point-of-sale exports, stock spreadsheets and year-to-date accounts. One morning Windows began running CHKDSK automatically every time the drive was connected — scrolling through a repair pass, ‘fixing’ entries, and then either failing part-way or finishing to reveal folders that were half-empty, full of zero-byte files, or renamed to strings like FILE0001.CHK. The drive still spun and still appeared in Windows, which made it tempting to keep replugging it and let CHKDSK ‘sort itself out’. That instinct is exactly what turns a recoverable drive into a lost one, so it was unplugged and sent to us instead.
Every NTFS volume carries a flag in its boot sector called the dirty bit. Windows sets it whenever it starts writing to the volume and clears it once everything has been flushed and the file system is consistent. If the drive is unplugged mid-write, hits a run of bad sectors, or the metadata stops adding up, the bit is left set. On the next connection Windows sees a volume that was never marked clean and schedules CHKDSK to repair it. So CHKDSK launching on every plug-in isn’t the problem — it’s the symptom. Something underneath, on this drive a damaged file-system index sitting over failing sectors, is preventing the volume from ever being marked clean again.
CHKDSK was built to make a file system internally consistent again so Windows can use the volume — not to preserve your data. On a drive that is physically failing, those two goals pull in opposite directions, for three reasons:
It writes to a drive that should be resting. CHKDSK repairs in place, writing corrections directly onto the struggling disk. Every write forces the heads back over weak, failing areas that ideally should be read once, gently, and never touched again. On a drive with a developing mechanical or media fault, that extra work can tip it from ‘slow and readable’ into ‘clicking and dead’.
It discards what it can’t resolve. When CHKDSK meets a directory entry or index record it can’t reconcile, it doesn’t recover it — it removes it. Cross-linked files get truncated, orphaned fragments are dumped into a found.000 folder as anonymous .CHK files stripped of their names and folders, and unreadable records are simply deleted. That is why a ‘repaired’ volume so often comes back emptier than before.
It overwrites the evidence. Recovery depends on the surviving copies of the file-system structures. CHKDSK edits those very structures as it goes, so each pass overwrites some of the exact metadata a proper recovery would have used to rebuild your files intact.
When the drive reached our lab, a controlled read-only inspection showed two faults layered on top of each other. First, the Master File Table (MFT) was damaged. On NTFS the MFT is the central index — one record per file and folder, holding the name, timestamps, permissions and, crucially, the map of which sectors hold the file’s data. Corrupt the MFT and the data can still be sitting on the platters while Windows has no idea where any of it is. Second, there were bad sectors clustered in the MFT’s region and across several data areas — the underlying media faults that had left the volume dirty in the first place and set the whole CHKDSK cycle going. NTFS keeps a partial backup of the MFT called $MFTMirr, and a transaction log ($LogFile) — both would matter for the rebuild.
The single most important step was to take a complete image of the drive before attempting any repair, and to do it in a way that asked the failing media for as little as possible. Working through a hardware imager with the source behind a write blocker, we cloned the drive sector by sector to a healthy disk, with the imager configured for damaged media: read retries capped low so a bad sector is skipped quickly rather than hammered, the healthy bulk of the drive read first to secure it, and the weak zones approached afterwards in smaller passes — including reading in reverse across stubborn regions — to coax out the maximum without stalling the heads on any one sector. Unreadable sectors were logged and padded so the image stayed aligned. From that point on the original drive was set aside untouched, and every further step happened on the clone — so nothing we did could cost more data, and the failing drive was never stressed by the recovery itself.
With a stable image in hand, the file system was rebuilt from the copy rather than ‘repaired’ on the original. Where the primary MFT was damaged, records were recovered from the $MFTMirr backup and by parsing the raw MFT area directly, pulling intact file records — complete with their original names, folders and data maps — out of the areas CHKDSK had not yet reached. For files whose MFT records were genuinely gone, we fell back on signature carving: scanning the imaged data for the distinctive headers and structures of the formats that mattered here — Excel and CSV exports, PDFs, Word documents, and the point-of-sale database files — and reassembling them straight from their contents, independent of the file system. The two approaches complement each other: the MFT rebuild restores names and structure, and carving catches whatever the index could no longer account for.
Recovered spreadsheets were opened and totals sampled, PDFs and documents were checked to confirm they rendered in full, and the database exports were validated against expected record counts before anything was signed off. The complete set was written to a fresh drive and returned. We made the same point we make to everyone who has trusted a single external drive: it is a convenience, not a backup. A second copy — another drive plus an offsite or cloud copy — is what would have turned this from a four-day recovery into a five-minute restore. And if a drive ever forces CHKDSK on you, the safest thing you can do is cancel it, unplug the drive, and copy nothing more to it until the data is safe.
Hardware imager with write blocker and damaged-media profile (retry-limited, reverse-read passes) · NTFS MFT and $MFTMirr reconstruction · $LogFile analysis · signature-based carving for Office, PDF and database formats. Read-only imaging, all work in-house at our Belfast lab.
Cancel the check, unplug the drive, and send it to us for a free, no-obligation diagnostic. We’ll tell you what can be recovered and put a fixed price in writing before any work starts — and on most jobs, if we can’t get your data back, there’s nothing to pay. Post it in from anywhere in the UK, or drop it to us in Belfast.
If the files on it matter and you don’t have another copy, no. CHKDSK repairs the file system by writing to a drive that is already struggling, and it deletes or truncates anything it can’t resolve rather than recovering it. Cancel the scan, unplug the drive, and get a diagnostic first — you can always run CHKDSK later once the data is safely off.
Often not. The .CHK files in a found.000 folder are your data with the names stripped off, and much of it can be identified and rebuilt by its contents. Anything CHKDSK deleted outright frequently still exists on the disk until it’s overwritten. Stop using the drive and a recovery can usually reunite a large part of it with its original names and folders.
Possibly. A volume that keeps going dirty and triggering CHKDSK is usually sitting on bad sectors or a failing head, even while it still mounts. Continuing to use it — and letting Windows repair it in place — is what commonly turns a still-readable drive into one that clicks and won’t mount at all. Imaging it once, gently, is far safer than working it.