Win7x64 Serious USB Disk Bug. Post 1

[buai]

Windows 7 x64 seems to have a long-standing serious bug in the USB disk I/O system.

After getting quite a few corrupted files on my USB disks, I searched forums for similar reports. These problem reports go back to day-one for Win7, but only for 64-bit installations. It does not seem to depend on the architecture at all, and it is not a USB-3 issue. I will summarize below. In the second post, I will give some details of the nature of the corruption for a specific incident.

1. Corruption occurs when writing to a USB storage device, but not when reading from a device. Both flash drives and HDD can have this corruption.

2. The corruption is not reproducible; not even with the same initial conditions. It is quite flaky and random. I suspect this is a software/hardware timing issue with buffers, rather than a logical error in the Win7 operating system.

3. I mostly store files in archives (zip, 7z, etc) or compute checksums for newly written large files. This is how I found the problem. Corrupted files may be of any size, not just large ones.

4. The problem is not related to any updates or service packs. Not related to architecture. Seems to be confined to Win7 x64.

5. As shown in the next post, the error is an absence data in whole sectors of the o/p file.

6. One user has reported that switching the USB write policy from write-thu (quick disconnect) to write (performance) cures the problem.

This is a very serious problem, and MS needs to admit it, and to fix it. The average user is mostly unaware of this corruption. When they do find this problem, the USB device is always blamed, and junked.

(MS engineers take note. Pestiferous suggestions and requests for irrelevant info will be ignored.)

 

[buai]

Please see my previous post. This post describes a specific incident of USB file corrution. I wrote a 1GB file from my laptop (Ausus EM642G) to a 750GB WD USB disk. The disk was new and fully zeroed (0x00 in every byte) before formatting. A SHA1 check showed that the new file on the external disk was not the same as the original one on the C-drive desktop. Using unix tools the following were results found.

1. The new file was the correct length. The first 555MB (55% of 1GB) was identical to the original file. There were then 40 consective sectors in the corrupt file, that had zeros in them. It was exactly 40 of 512byte sectors. The next few megabytes were correct. Futher errors were all in exact groups of 512byte sectors.

2. The zero sectors were mostly likely due to the free space being all zeroed. The problem was that no data at all was written to them, rather than bad data.

3. When pasting in Win7 , the progress bar went to about the 50% mark instantly, and then filled up to the 100% mark at normal speed.

4. Looks like a buffer flushing problem. There are multiple s/w buffers for a single i/o opertion. Disk space is allocated correctly, but the buffers never get written.