Hard disk ‘repair’ software like Spinrite, DiskPatch or the hard disk manufacturer diagnostic software often identifies bad sectors in the form of an LBA address (logical block addressing). A commonly asked question is, “how do I determine, which file is affected by a bad sector?”.
What is bad sector repair?
Bad sector repair utilities do not actually repair bad sectors and often the original data in the sector is lost.
Hard disks have a pool of ‘spare’ sectors. If a bad sector develops it can be taken out of service and replaced by one from the spare pool. Using a S.M.A.R.T. utility you can observe and how many sectors have been reallocated this way. The disk all handles this internally:
Assume the sector at LBA address 100 can not be read and is reallocated. From this moment on, all reads and writes to LBA address 100 are redirected to the spare sector that was assigned to this address.
Hard disk repair software scans the disk, allowing the disk to discover bad sectors. When ‘hitting’ a bad sector the disk will add the LBA address of the sector to the ‘pending reallocation’ list. The disk will not yet reallocate the sector because once it has done that, no attempts can be made to get the data from the sector. So the disk does not make that decision. By writing data to the sector you can signal to the disk that the data is given up on.
Which file is affected by a bad sector, if any?
As this hard disk repair software runs in an out of Windows environment (DOS mostly) and does address the physical disk rather than a logical volume, it has no way of telling if, and if so, which files are affected by the repairs. There are several possible effects if bad sectors were repaired, depending on what was actually in the sectors.: Were they part of
- empty, unallocated space
- file system structures
- system files
- user files
As reallocation of sectors that aren’t in use by any file system or files does not result in data loss, we can ignore this.
File System Structures
If the file system itself is affected by bad sectors, the first tool that comes to mind to address those is Chkdsk.exe. Of course Chkdsk scans at the cluster level rather than the sector level. A sector is the smallest addressable unit on hard disk. A cluster is the smallest addressable unit in a file system. It’s how the file system organizes data. A cluster is usually several sectors in size.
If chkdsk runs into read problems while scanning clusters it will:
- Determine if a file is affected and if so, try to recover the data from the cluster(s).
- Add the cluster(s) to the $BADCLUS table where it basically marks the cluster as bad so it will not be used again. This not the same as the disk itself reallocating bad sectors! As far as the disk concerns, the bad sectors still exist. The cluster is marked ‘bad’ at the file system level.
Addressing issues that may occur after sector reallocation on the file system level:
If we’d run a disk repair utility *after* chkdsk, and let it repair (read: reallocate) bad sectors, the $BADCLUS file would need to be updated. After all, the clusters that were marked bad no longer contain bad sectors.
You can then use Chkdsk to re-evaluate the bad clusters by specifying /B switch, so chkdsk /b [enter].
Theoretically bad sectors in the first $MFT entries can be overcome by using the $MFTMIRR which backs up the first 4 records of the MFT. I am not sure how Chkdsk handles this however, I have never seen it happen.
A corrupt boot sector, which technically is a file as far as NTFS is concerned, could be addressed by using the backup boot sector (which is technically NOT a file, nor part of the file system). Typically Chkdsk will mention the file system is RAW and will refuse repairs. A utility like DiskPatch [Fix NTFS boot sector] can copy the backup boot sector to the boot sector, or it can even rebuild a boot sector from scratch.
Minor file system damage can be fixed using Chkdsk.
System Files (Windows)
Windows includes a system file checker (SFC.exe) that can be used to verify system files after sector reallocation. More info here. You can use it to verify if any system files were affected (corrupted) and repair them.
This is probably the most worrying problem. Corrupt data may be even worse than no data at all After all, a few corrupt bits may render all data useless while this isn’t immediately clear. To find out if user files are or were affected by bad sectors or bad sector repair (sector reallocation) you can use ‘NFI.exe’.
The Microsoft support tool NFI.exe can be used to convert a LBA sector address to a file path. This way you can determine which files need to be restored from backup after sector reallocation.
> nfi.exe Dumps information about an NTFS volume, and optionally determines which volume and file contains a particular sector. Usage: nfi drive-letter [logical-sector-number] Drive-letter can be a single character or a character followed by a colon (i.e., C or C: are acceptable). Logical-sector-number is a decimal or 0x-prefixed hex number, specifying a sector number relative to the volume whose drive letter is given by drive-letter. If not specified, then information about every file on the volume is dumped. nfi NT-device-path physical-sector-number Determines which volume a given physical sector on a drive is within, and then which file on the volume it is in. NT-device-path is the NT-style path to a physical device. It must not include a partition specification. Physical-sector-number is a decimal or 0x-prefixed hex number, specifying a sector number relative to the physical drive whose device path is given by NT-device-path. nfi full-win32-path Dumps information about a particular file. full-win32-path must start with a drive letter and a colon.
Note you must omit the “\\?” prefix of the block device path. Example:
C:\Users\admin\Downloads>nfi \Device\Harddisk0\DR0 28521816 NTFS File Sector Information Utility. Copyright (C) Microsoft Corporation 1999. All rights reserved. ***Physical sector 28521816 (0x1b33558) is in file number 5766 on drive C. \IMAGES\win7HDD.vhd
The alternative: HD Sentinel
HD Sentinel Pro offers several advantages over alternative tools that can ‘repair’ bad sectors:
- Repairs can be done from Windows
- HD Sentinel shows which file is affected by a bad sector.
1) If there is any suspicion of physical defect, Chkdsk should *not* be used – at least not until a full clone or image has been performed first and foremost, using a specialized tool like ddrescue or HDDSuperClone. Actually it’s better to run Chkdsk on the clone, or better yet a clone of the first clone, or backup the data from the clone first, then attempt to fix the file system in-place on the clone. If there are more than about 5 bad sectors on a drive it should not be used anymore to store any remotely important data, and Chkdsk won’t fix that kind of issue.
2) “Theoretically bad sectors in the first $MFT entries can be overcome by using the $MFTMIRR which backs up the first 10 records of the MFT.”
Actually it’s 4 records : the one pointing to the MFT itself, the MFT mirror itself, then $Logfile, then $Volume.
I had to analyze this quite in depth to solve that issue, whereby 3 of those records had been wiped on both the MFT and the MFT mirror :
3) “Minor file system damage can be fixed using Chkdsk.”
But even minor physical damage can be worsened using Chkdsk…
4) HD Sentinel, while it is great to constantly check the integrity of storage devices, has a huge caveat when it comes to that particular feature : when requested to provide file system informations about a particular sector previously identified as bad, it will attempt to actually access it and display its contents, instead of just giving the name of the file which currently occupies it by analyzing the MFT, like nfi.exe. This can further extend the damage to nearby sectors, and if the drive is about to fail badly it can contribute to the onset of a situation whereby it becomes too unstable to operate normally, at which point it becomes too late to perform a clone or image without highly expensive professional data recovery tools.
I wrote about it here :
(Which is where I found the link to this very article.)
5) I found out that nfi.exe had an issue with sector numbers beyond 2^31 or 2147483648 or exactly 2TB.
6) The native Windows tool fsutil also provides that information ; it uses cluster values instead of sector values.
fsutil volume querycluster X: [cluster number]
7) Although less accurate than nfi and fsutil, Piriform’s Defraggler is very convenient to get a list of files in the vicinity of sectors previously identified as bad, which is especially important when in a situation of having to salvage as much data as possible from a HDD with bad sectors : if the drive is still normally operating, and there are some folders which are especially important, and you’re wary of not getting those folders by going through the painstaking process of performing a full clone (knowing that the drive could fail dramatically before it’s complete), one possible course of action is to first do a read scan with HD Sentinel (with the “maximum try count” set to 0 in order to stress the drive to a minimum), which will provide a list of unreadable sectors, then use Defraggler to find out which files are on that problematic area or close enough (if bad sectors are due to a physical defect on the magnetic coating on the platters they can quickly spread whenever the heads fly close enough), then preemptively move those files to a special folder (be careful : for some file types, when they’re selected within the explorer, Windows will automatically attempt to parse them so as to display a preview, not good at all in that case, so it’s safer to move them from the command prompt), then copy all the other folders by order of importance (my favorite copy tools on Windows are those few ones which preserve all timestamps, including folders’ timestamps : Robocopy, SynchronizeIt, FastCopy), then at the very end you can try to copy those remaining files which are inside of – or very close to – the danger zone. Two options at that point :
– Copying each file one by one with Roadkil’s Unstoppable Copier, which will skip a selectable amount of sectors when a bad sector is encountered, but continue to copy anyway until the end of the file. The resulting file will have some empty “holes” but hopefully a large amount will be saved (the effect of that kind of corruption depends on the type of file, for a video file a single bad sector will usually result in a small glitch, but for JPG pictures the whole image beyond that point will be garbled). A compromise has to be made as to whether the threshold parameter should be set closer to “Best data recovery” (will try to read each sector, at the risk of spreading the damage and causing a major failure before all files have been at least partly recovered) or “Fastest data recovery” (which will skip a large chunk of data right away, safer approach but there might be a lot of still readable sectors in those skipped chunks).
– Using a Linux live environment and making a partial image with ddrescue to get as many sectors as possible (the boundaries can be defined by checking with Defraggler the total extent of sectors occupied by those remaining files and adding a margin of safety), then extracting the files from that partial image. But if you do that, make sure to get the whole MFT first – I learned it the hard way. That method should have been the best in that particular scenario, but it’s quite convoluted and prone to many mishaps along the way so I can’t recommand it. (At least I managed to fix my mess on my own ! :^p)
Good info, thanks! I’ll go over it and maybe update my post if have some time to spare!
(Two years later.)
“Good info, thanks!”
You’re welcome. ê_ê
“I’ll go over it and maybe update my post if have some time to spare!”
Apparently you have not. é_è (Haven’t re-read the whole article, but for instance it still says that $MFTMirr backs up the first 10 MFT records.) It’s not too late, as I’m sure this article still gets consulted quite a bit, it was mentioned on SuperUser as one of the most useful / relevant / complete sources available on the topic (see link 247419 in my previous post).
Earlier today I reported the issue I noticed regarding HD Sentinel to the parent company (pointing to my post on this page, as well as the threads I mentioned at SuperUser). Let’s hope that it will get fixed soon. In the mean time, I don’t recommend using HD Sentinel to determine which files are affected by bad sectors, for the reasons I explained above.
Checked and done, MFTMirror, 4 records, with screenshot ;)
The trial version just told me that a brand new, out-of-the-packet yesterday, HDD had been running for 458 days!
Why should I believe anything else HD Sentinel tells me?
Good that I didn’t waste my money on this product. Grrrrr.
As SMART attributes can vary from vendor to vendor or even model to model this can always happen. Another option is that you were given a refurbished disk.
Can you post smart report here, or care to email it (firstname.lastname@example.org)? Because if it is an error in HD Sentinel it’s nice if we can correct it.
Your comment is a bit short sighted if I may be honest.