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.


--

Reply in group, but if emailing add another
zero, and remove the last word.

Previously Tom Del Rosso <(E-Mail Removed)> wrote:
> 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

"Arno Wagner" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> Previously Tom Del Rosso <(E-Mail Removed)> wrote:
>> 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?


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 �.".



--

Reply in group, but if emailing add another
zero, and remove the last word.

"Tom Del Rosso" <(E-Mail Removed)> wrote in message news:47e80333$0$5650$(E-Mail Removed)...
>
> 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.

"Eric Gisin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
>>
> 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.


--

Reply in group, but if emailing add another
zero, and remove the last word.

"Eric Gisin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> "Tom Del Rosso" <(E-Mail Removed)> wrote in message
> news:47e80333$0$5650$(E-Mail Removed)...
>>
>> 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.


-----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.



--

Reply in group, but if emailing add another
zero, and remove the last word.

Previously Tom Del Rosso <(E-Mail Removed)> wrote:
> "Eric Gisin" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)
>>>
>> 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.

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

>> 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.

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

"Arno Wagner" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> Previously Tom Del Rosso <(E-Mail Removed)> wrote:
>> "Eric Gisin" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)
>>>>
>>> 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.
>
> 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.


--

Reply in group, but if emailing add another
zero, and remove the last word.