Re: USBSER.SYS: where to get a bug-free version?
From: Holi (holi_at_nospam.com)
Date: 09/02/04
- Next message: Holi: "Re: HOWTO debug with 2 computers"
- Previous message: Mark Roddy: "Re: Distinguishing resources of the same type and length"
- Next in thread: Maxim S. Shatskih: "Re: USBSER.SYS: where to get a bug-free version?"
- Reply: Maxim S. Shatskih: "Re: USBSER.SYS: where to get a bug-free version?"
- Maybe reply: Robby Tanner: "Re: USBSER.SYS: where to get a bug-free version?"
- Reply: Tim Roberts: "Re: USBSER.SYS: where to get a bug-free version?"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 02 Sep 2004 14:38:22 +0200
I completely agree with Alexander (the other reply to your post)!
And it IS definitely a bug (at least in usbser.sys)! Not to not support DFU (or
any additional interface besides CDC), but to BSOD if such a device appears!!!
We also found usbd.sys and ntoskrnl.exe to BSOD due to similar device
configurations (that fulfill the specs).
But what I wonder most is: there are already quite a few people involved in
this thread, BUT NONE OF THEM SEEMS TO BE OF MICROSOFT (normally appearing with
[MS] in the name)... What do they fear? Afraid of admitting an error?
Holi
Marc Reinig wrote:
> 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
>
>
>
- Next message: Holi: "Re: HOWTO debug with 2 computers"
- Previous message: Mark Roddy: "Re: Distinguishing resources of the same type and length"
- Next in thread: Maxim S. Shatskih: "Re: USBSER.SYS: where to get a bug-free version?"
- Reply: Maxim S. Shatskih: "Re: USBSER.SYS: where to get a bug-free version?"
- Maybe reply: Robby Tanner: "Re: USBSER.SYS: where to get a bug-free version?"
- Reply: Tim Roberts: "Re: USBSER.SYS: where to get a bug-free version?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|