Some time ago I noticed a bunch of disk controller error messages in Windows' Event Viewer and got alarmed that one of my disks or disk controllers might be corrupting data.
The actual messages looked like this:
The driver detected a controller error on \Device\Harddisk1\DR4. The driver detected a controller error on \Device\Harddisk2\DR5.
, and physical drive numbers corresponded to hard drives in the Mediasonic ProBox enclosure HF2-SU3S2. I contacted Mediasonic Support and went through the usual troubleshooting hoops replacing drivers, checking SMART output for affected drives, changing USB sleep power-off features, etc. None of these steps eliminated error messages or explained them in any way.
With all other ways to figure out what's going on, I decided to fire up Wireshark and try the USB capture, which I never used before.
It took me a bit to figure out how to find the USB channel on which this error was reported, but in the end the problem became quite self-evident - HF2-SU3S2 was powering down drives without Windows telling it to do so and Windows wasn't expecting a delay for a read request to be as long as 8 seconds, which is how long it took HF2-SU3S2 to spin up the drives.
Windows reported the controller error right at the end of that 8-second failed read, so that was indeed the problem. Windows was set up to power off hard drives after 15 minutes when plugged in and HF2-SU3S2 was powering down drives after a minute, which clearly was the manufacturer's attempt to be helpful, but just as many attempts to do so without any regard to other components, it is hurting more than it is helping.
It also appears from the capture that Windows attempts to repeat the failed read, so no data is actually lost, but I didn't confirm this bit beyond any doubt. So far it appears to be the case with all the data with built-in integrity checks, like ZIP files, read from and written to this enclosure.
Hard drive enclosure manufacturers shouldn't just power drives on their own, but should listen what the operating system tells them to do, so the operating system knows when to expect a delay after waking up a device from sleep and when just go ahead and read data. I hope one day they will, but in the meantime I keep collecting those errors in my Windows Event Log and it is quite unsettling, even now that I know what's going on.