A lesson on Windows’ Internals
Ok, let me begin with a quick question. Suppose you’re designing a USB peripheral for a PC, and are using Windows to test it out. Now, the development process is fairly lengthy, so you’ll be writing and testing in stages to see how each module performs.
Right. Now assume you’re writing a USB Mass Storage device. You’re not sure how much of it is working. What would you expect Windows to do when it sees something is amiss during the device enumeration?
If you answered “pop up a detailed error report”, you’d be wrong. Totally wrong, in fact. The best Windows can do is – if you’re lucky – eventually pop up with a balloon saying that the device could not be enumerated “because it has a problem”. Extremely helpful. If you’re unlucky, Windows will just sit there with the device installation balloon frozen on the last device interface it tried to instantiate.
Now, for the million dollar question. What would you expect Windows to do once it realizes that the disk portion of the device has a problem? The answer, of course, is this:

Yes, that’s right. A faulty USB mass storage device triggers a blue screen of death. Apparently a balloon just isn’t good enough for a system calamity of this magnitude. I hope that won’t be a regular occurrence during the development period.
Despite the above setbacks, the Mass Storage Demo code is coming along reasonably well despite the SCSI standards body doing their best to make the standards as obtuse as possible. I’ve implemented only three commands so far, but at least I’m getting somewhere.

Loading...