“File record segment is unreadable” is a CHKDSK warning about an NTFS record it could not read. It does not identify a specific document for you, and one message cannot prove that the entire drive is physically failing. Multiple unreadable records, freezes, or repeated I/O errors are much more concerning. Before another scan or repair pass, protect the files you can still access and note whether the device remains stable. A repair report is not a replacement for a usable backup.
Translate the CHKDSK line into plain language
NTFS keeps information about files in the Master File Table, or MFT. Microsoft’s MFT developer documentation explains that it contains file record segments used to describe files. A segment may hold or point to attributes needed to locate a file. When CHKDSK says a particular segment is unreadable, it is reporting trouble obtaining that record during the check.
The number following the message identifies a record segment within NTFS. It is not a drive letter, a sector address to repair manually, or a filename you can search directly in File Explorer. Do not assume that “segment 12345” means exactly one document is lost. File-system structures can be interconnected, and the readable data may not match the number of warnings one to one.
Record the complete CHKDSK command, the volume it targeted, and surrounding messages. A status check, a repair run with /f, and a deeper read pass with /r do different work. If you used a command copied from a forum, confirm that the drive letter actually belonged to the intended source. The report makes sense only in the context of the device and the options used.
Separate one unreadable record from an unstable drive
Ask how the device behaved before and during CHKDSK. Did files open normally yesterday? Is this an external disk that was unplugged while writing? Does the scan keep finding new unreadable segments? Is the drive clicking, disconnecting, or taking a very long time to list directories? These observations matter more than a single code line.
One reported record on a drive that remains stable may reflect a localized logical or read problem. It still deserves a backup and follow-up. Many unreadable records accompanied by slow or failed reads raise concern about the underlying media. On an HDD, mechanical symptoms make further full-surface scanning particularly risky. On an SSD, repeated errors or a disappearing device also require caution, even though there may be no noise.
Do not keep launching CHKDSK until the output looks clean. A repair operation can change file-system metadata, and a deeper pass reads more of the medium. If the only copy of valuable files is on that drive, preserve it first. If the disk is physically unstable, a professional image or specialist service may be safer than both repair and ordinary recovery software.
The broader guide to hard-disk bad sectors explains storage-health clues. This article addresses a narrower question: how to interpret the NTFS file-record message and decide what to do with your files before another operation.
Save what still opens while the source is readable
If Windows can browse the volume, make a priority list. Copy current work, family photos, financial documents, and other files without a verified second copy to a different healthy disk. Start with small critical folders rather than launching a massive backup that could stall on one unreadable area. After each group, open sample copies at the destination and check their contents.
If a specific file will not copy, note its path and the exact error. Continue with other accessible files if the drive remains steady, but do not repeatedly force the same failed read. A copying tool that retries indefinitely may place needless stress on weak media. If many folders are failing or the device drops offline, stop and ask about imaging or professional recovery.
Check existing backups as well. A cloud service may hold an earlier version even if the latest local edit was not synced. Open files from the backup to verify them. A backup directory listing is not enough: the file may be incomplete or the wrong version. Keep the original disk unchanged until you know which important materials are safe elsewhere.
Use recovery software only if the source is stable
When folders or files are missing but the physical drive is consistently detected at the correct size, a file-recovery scan may find candidates before any further file-system repair. Drecov is Windows recovery software for recognized HDDs, SSDs, external drives, USB media, and other supported storage. Quick Scan, Deep Scan, filters, and preview help identify likely documents or photos. Results are saved to another healthy destination, not to the damaged source. The file-recovery workflow is relevant to a stable NTFS volume with missing files. Drecov does not repair unreadable physical sectors, reconstruct every damaged NTFS record, or guarantee retrieval of overwritten data.
Prepare a destination with enough free space and install the software away from the affected partition. If Windows itself will not boot, the stable source needs a suitable working Windows environment or a safe connection to another PC before scanning. If the disk clicks, repeatedly disconnects, or reports the wrong size, do not keep asking software to read it. Controlled imaging or a professional assessment is the safer branch.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
Step 1: Open Drecov and choose the original NTFS source
Select the affected disk or partition by size and label. Its letter may change when attached to another PC. If the CHKDSK command targeted D:, confirm that D: really referred to this physical source before choosing it. The healthy output drive is not the scan target.
Step 2: Start Quick Scan and check known folders
Look for the directories that held the missing documents. Search a few distinctive filenames and file types. A long result list cannot tell you whether the needed version is intact. Stop the scan if the drive becomes unstable.
Step 3: Broaden the search only if reading stays reliable
Run Deep Scan when Quick Scan does not locate essential files and the source has remained stable. Deep Scan may reveal additional candidates, but it reads more of the disk. New I/O errors, timeouts, or disconnections are reasons to stop and reconsider the recovery method.
Step 4: Filter and preview representative candidates
Use former path, name, and file type to narrow the selection. Preview supported files and compare them with the work you expect. One previewed page cannot prove an entire document, archive, or linked project is complete. Recover related files together if an application depends on them.
Step 5: Save elsewhere, then open the recovered files
Export to the separate healthy drive. If the output is not visible in the folder you selected, check that destination’s Drecov Folder or Recovery Folder. Open several recovered files in their normal programs, compare contents and dates, and make another backup. Only then decide whether a write-based repair is appropriate.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
What a later repair result can and cannot tell you
After data protection, a CHKDSK repair on a stable drive may address some logical inconsistencies. Read the final report and note whether file-record warnings return. A report that says errors were fixed does not certify the physical drive or every document. Open critical files and monitor for additional read failures. Recurrent problems may justify replacing the source rather than trusting another repair.
Do not use CHKDSK as a physical-drive endurance test. A storage diagnostic from the device manufacturer may help assess health, but it is not a backup and should be selected with awareness of its read load. If the drive is deteriorating, an image taken under controlled conditions is often the priority. Replace a suspect device after recovering data rather than storing new sole copies on it.
For the broader process of recovering lost NTFS files, a separate guide covers deletion scenarios where CHKDSK has not reported an unreadable record. Keep the search tasks distinct: deleting a file and failing to read an MFT record are not the same event.
Questions prompted by the segment number
Can I look up which filename matches the number?
Not reliably from the line alone. The number is an NTFS record reference, not a friendly filename. Focus on protecting accessible files and examining actual missing folders rather than guessing a one-to-one mapping.
Does one unreadable segment mean the whole drive is failing?
Not necessarily. It does require caution and a verified backup. Multiple reports, worsening read behavior, a changing capacity, or a disappearing drive increase concern about media health.
Should I rerun CHKDSK with /r?
Not before protecting important files and assessing the drive. That option involves extensive reading and includes repair behavior. On an unstable source, more reads may be counterproductive.
Can a recovered file still be damaged?
Yes. A candidate file may be incomplete or have corrupt content. Preview samples where possible, recover to another drive, and open the exported files to verify them. Some projects also need linked assets from nearby folders.
Will Drecov repair the MFT entry?
No. It searches for recoverable files on a suitable stable source and exports them. In-place NTFS repair and physical-drive service are separate tasks.
Conclusion
“File record segment is unreadable” identifies an NTFS record CHKDSK could not read, not the exact fate of every file. Save accessible content, assess whether the disk remains stable, and avoid repeated repair passes before a verified backup. On a consistently recognized source, Drecov can search for missing files and export candidates to another healthy drive for testing. If unreadable records multiply alongside hardware symptoms, stop software scans and seek specialist guidance.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
