I have a USB device with a WDM driver that has been in use for several years
on W2k and XP. I am rewriting the driver to use WDF, WPP and eventually
some other enhancement specific to the USB device. The device has 2 Bulk in
pipes and 1 Bulk out pipe. With the new WDF driver, the CATC USB tracer
sees the correct data going to the target device on a Bulk out pipe but the
data coming back is identified as coming back on an Iso pipe. The driver
sees an NTSTATUS of 0xc0000001. The data on the Iso pipe reported by the
CATC is also correct.
Does anyone have any ideas why the data coming from the target device is on
an Iso pipe instead of the Bulk In pipe? I’m assuming that is why of have
an NTSTATUS error.
*I have KMDF v1.1, Windows Server sp1 DDK (3790.1830), and Vista Beta 2
(5384) installed.
*I’m using KMDF v1.1 and the 3790 build environment.
*Target box is currently an XP Pro box
*When device connects, all three pipes are identified correctly during
configuration.
*WinDbg’s wdfkd extension (KMDF version is loaded) reports the correct pipe
information as:
kd> !wdfkd.wdfusbpipe 0x79411b18
WDFUSBPIPE 79411b18
Type UsbdPipeTypeBulk
Direction Out
MaxPacket 0x200, Max Transfer 0xffffffff
Endpoint Address 0x1
USBD_PIPE_HANDLE 86ca0c04
!WDFUSBDEVICE 79351b58
!WDFUSBINTERFACE 79274bb8
kd> !wdfkd.wdfusbpipe 0x79410dd0
WDFUSBPIPE 79410dd0
Type UsbdPipeTypeBulk
Direction In
MaxPacket 0x200, Max Transfer 0xffffffff
Endpoint Address 0x81
USBD_PIPE_HANDLE 86ca0c24
!WDFUSBDEVICE 79351b58
!WDFUSBINTERFACE 79274bb8
kd> !wdfkd.wdfusbpipe 0x79411438
WDFUSBPIPE 79411438
Type UsbdPipeTypeBulk
Direction In
MaxPacket 0x200, Max Transfer 0xffffffff
Endpoint Address 0x82
USBD_PIPE_HANDLE 86ca0c44
!WDFUSBDEVICE 79351b58
!WDFUSBINTERFACE 79274bb8
Thanks
David Voeller
More information:
*The driver gets an IOCTL and then issues an asychronous write followed by
an asychronous read.
*The read completion routine reports no bytes read even when the CATC show
all of the correct bytes being sent. I am looking at
PWDF_USB_REQUEST_COMPLETION_PARAMS Parameters.PipeRead.Length to get the
number of bytes read.
“David Voeller” wrote in message news:xxxxx@ntdev…
>I have a USB device with a WDM driver that has been in use for several
>years on W2k and XP. I am rewriting the driver to use WDF, WPP and
>eventually some other enhancement specific to the USB device. The device
>has 2 Bulk in pipes and 1 Bulk out pipe. With the new WDF driver, the CATC
>USB tracer sees the correct data going to the target device on a Bulk out
>pipe but the data coming back is identified as coming back on an Iso pipe.
>The driver sees an NTSTATUS of 0xc0000001. The data on the Iso pipe
>reported by the CATC is also correct.
>
> Does anyone have any ideas why the data coming from the target device is
> on an Iso pipe instead of the Bulk In pipe? I’m assuming that is why of
> have an NTSTATUS error.
>
>
> *I have KMDF v1.1, Windows Server sp1 DDK (3790.1830), and Vista Beta 2
> (5384) installed.
> *I’m using KMDF v1.1 and the 3790 build environment.
> *Target box is currently an XP Pro box
> *When device connects, all three pipes are identified correctly during
> configuration.
> *WinDbg’s wdfkd extension (KMDF version is loaded) reports the correct
> pipe information as:
> kd> !wdfkd.wdfusbpipe 0x79411b18
>
> WDFUSBPIPE 79411b18
> ===========================
> Type UsbdPipeTypeBulk
> Direction Out
> MaxPacket 0x200, Max Transfer 0xffffffff
> Endpoint Address 0x1
> USBD_PIPE_HANDLE 86ca0c04
>
> !WDFUSBDEVICE 79351b58
> !WDFUSBINTERFACE 79274bb8
>
> kd> !wdfkd.wdfusbpipe 0x79410dd0
>
> WDFUSBPIPE 79410dd0
> ===========================
> Type UsbdPipeTypeBulk
> Direction In
> MaxPacket 0x200, Max Transfer 0xffffffff
> Endpoint Address 0x81
> USBD_PIPE_HANDLE 86ca0c24
>
> !WDFUSBDEVICE 79351b58
> !WDFUSBINTERFACE 79274bb8
>
> kd> !wdfkd.wdfusbpipe 0x79411438
>
> WDFUSBPIPE 79411438
> ===========================
> Type UsbdPipeTypeBulk
> Direction In
> MaxPacket 0x200, Max Transfer 0xffffffff
> Endpoint Address 0x82
> USBD_PIPE_HANDLE 86ca0c44
>
> !WDFUSBDEVICE 79351b58
> !WDFUSBINTERFACE 79274bb8
>
> Thanks
>
> David Voeller
>
>
David Voeller wrote:
I have a USB device with a WDM driver that has been in use for several years
on W2k and XP. I am rewriting the driver to use WDF, WPP and eventually
some other enhancement specific to the USB device. The device has 2 Bulk in
pipes and 1 Bulk out pipe. With the new WDF driver, the CATC USB tracer
sees the correct data going to the target device on a Bulk out pipe but the
data coming back is identified as coming back on an Iso pipe. The driver
sees an NTSTATUS of 0xc0000001. The data on the Iso pipe reported by the
CATC is also correct.
Does anyone have any ideas why the data coming from the target device is on
an Iso pipe instead of the Bulk In pipe? I’m assuming that is why of have
an NTSTATUS error.
Does your device have multiple configurations, or multiple interfaces,
or multiple alternate settings?
This almost has to be a firmware or CATC bug. The type of pipe is not
included in each transfer. In fact, the only time that information
travels across the wire is when the device sends its descriptors, so the
analyzer must be snooping that information at setup time. Have you
double-checked your descriptors by hand, byte-by-byte, to make sure they
are valid? Maybe KMDF is more forgiving of descriptor problems than the
CATC. Can you post a hex dump of your descriptors?
C0000001 (STATUS_UNSUCCESSFUL) is pretty generic. Is there an error code
in the URB?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
*This is a single interface device.
*The read completion routine reports a USB status of 0 (also of no help). I
am looking at PWDF_USB_REQUEST_COMPLETION_PARAMS parameter
(Parameters.Usb.Completion.UsbdStatus) in the completion routine to get the
USB status.
*I was thinking the same thing about the error being in the device firmware
or even the CATC but the WDM driver talks to the same device using the same
data and the CATC reports the data coming back on a Bulk In pipe.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> David Voeller wrote:
>
>>I have a USB device with a WDM driver that has been in use for several
>>years
>>on W2k and XP. I am rewriting the driver to use WDF, WPP and eventually
>>some other enhancement specific to the USB device. The device has 2 Bulk
>>in
>>pipes and 1 Bulk out pipe. With the new WDF driver, the CATC USB tracer
>>sees the correct data going to the target device on a Bulk out pipe but
>>the
>>data coming back is identified as coming back on an Iso pipe. The driver
>>sees an NTSTATUS of 0xc0000001. The data on the Iso pipe reported by the
>>CATC is also correct.
>>
>>Does anyone have any ideas why the data coming from the target device is
>>on
>>an Iso pipe instead of the Bulk In pipe? I’m assuming that is why of have
>>an NTSTATUS error.
>>
>>
>
> Does your device have multiple configurations, or multiple interfaces,
> or multiple alternate settings?
>
> This almost has to be a firmware or CATC bug. The type of pipe is not
> included in each transfer. In fact, the only time that information
> travels across the wire is when the device sends its descriptors, so the
> analyzer must be snooping that information at setup time. Have you
> double-checked your descriptors by hand, byte-by-byte, to make sure they
> are valid? Maybe KMDF is more forgiving of descriptor problems than the
> CATC. Can you post a hex dump of your descriptors?
>
> C0000001 (STATUS_UNSUCCESSFUL) is pretty generic. Is there an error code
> in the URB?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
David Voeller wrote:
*I was thinking the same thing about the error being in the device firmware
or even the CATC but the WDM driver talks to the same device using the same
data and the CATC reports the data coming back on a Bulk In pipe.
I don’t know how to explain that without falling back on my old standby:
gamma rays. A pipe gets its personality from its descriptors, not from
the host.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> The type of pipe is not
included in each transfer. In fact, the only time that information
travels across the wire is when the device sends its descriptors…
It not correct for Iso pipes. Iso transfers use a different protocol from the
control/bulk/interrupt protocol: there are no ACK/NAK acknowledgment packets.
Does the device send the correct configuration descriptor without any Iso
endpoints?
Dmitriy Budko
VMware
In short yes
USBView shows the correct configuration
As I said earlier, the LDF driver is seeing the correct endpoints when
initially getting configured.
I am going to take a closer look at all the bits sent across on the bus
using the CATC to verify the configuration information. I trust the CATC’s
ability to report the raw bits.
Dave
“Dmitriy Budko” wrote in message news:xxxxx@ntdev…
> The type of pipe is not
> included in each transfer. In fact, the only time that information
> travels across the wire is when the device sends its descriptors…
It not correct for Iso pipes. Iso transfers use a different protocol from
the
control/bulk/interrupt protocol: there are no ACK/NAK acknowledgment
packets.
Does the device send the correct configuration descriptor without any Iso
endpoints?
Dmitriy Budko
VMware
I have fixed my problem.
I was using the buffer from the IOCTL to read data asynchronously from the
device. Normally I wouldn’t think this was a problem but the buffer was too
small. I had forgot that I needed to strip off some header information from
my device before sending the actual data back to the application. The
solution was to create another buffer correctly sized.
As for the CATC identifying the pipe as Isochronous instead of Bulk In, I
didn’t pursue that further. The CATC doesn’t store the descriptor
information that I know of. It has trouble deciding if a pipe is bulk or
interrupt because they look that same as far as protocol. I suspect there
is something in the protocol that makes the pipe look like an isochronous
pipe but I don’t know what.
The biggest disappointment in this particular bug was the NTSTATUS I
received. Both the NTSTATUS and the URB status gave me no indication of the
problem. The problem was stupid on my part but I was hoping for a little
more help from the error status.
Dave
“David Voeller” wrote in message news:xxxxx@ntdev…
> In short yes
>
> USBView shows the correct configuration
>
> As I said earlier, the LDF driver is seeing the correct endpoints when
> initially getting configured.
>
> I am going to take a closer look at all the bits sent across on the bus
> using the CATC to verify the configuration information. I trust the
> CATC’s ability to report the raw bits.
>
> Dave
>
>
> “Dmitriy Budko” wrote in message news:xxxxx@ntdev…
>> The type of pipe is not
>> included in each transfer. In fact, the only time that information
>> travels across the wire is when the device sends its descriptors…
>
> It not correct for Iso pipes. Iso transfers use a different protocol from
> the
> control/bulk/interrupt protocol: there are no ACK/NAK acknowledgment
> packets.
>
> Does the device send the correct configuration descriptor without any Iso
> endpoints?
>
>
> Dmitriy Budko
> VMware
>
>
>