NTFS erros on one type of USB disk

[Tom Del Rosso]

I have a SBS 2003 server with SCSI internal and 2 types of USB disks,
"Maxtor OneTouch 4" and "Maxtor OneTouch 4 Mini".

The mini drive type has no problem. The standard size drive type logs about
4000 NTFS file system errors every day. This system has no other critical
error in the logs (except for things like login failures) going back months.

The problem started when I had to restore a systemstate backup. I then
replaced the drive with an identical one but it behaves the same.

Maybe a driver was not restored properly, although there is no low-level
error logged by the drivers, only NTFS errors, and reinstalling the drivers
the usual way didn't help. But what other possibility is there?

Right now I'm surveying other systems with the same type of drive to get
driver info for comparison. In the meantime any ideas are appreciated.

 

[Arno Wagner]

I have a SBS 2003 server with SCSI internal and 2 types of USB disks,
"Maxtor OneTouch 4" and "Maxtor OneTouch 4 Mini".

The mini drive type has no problem. The standard size drive type logs about
4000 NTFS file system errors every day. This system has no other critical
error in the logs (except for things like login failures) going back months.

The problem started when I had to restore a systemstate backup. I then
replaced the drive with an identical one but it behaves the same.

Maybe a driver was not restored properly, although there is no low-level
error logged by the drivers, only NTFS errors, and reinstalling the drivers
the usual way didn't help. But what other possibility is there?

Right now I'm surveying other systems with the same type of drive to get
driver info for comparison. In the meantime any ideas are appreciated.

And maybe, if you gave us the error messages as well,
we would have a chance to understand the problem?

Arno

 

[Tom Del Rosso]

And maybe, if you gave us the error messages as well,
we would have a chance to understand the problem?

Event Type: Error
Event Source: Ntfs
Event Category: Disk
Event ID: 55
Date: 3/24/2008
Time: 3:31:34 PM
User: N/A
Computer: KOHSBS01
Description:
The file system structure on the disk is corrupt and unusable. Please run
the chkdsk utility on the volume X:.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 0d 00 04 00 02 00 52 00 ......R.
0008: 02 00 00 00 37 00 04 c0 ....7..À
0010: 00 00 00 00 02 01 00 c0 .......À
0018: 00 00 00 00 00 00 00 00 ........
0020: 00 00 00 00 00 00 00 00 ........
0028: 81 01 22 00 .".

 

[Eric Gisin]

Event Type: Error
Event Source: Ntfs
Event Category: Disk
Event ID: 55
Date: 3/24/2008
Time: 3:31:34 PM
User: N/A
Computer: KOHSBS01
Description:
The file system structure on the disk is corrupt and unusable. Please run
the chkdsk utility on the volume X:.

Are you running chkdsk regularly on this drive? What errors does it find?
You have to be careful with disk removal with NTFS. FAT32 is more forgiving.

 

[Tom Del Rosso]

Are you running chkdsk regularly on this drive? What errors does it
find?

Chkdsk find's pretty much every error in its vocabulary. It reports fixing
it but sees the same errors again right away. After a few passes it finds
no errors, but the files are gone so it effectively reformatted. Then the
problem returns within a day (like it does after reformatting). Since I did
this earlier today, it's reporting no errors right now, but tomorrow I'll
try again and post the chkdsk output.

You have to be careful with disk removal with NTFS. FAT32 is more
forgiving.

It's practically never removed. The problem returns right after
reformatting it, and the drive has already been replaced. Another type of
USB drive has no problem at all though, and neither do the SCSI drives. The
USB ports have been swapped. I also tried both enabling and disabling the
write cache.

The only thing I know that hasn't been done is a radical removal of the
drivers and letting the OS enumerate them again, but I don't want to mess up
any other drivers on an otherwise perfect system. In other respects it's
the most error-free system, since it ran for months with no other errors at
all.

 

[Tom Del Rosso]

Are you running chkdsk regularly on this drive? What errors does it
find?
You have to be careful with disk removal with NTFS. FAT32 is more
forgiving.

-----Here it is without /f


C:\WINDOWS>chkdsk x:
The type of the file system is NTFS.
Volume label is BACKUP_USB_1.

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

CHKDSK is verifying files (stage 1 of 3)...
3 percent complete. (34 of 112 file records processed)
Deleting corrupt attribute record (128, "")
from file record segment 36.
112 file records processed.
File verification completed.
61 large file records processed.

Errors found. CHKDSK cannot continue in read-only mode.


-----with /f


C:\WINDOWS>chkdsk x:/f
The type of the file system is NTFS.
Volume label is BACKUP_USB_1.

