Re: USBSER.SYS: where to get a bug-free version?

From: Alexander Grigoriev (alegr_at_earthlink.net)
Date: 08/31/04 

Date: Mon, 30 Aug 2004 19:24:12 -0700

If a plugged in device is causing a blue screen with stock drivers, then
there is a bug in drivers.

Properly designed drivers should withstand whatever faulty or bogus hardware
is plugged into USB, with whatever incorrect descriptors, etc. In the
current state, it seems not the case. If USBSER gives a BSOD, it needs to be
fixed. It doesn't have to work with hardware it doesn't understand, but it
should not crash the whole system.

There used to be a problem if a USB device returned zero-length string
descriptor. Seems fixed now, but it means that USB stack developpers are not
paying attention to the external data validation.

For example, USBHUB crashes, if a IgnoreSerialNumxxxxxx registry value is
not in 1-byte format. Should it be so fragile?

Another problem: if an USB drive gives block size 8 KB, it BSODs. See
http://www.usb.org/phpbb/viewtopic.php?t=4376

"Marc Reinig" <AOLab@newsgroup.nospam> wrote in message
news:Ou8QwzrjEHA.4092@TK2MSFTNGP10.phx.gbl...
> In general, Windows does support composite devices.
>
> However, USBSer does not support operation in a composite mode (well, you
> might try using the endpoints after the ones USBSer expects, but I'm not
> sure if that works across all revs).
>
> Also, as far as I am aware, Windows does not support DFU as a class and
> USB has not identified any class which must be supported.
>
> So this is not a violation of the USB spec. Should it be changed in
> Windows to make development easier? Yes. Do you need to write a Windows
> driver or change your device to not cause a blue screen on a Windows host?
> Yes.
>
> Marc Reinig
> System Solutions
>
> "Holi" <holi@nospam.com> wrote in message
> news:%23Vn8DTmjEHA.2776@TK2MSFTNGP10.phx.gbl...
>> First of all I'm not so sure if Windows supports composite devices at
>> all - not to support is one thing, but producing BSOD's because of not
>> supporting is another.
>>
>> DFU specs (chapt. 4.1.) say:
>> "During normal run-time operation, the device exposes its normal set of
>> descriptors. However, the
>> following additional descriptors are inserted within each run-time
>> configuration that supports DFU:
>> - A single DFU class interface descriptor
>> - A single functional descriptor
>> 4.1.1 Run-Time Device and Configuration Descriptors
>> The run-time descriptor set exposes the device’s normal run-time device
>> and configuration descriptors.
>> The bNumInterfaces field of configuration descriptor of each
>> configuration that supports DFU is incremented by one to accommodate the
>> addition of the run-time DFU interface."
>>
>> Our device was checked by a validator program on MAC OS and looks fine.
>> Windows ends up with a BSOD with this implementation of DFU specs. I
>> think for DFU support this IS a requirement.
>>
>> What do you think?
>>
>> Holi
>>
>> Marc Reinig wrote:
>>> The USB spec has many features. Some are required and are labeled as
>>> such.
>>> Some are optional and are not labeled as required. Which of the
>>> required
>>> features do you feel have been either omitted or incorrectly
>>> implemented.
>>>
>>> Marc Reinig
>>> System Solutions
>
>

Relevant Pages