CHKDSK errors even after boot time checkdisk

[glugglug]

The monthly scan from Stablebit Scanner told me I had 2 drives with corrupt filesystems. Not too big a surprise, as I have had several unclean reboots in the past month when I had some UI (including explorer) freezes after enabling WiFi and playing around with a bunch of network sniffers to try and crack temporary guest networks I set up in different modes.

Anyway, I have (several times now) set it to run CHKDSK on those drives at boot. Sometimes the boot CHKDSK gives a clean bill of health, sometimes it finds sometimes it finds a number of "unused index entries from index $SII of file 0x9" to clean up and/or free space marked as used (which does NOT get put in a "Found" folder like it claims). Either way, after the boot-time checkdisk clears the dirty bit, CHKDSK from within windows still says there are errors, but won't tell me what.

Searching for the "unused index entries from index $SII of file 0x9" thing brings up articles about some bug where the WinXP version of CHKDSK errantly deletes security descriptors when you have more than 4 million files. But I am running Windows 7 x64 and don't have over 4 million files on either of these drives.


System seems to be running normally, other than the CHKDSK complaints. There are no bad clusters on any drives.

Sample output running CHKDSK from command line:

W:\>chkdsk /v
The type of the file system is NTFS.
Volume label is 4TBD.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
  80896 file records processed.
File verification completed.
  89 large file records processed.
  0 bad file records processed.
  0 EA records processed.
  0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
  92460 index entries processed.
Index verification completed.
  0 unindexed files scanned.
  0 unindexed files recovered.
CHKDSK is verifying security descriptors (stage 3 of 3)...
  80896 file SDs/SIDs processed.
Security descriptor verification completed.
  5783 data files processed.
CHKDSK is verifying Usn Journal...
100 percent complete. (147996672 of 147997176 USN bytes processed)
Examining Usn Journal file record segment.
  147997176 USN bytes processed.
Usn Journal verification completed.
Windows found problems with the file system.
Run CHKDSK with the /F (fix) option to correct these.

   3815317 MB total disk space.
1987003392 KB in 55640 files.
     19524 KB in 5784 indexes.
         0 KB in bad sectors.
   4609183 KB in use by the system.
     65536 KB occupied by the log file.
1915253532 KB available on disk.

      4096 bytes in each allocation unit.
 976721407 total allocation units on disk.
 478813383 allocation units available on disk.

Any ideas? I looked around and couldn't find any good chkdsk alternatives for NTFS. Lots of apps to scan for bad blocks, but nothing for doing filesystem consistency checks/cleanup.

 

[Elixer]

What does SMART say about the drives (Use crystaldiskinfo portable to check)? They could be on the way out...

 

[glugglug]

One drive has clean SMART info, the other has 6 pending sectors (which read fine on a surface scan, it has had them a few weeks now, but apparently there is a bit error getting corrected on them by ECC so the drive is waiting for them to be explicitly rewritten).

 

[Steltek]

Another thing you might consider is to run a MEMTEST86+ session as file system corruption can be a side effect of a failing memory module.

 

[Elixer]

One drive has clean SMART info, the other has 6 pending sectors (which read fine on a surface scan, it has had them a few weeks now, but apparently there is a bit error getting corrected on them by ECC so the drive is waiting for them to be explicitly rewritten).

It has been my experience that when a drive starts to have bad sectors, it is better to get a new one, and use the current one as a scratch drive.

From within windows, you can also do chkdsk /x drive: and it should give you more info while it corrects the error.
If this is a boot drive, then on reboot, you can look at the event viewer logs to see what it said about it.

You should also look at the event viewer now, and see how many errors/warnings you see that have to do with disks.

 

[glugglug]

There are no event log messages about the drives, at all.

One thing I noticed checking the drives from safe mode so drivepool isn't started up using them, is that on one of the drives the # of bytes it is checking of the USN journal goes to 4GB, then like -220 MB. in the last second. Maybe some kind of bug when it goes over 4GB?

The drives are part of a pool so they should have near the same use as each other. In addition to normal desktop use the machine is used as a 10-tuner DVR, so there are a lot of large files written/deleted every day.

Both drives show the USN journal bytes somewhere around 150MB when it finishes.