Bad cluster (bad block) mapping to filenames
msg
easily searchable references in Usenet archives (e.g. Google
Groups), I felt it useful to post a suggestion regarding
bad cluster (bad block) analysis on NTFS.
Typically if a user encounters problems on booting an NT
derived O/S that hosts a drive with bad clusters in areas
needed by the system, either a blue screen stop will occur
(e.g. 0x0000007B Boot Device Unavailable) or autocheck
will offer to repair the drive and after a timeout will
proceed to do so. If 'chkdsk' is allowed to proceed, the
user will not likely be able to determine what files contained
the bad blocks that will now be mapped out to spares, except
through inferences from forensic analysis.
Web forums are full of advice to permit this behavior and
to suffer the consequences; either restore from backups,
compare each and every file to ascertain which ones may have
changed, or contract to a data recovery service for more
comprehensive analysis. Any major O/S should provide utilities
to analyze the filesystem and volume structure at all levels;
Unix users (and users of other server class O/Ses) are used
to this capability as standard, and indeed NT based O/Ses
also have useful filesystem analysis utilities without need
to purchase expensive and bloated commercial-ware.
A useful approach to deal with bad blocks is to prevent chkdsk
from repairing a drive with bad blocks during boot (and
certainly don't run it manually), instead examine the volume
to determine what files or structures contain bad blocks before
permitting a repair.
Remove the offending drive if it is the boot device and
install it as an additional drive in a different system;
if it is not the boot device, perform the following steps
in the original system. On boot, in the new system, do not
permit chkdsk to repair the drive. First, generate a list of
the bad blocks on the drive using your favorite tool for the
purpose; I find it simple to just 'dd' the drive to NUL
until there is an I/O error, note the block number and
run 'dd' again, skipping over the block, and noting any
subsequent I/O errors, recursively, e.g.
dd if=\\.\PhysicalDrive1 bs=512 of=nul
(note that this usage of 'dd' is in a cmd.exe shell, using
a version of 'dd' built for native use; if using 'Cygwin',
use the unix pathname syntax in the command)
Get 'nfi.exe' from the 'oem3sr2' package available at the
time of this writing at:
http://download.microsoft.com/download/win2000srv/utility/3.0/nt45/en-us/oem3sr2.zip
Read the file 'specs/ph3nfi.htm' in the archive for usage syntax
of the nfi.exe utility. There is some confusion regarding NT file
system pathnames; I found that the following worked on Win2k for
physical drive 1 (drive 'D:') -- the examples below show the results
_after_ chkdsk was permitted to repair the drive, which had a bad
physical block 70498, which turned out to be in $LogFile which was
a relatively safe place to develop an error (the nfi command was
told to look at a sector just prior to the bad cluster; when doing
this before a repair, run nfi on the offending sector instead):
C:\Program Files\bin>nfi \device\harddisk1\Partition0 70503
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.
***Physical sector 70503 (0x11367) is in file number 2 on drive D.
Log File ($LogFile)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
physical sectors 199-70494 (0xc7-0x1135e)
physical sectors 142935-142942 (0x22e57-0x22e5e)
physical sectors 70503-131270 (0x11367-0x200c6)
Note that the extent of '$LogFile' now goes up to 70494, skips
the bad clusters and resumes from 70503. Here is the report for
physical sector 70498 (our original reported bad block):
C:\Program Files\bin>nfi \device\harddisk1\Partition0 70498
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.
***Physical sector 70498 (0x11362) is in file number 8 on drive D.
Bad Cluster List ($BadClus)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)
$DATA $Bad (nonresident)
physical sectors 70495-70502 (0x1135f-0x11366)
In the above case, it is evident that the bad blocks are manageable
without filesystem corruption; however in other cases knowing in
advance where the damage lies permits the user to choose a repair
methodology in keeping with his requirements. I suggest that auto
repair of filesystems by default is inadvisable; at least the timeout
should be changed to require a positive affirmation by the user before
any auto repairs are effected.
BTW, the 'System Log' viewable in 'Event Viewer' contains 'Event 7'
bad block reports; does anyone have information on what the displayed
hex data reports?
Michael