CHKDSK is verifying files (stage 1 of 3)...
3 percent complete. (34 of 112 file records processed)
Deleting corrupt attribute record (128, "")
from file record segment 36.
112 file records processed.
File verification completed.
61 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)...
Correcting error in index $I30 for file 5.
Correcting error in index $I30 for file 5.
Sorting index $I30 in file 5.
16 percent complete. (9 of 273 index entries processed)
Correcting error in index $SDH for file 9.
Correcting error in index $SDH for file 9.
Sorting index $SDH in file 9.
30 percent complete. (56 of 273 index entries processed)
Correcting error in index $I30 for file 27.
Correcting error in index $I30 for file 27.
Sorting index $I30 in file 27.
273 index entries processed.
Index verification completed.
CHKDSK is recovering lost files.
89 percent complete. (1 of 23 unindexed files processed)
Recovering orphaned file $MFT (0) into directory file 5.
Recovering orphaned file $MFTMirr (1) into directory file 5.
90 percent complete. (3 of 23 unindexed files processed)
Recovering orphaned file $LogFile (2) into directory file 5.
Recovering orphaned file $Volume (3) into directory file 5.
Recovering orphaned file $AttrDef (4) into directory file 5.
Recovering orphaned file . (5) into directory file 5.
Recovering orphaned file $Bitmap (6) into directory file 5.
Recovering orphaned file $Boot (7) into directory file 5.
Recovering orphaned file $BadClus (8) into directory file 5.
Recovering orphaned file $Secure (9) into directory file 5.
Recovering orphaned file $UpCase (10) into directory file 5.
Recovering orphaned file $Extend (11) into directory file 5.
Recovering orphaned file SYSTEM~1 (27) into directory file 5.
Recovering orphaned file System Volume Information (27) into directory file
5.
Recovering orphaned file MOUNTP~1 (28) into directory file 27.
Recovering orphaned file MountPointManagerRemoteDatabase (28) into directory
fil
e 27.
Recovering orphaned file tracking.log (29) into directory file 27.
Recovering orphaned file Backups (30) into directory file 5.
91 percent complete. (17 of 23 unindexed files processed)
Recovering orphaned file ARCHIV~1 (31) into directory file 5.
Recovering orphaned file Archives1 (31) into directory file 5.
Recovering orphaned file ARCHIV~2 (32) into directory file 5.
Recovering orphaned file Archives2 (32) into directory file 5.
Recovering orphaned file 97{380~1 (36) into directory file 27.
Recovering orphaned file 97{3808876b-c176-4e48-b7ae-04046e6cc752} (36) into
dire
ctory file 27.
24 unindexed files processed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Inserting an index entry with Id 256 into index $SDH of file 9.
Inserting an index entry with Id 257 into index $SDH of file 9.
Inserting an index entry with Id 258 into index $SDH of file 9.
Inserting an index entry with Id 259 into index $SDH of file 9.
Inserting an index entry with Id 260 into index $SDH of file 9.
Inserting an index entry with Id 261 into index $SDH of file 9.
Inserting an index entry with Id 262 into index $SDH of file 9.
Inserting an index entry with Id 263 into index $SDH of file 9.
Repairing the security file record segment.
Replacing missing or invalid security descriptor for file 5.
112 security descriptors processed.
Security descriptor verification completed.
Inserting data attribute into file 36.
12 data files processed.
Correcting errors in the Master File Table (MFT) mirror.
Correcting errors in the uppercase file.
Correcting errors in the master file table's (MFT) BITMAP attribute.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

732572000 KB total disk space.
6919208 KB in 5 files.
24 KB in 13 indexes.
0 KB in bad sectors.
88408 KB in use by the system.
65536 KB occupied by the log file.
725564360 KB available on disk.

4096 bytes in each allocation unit.
183143000 total allocation units on disk.
181391090 allocation units available on disk.

 

[Arno Wagner]

Chkdsk find's pretty much every error in its vocabulary. It reports
fixing it but sees the same errors again right away. After a few
passes it finds no errors, but the files are gone so it effectively
reformatted. Then the problem returns within a day (like it does
after reformatting). Since I did this earlier today, it's reporting
no errors right now, but tomorrow I'll try again and post the chkdsk
output.

This means it is very likely not a problem with the disk itself,
but possibly with the enclosure.

It's practically never removed. The problem returns right after
reformatting it, and the drive has already been replaced. Another
type of USB drive has no problem at all though, and neither do the
SCSI drives. The USB ports have been swapped. I also tried both
enabling and disabling the write cache.

There are rare cases where the cables cause problems. Have you
tried different USB cables?

The only thing I know that hasn't been done is a radical removal of
the drivers and letting the OS enumerate them again, but I don't
want to mess up any other drivers on an otherwise perfect system.
In other respects it's the most error-free system, since it ran for
months with no other errors at all.

If nothing else helps, you can salvage the drive by getting
a drive-less external enclosure and transplanting the rare drive.
I would say this most likely is a problem somewhere in the USB
path, possibly a subtle incompatibility between enclosure and
computer USB ports, or, as mentioned above, a bad USB cable.

Arno

 

[Tom Del Rosso]

This means it is very likely not a problem with the disk itself,
but possibly with the enclosure.

Well it was all replaced under Maxtor's warranty.

There are rare cases where the cables cause problems. Have you
tried different USB cables?

When I replaced the drive I used the new cable.

If nothing else helps, you can salvage the drive by getting
a drive-less external enclosure and transplanting the rare drive.
I would say this most likely is a problem somewhere in the USB
path, possibly a subtle incompatibility between enclosure and
computer USB ports, or, as mentioned above, a bad USB cable.

Thanks. I tried the other USB ports but they all use the same on-board
controller. I'll try a spare card I have. It seems like such a problem
ought to produce a lower-level error, but it's worth a try.