WdfUsbTargetDeviceSendControlTransferSynchronously and timeouts

NTDEV
1

I’m using WdfUsbTargetDeviceSendControlTransferSynchronously() with a
WDF_REQUEST_SEND_OPTIONS to specify a timeout but I’ve encountered a
couple of issues.

  1. If I specify a 0 timeout then the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() fails immediately
    with a timeout. According to the documentation “If the value is zero,
    the framework does not time out the request.” I suspect that this is
    not true and that instead the framework doesn’t wait for the request.

  2. If I specify a relative timeout (600 ms or 600 seconds) the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() seems to timeout in
    1 second regardless of the timeout value.

Here is the code that I’m using:
WDF_REQUEST_SEND_OPTIONS SendOptions;
WDF_REQUEST_SEND_OPTIONS_INIT(&SendOptions,
WDF_REQUEST_SEND_OPTION_TIMEOUT);
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&SendOptions,
WDF_REL_TIMEOUT_IN_SEC(600));
status =

WdfUsbTargetDeviceSendControlTransferSynchronously(DevContext->UsbDevice
,
WDF_NO_HANDLE,
&SendOptions,

&ControlSetupPacket,
NULL,
NULL);

The reason that I’m trying to specify a large timeout is that I have a
USB device that for one of the control transfers takes a long time (1.25
seconds) to complete under some conditions. I’ve found that when it
takes this long that the
WdfUsbTargetDeviceSendControlTransferSynchronously() call fails. What I
see on the USB using a WDM based driver is that the Setup transaction
occurs and then I get IN transactions that are NAKed for 1.25 seconds
followed by an IN which is ACKed and then the status stage which
completes the transaction successfully. With the WDF based driver I see
the Setup transaction and then 0.998 seconds of NAKed IN transactions
and then nothing resulting in a failed transaction. I thought that if I
specified a longer timeout that this would handle this situation but it
seems to have no effect.

Regards,

  • Steve -
2

If you want no timeout, do not call SET_TIMEOUT. What is really the key
here is the timeout flag that is set by this function call, e.g.

VOID
FORCEINLINE
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(
OUT PWDF_REQUEST_SEND_OPTIONS Options,
IN LONGLONG Timeout
)
{
Options->Flags |= WDF_REQUEST_SEND_OPTION_TIMEOUT; <–
Options->Timeout = Timeout;
}

Otherwise, yes, zero will be treated as immediate. I will look at the
timeout logic later.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Friday, February 24, 2006 8:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfUsbTargetDeviceSendControlTransferSynchronously and
timeouts

I’m using WdfUsbTargetDeviceSendControlTransferSynchronously() with a
WDF_REQUEST_SEND_OPTIONS to specify a timeout but I’ve encountered a
couple of issues.

  1. If I specify a 0 timeout then the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() fails immediately
    with a timeout. According to the documentation “If the value is zero,
    the framework does not time out the request.” I suspect that this is
    not true and that instead the framework doesn’t wait for the request.

  2. If I specify a relative timeout (600 ms or 600 seconds) the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() seems to timeout in
    1 second regardless of the timeout value.

Here is the code that I’m using:
WDF_REQUEST_SEND_OPTIONS SendOptions;
WDF_REQUEST_SEND_OPTIONS_INIT(&SendOptions,
WDF_REQUEST_SEND_OPTION_TIMEOUT);
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&SendOptions,
WDF_REL_TIMEOUT_IN_SEC(600));
status =

WdfUsbTargetDeviceSendControlTransferSynchronously(DevContext->UsbDevice
,
WDF_NO_HANDLE,
&SendOptions,

&ControlSetupPacket,
NULL,
NULL);

The reason that I’m trying to specify a large timeout is that I have a
USB device that for one of the control transfers takes a long time (1.25
seconds) to complete under some conditions. I’ve found that when it
takes this long that the
WdfUsbTargetDeviceSendControlTransferSynchronously() call fails. What I
see on the USB using a WDM based driver is that the Setup transaction
occurs and then I get IN transactions that are NAKed for 1.25 seconds
followed by an IN which is ACKed and then the status stage which
completes the transaction successfully. With the WDF based driver I see
the Setup transaction and then 0.998 seconds of NAKed IN transactions
and then nothing resulting in a failed transaction. I thought that if I
specified a longer timeout that this would handle this situation but it
seems to have no effect.

Regards,

  • Steve -

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Originally I was passing NULL for the WDF_REQUEST_SEND_OPTIONS in the
call to WdfUsbTargetDeviceSendControlTransferSynchronously() and that
still resulted in a timeout.

I just tried using a WDF_REQUEST_SEND_OPTIONS without setting the
Timeout and I got the same behavior.

I can’t be positive that I’m getting a timeout but for some reason the
framework is not completing the Control Transfer. The status value
returned from WdfUsbTargetDeviceSendControlTransferSynchronously() is
STATUS_UNSUCCESSFUL which isn’t all that helpful.

Is it possible to turn on WPP tracing for WDF itself (not my driver but
the framework)? The documentation seems to indicate that it is possible
if you set the registry value VerboseOn to 1 in your drivers
Parameters/Wdf registry key but that didn’t seem to do anything.

Thanks,

  • Steve -

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-241263-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, February 24, 2006 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev]
WdfUsbTargetDeviceSendControlTransferSynchronously
and timeouts

If you want no timeout, do not call SET_TIMEOUT. What is really the
key
here is the timeout flag that is set by this function call, e.g.

VOID
FORCEINLINE
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(
OUT PWDF_REQUEST_SEND_OPTIONS Options,
IN LONGLONG Timeout
)
{
Options->Flags |= WDF_REQUEST_SEND_OPTION_TIMEOUT; <–
Options->Timeout = Timeout;
}

Otherwise, yes, zero will be treated as immediate. I will look at the
timeout logic later.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Friday, February 24, 2006 8:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfUsbTargetDeviceSendControlTransferSynchronously
and
timeouts

I’m using WdfUsbTargetDeviceSendControlTransferSynchronously() with a
WDF_REQUEST_SEND_OPTIONS to specify a timeout but I’ve encountered a
couple of issues.

  1. If I specify a 0 timeout then the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() fails immediately
    with a timeout. According to the documentation “If the value is zero,
    the framework does not time out the request.” I suspect that this is
    not true and that instead the framework doesn’t wait for the request.

  2. If I specify a relative timeout (600 ms or 600 seconds) the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() seems to timeout
    in
    1 second regardless of the timeout value.

Here is the code that I’m using:
WDF_REQUEST_SEND_OPTIONS SendOptions;
WDF_REQUEST_SEND_OPTIONS_INIT(&SendOptions,
WDF_REQUEST_SEND_OPTION_TIMEOUT);
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&SendOptions,
WDF_REL_TIMEOUT_IN_SEC(600));
status =

WdfUsbTargetDeviceSendControlTransferSynchronously(DevContext->UsbDevice

,
WDF_NO_HANDLE,
&SendOptions,

&ControlSetupPacket,
NULL,
NULL);

The reason that I’m trying to specify a large timeout is that I have a
USB device that for one of the control transfers takes a long time
(1.25
seconds) to complete under some conditions. I’ve found that when it
takes this long that the
WdfUsbTargetDeviceSendControlTransferSynchronously() call fails. What
I
see on the USB using a WDM based driver is that the Setup transaction
occurs and then I get IN transactions that are NAKed for 1.25 seconds
followed by an IN which is ACKed and then the status stage which
completes the transaction successfully. With the WDF based driver I
see
the Setup transaction and then 0.998 seconds of NAKed IN transactions
and then nothing resulting in a failed transaction. I thought that if
I
specified a longer timeout that this would handle this situation but
it
seems to have no effect.

Regards,

  • Steve -

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

After the unsucessful call to the KMDF DDI, break in and do the
following

!load c:\winddk\wdf\kmdf10\bin\x86\wdfkd.dll
!c:\winddk\wdf\kmdf10\bin\x86\wdfkd.wdfsearchpath
C:\WinDDK\wdf\KMDF10\symbols\x86fre\wdf\tmf
!c:\winddk\wdf\kmdf10\bin\x86\wdfkd.wdflogdump .sys>

(replace c:\winddk with your ddk install root as necessary)

If there are any errors, the log dump will tell you what happened.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Friday, February 24, 2006 10:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfUsbTargetDeviceSendControlTransferSynchronously
and timeouts

Originally I was passing NULL for the WDF_REQUEST_SEND_OPTIONS in the
call to WdfUsbTargetDeviceSendControlTransferSynchronously() and that
still resulted in a timeout.

I just tried using a WDF_REQUEST_SEND_OPTIONS without setting the
Timeout and I got the same behavior.

I can’t be positive that I’m getting a timeout but for some reason the
framework is not completing the Control Transfer. The status value
returned from WdfUsbTargetDeviceSendControlTransferSynchronously() is
STATUS_UNSUCCESSFUL which isn’t all that helpful.

Is it possible to turn on WPP tracing for WDF itself (not my driver but
the framework)? The documentation seems to indicate that it is possible
if you set the registry value VerboseOn to 1 in your drivers
Parameters/Wdf registry key but that didn’t seem to do anything.

Thanks,
- Steve -

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-241263-
> xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Friday, February 24, 2006 11:57 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev]
WdfUsbTargetDeviceSendControlTransferSynchronously
> and timeouts
>
> If you want no timeout, do not call SET_TIMEOUT. What is really the
key
> here is the timeout flag that is set by this function call, e.g.
>
> VOID
> FORCEINLINE
> WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(
> OUT PWDF_REQUEST_SEND_OPTIONS Options,
> IN LONGLONG Timeout
> )
> {
> Options->Flags |= WDF_REQUEST_SEND_OPTION_TIMEOUT; <–
> Options->Timeout = Timeout;
> }
>
> Otherwise, yes, zero will be treated as immediate. I will look at the
> timeout logic later.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
> Sent: Friday, February 24, 2006 8:38 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] WdfUsbTargetDeviceSendControlTransferSynchronously
and
> timeouts
>
> I’m using WdfUsbTargetDeviceSendControlTransferSynchronously() with a
> WDF_REQUEST_SEND_OPTIONS to specify a timeout but I’ve encountered a
> couple of issues.
>
> 1. If I specify a 0 timeout then the call to
> WdfUsbTargetDeviceSendControlTransferSynchronously() fails immediately
> with a timeout. According to the documentation “If the value is zero,
> the framework does not time out the request.” I suspect that this is
> not true and that instead the framework doesn’t wait for the request.
>
> 2. If I specify a relative timeout (600 ms or 600 seconds) the call to
> WdfUsbTargetDeviceSendControlTransferSynchronously() seems to timeout
in
> 1 second regardless of the timeout value.
>
> Here is the code that I’m using:
> WDF_REQUEST_SEND_OPTIONS SendOptions;
> WDF_REQUEST_SEND_OPTIONS_INIT(&SendOptions,
> WDF_REQUEST_SEND_OPTION_TIMEOUT);
> WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&SendOptions,
> WDF_REL_TIMEOUT_IN_SEC(600));
> status =
>
>
WdfUsbTargetDeviceSendControlTransferSynchronously(DevContext->UsbDevice
> ,
> WDF_NO_HANDLE,
> &SendOptions,
>
> &ControlSetupPacket,
> NULL,
> NULL);
>
> The reason that I’m trying to specify a large timeout is that I have a
> USB device that for one of the control transfers takes a long time
(1.25
> seconds) to complete under some conditions. I’ve found that when it
> takes this long that the
> WdfUsbTargetDeviceSendControlTransferSynchronously() call fails. What
I
> see on the USB using a WDM based driver is that the Setup transaction
> occurs and then I get IN transactions that are NAKed for 1.25 seconds
> followed by an IN which is ACKed and then the status stage which
> completes the transaction successfully. With the WDF based driver I
see
> the Setup transaction and then 0.998 seconds of NAKed IN transactions
> and then nothing resulting in a failed transaction. I thought that if
I
> specified a longer timeout that this would handle this situation but
it
> seems to have no effect.
>
> Regards,
> - Steve -
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

If WDF_REQUEST_SEND_OPTION_TIMEOUT is set, then we pass the value from
Options->Timeout directly to KeWaitForSingleObject after we call
IoCallDriver when sending the I/O.

d

-----Original Message-----
From: Doron Holan
Sent: Friday, February 24, 2006 8:57 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfUsbTargetDeviceSendControlTransferSynchronously
and timeouts

If you want no timeout, do not call SET_TIMEOUT. What is really the key
here is the timeout flag that is set by this function call, e.g.

VOID
FORCEINLINE
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(
OUT PWDF_REQUEST_SEND_OPTIONS Options,
IN LONGLONG Timeout
)
{
Options->Flags |= WDF_REQUEST_SEND_OPTION_TIMEOUT; <–
Options->Timeout = Timeout;
}

Otherwise, yes, zero will be treated as immediate. I will look at the
timeout logic later.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Friday, February 24, 2006 8:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfUsbTargetDeviceSendControlTransferSynchronously and
timeouts

I’m using WdfUsbTargetDeviceSendControlTransferSynchronously() with a
WDF_REQUEST_SEND_OPTIONS to specify a timeout but I’ve encountered a
couple of issues.

  1. If I specify a 0 timeout then the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() fails immediately
    with a timeout. According to the documentation “If the value is zero,
    the framework does not time out the request.” I suspect that this is
    not true and that instead the framework doesn’t wait for the request.

  2. If I specify a relative timeout (600 ms or 600 seconds) the call to
    WdfUsbTargetDeviceSendControlTransferSynchronously() seems to timeout in
    1 second regardless of the timeout value.

Here is the code that I’m using:
WDF_REQUEST_SEND_OPTIONS SendOptions;
WDF_REQUEST_SEND_OPTIONS_INIT(&SendOptions,
WDF_REQUEST_SEND_OPTION_TIMEOUT);
WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&SendOptions,
WDF_REL_TIMEOUT_IN_SEC(600));
status =

WdfUsbTargetDeviceSendControlTransferSynchronously(DevContext->UsbDevice
,
WDF_NO_HANDLE,
&SendOptions,

&ControlSetupPacket,
NULL,
NULL);

The reason that I’m trying to specify a large timeout is that I have a
USB device that for one of the control transfers takes a long time (1.25
seconds) to complete under some conditions. I’ve found that when it
takes this long that the
WdfUsbTargetDeviceSendControlTransferSynchronously() call fails. What I
see on the USB using a WDM based driver is that the Setup transaction
occurs and then I get IN transactions that are NAKed for 1.25 seconds
followed by an IN which is ACKed and then the status stage which
completes the transaction successfully. With the WDF based driver I see
the Setup transaction and then 0.998 seconds of NAKed IN transactions
and then nothing resulting in a failed transaction. I thought that if I
specified a longer timeout that this would handle this situation but it
seems to have no effect.

Regards,

  • Steve -

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

>

If there are any errors, the log dump will tell you what happened.

Thanks for the info on how to get the WPP tracing information.
Unfortunately it hasn’t helped me nail down what is causing the problem.
Here is the information from the log:
390: FxPkgIo_cpp123 – !devobj 0x81855C10
0x0000000e(IRP_MJ_DEVICE_CONTROL), IRP_MN 0, IRP 0x81ADE1A0
391: FxDevice_cpp1519 – Allocating FxRequest* 81830540, WDFREQUEST
7E7CFAB8
392: FxIoQueue_cpp1718 – Queuing WDFREQUEST 0x7E7CFAB8 on WDFQUEUE
0x7E7B3850
393: FxIoQueue_cpp2108 – Thread 8181B020 is processing WDFQUEUE
0x7E7B3850
394: FxIoQueue_cpp2518 – Calling driver EvtIoDeviceControl for
WDFREQUEST 0x7E7CFAB8
395: FxRequestApi_cpp838 – Enter: WDFREQUEST 0x7E7CFAB8
396: FxRequestApi_cpp980 – Enter: WDFREQUEST 0x7E7CFAB8
397: FxUsbDeviceAPI_cpp91 – WDFUSBDEVICE 7E787D00 control transfer
sync
398: FxUsbDeviceAPI_cpp94 – WDFUSBDEVICE 7E787D00, WDFREQUEST F76A68E8
being submitted
399: FxIoTarget_cpp1222 – WDFIOTARGET 7E787D00, WDFREQUEST F76A68E8
400: FxIoTarget_cpp1277 – action 0x11
401: FxIoTarget_cpp1290 – Sending WDFREQUEST F76A68E8, Irp 81826CD8
402: FxIoTarget_cpp1762 – WDFREQUEST F76A68E8
403: FxIoTarget_cpp1485 – WDFIOTARGET 7E787D00, WDFREQUEST F76A68E8
404: FxIoTarget_cpp1817 – WDFREQUEST F76A68E8 completed in
completion routine
405: FxUsbDeviceAPI_cpp96 – WDFUSBDEVICE 7E787D00,
0xc0000001(STATUS_UNSUCCESSFUL)
406: FxSyncRequest_cpp162 – SyncRequest F76A68E8, signaling event
F76A6960 on SelfDestruct
407: FxRequestApi_cpp422 – Completing WDFREQUEST 0x7E7CFAB8,
0xc0000001(STATUS_UNSUCCESSFUL)
408: FxRequest_cpp461 – Completing WDFREQUEST 0x7E7CFAB8 for IRP
0x81ADE1A0 with Information 0x0, 0xc0000001(STATUS_UNSUCCESSFUL)
409: FxIoQueue_cpp1607 – Enter: WDFQUEUE 0x7E7B3850, WDFREQUEST
0x7E7CFAB8
410: FxIoQueue_cpp2635 – WDFREQUEST 0x7E7CFAB8 dispatched to driver
411: FxDevice_cpp1536 – Free FxRequest* 81830540 memory
412: FxIoQueue_cpp2313 – No requests on WDFQUEUE 0x7E7B3850
413: FxPkgGeneral_cpp412 – !devobj 0x81855C10
0x00000012(IRP_MJ_CLEANUP) IRP 0x81ADE1A0
414: FxIoQueue_cpp2108 – Thread 8181B020 is processing WDFQUEUE
0x7E7B3850
415: FxIoQueue_cpp2313 – No requests on WDFQUEUE 0x7E7B3850
416: FxIoQueue_cpp2108 – Thread 8181B020 is processing WDFQUEUE
0x7E4BE408
417: FxIoQueue_cpp2313 – No requests on WDFQUEUE 0x7E4BE408
418: FxIoQueue_cpp2108 – Thread 8181B020 is processing WDFQUEUE
0x7E7E2538
419: FxIoQueue_cpp2313 – No requests on WDFQUEUE 0x7E7E2538
420: FxPkgGeneral_cpp412 – !devobj 0x81855C10
0x00000002(IRP_MJ_CLOSE) IRP 0x81ADE1A0

I believe that the call to
WdfUsbTargetDeviceSendControlTransferSynchronously() started at event
#395 and failed at #405 but this hasn’t provided me with any more
information that I had before. I still have no idea why I’m getting a
STATUS_UNSUCCESSFUL.

  • Steve -
7

>

If WDF_REQUEST_SEND_OPTION_TIMEOUT is set, then we pass the value from
Options->Timeout directly to KeWaitForSingleObject after we call
IoCallDriver when sending the I/O.

Based on the error code returned and the trace log (see my previous msg)
it doesn’t look like I’m experiencing a timeout. I guess I’ll have to
start spelunking deeper into the framework.

Thanks,

  • Steve -
8

I am pretty sure that you are getting STATUS_UNSUCCESSFUL from the USB
core, not from KMDF. From the log

397: FxUsbDeviceAPI_cpp91 – WDFUSBDEVICE 7E787D00 control transfer
sync
398: FxUsbDeviceAPI_cpp94 – WDFUSBDEVICE 7E787D00, WDFREQUEST F76A68E8
being submitted
399: FxIoTarget_cpp1222 – WDFIOTARGET 7E787D00, WDFREQUEST F76A68E8
400: FxIoTarget_cpp1277 – action 0x11

** sending the target here **
401: FxIoTarget_cpp1290 – Sending WDFREQUEST F76A68E8, Irp 81826CD8
402: FxIoTarget_cpp1762 – WDFREQUEST F76A68E8
403: FxIoTarget_cpp1485 – WDFIOTARGET 7E787D00, WDFREQUEST F76A68E8

** completion routine ran, means request was sent **
404: FxIoTarget_cpp1817 – WDFREQUEST F76A68E8 completed in
completion routine

405: FxUsbDeviceAPI_cpp96 – WDFUSBDEVICE 7E787D00,
0xc0000001(STATUS_UNSUCCESSFUL)

Did you have previous WDM code that worked ? if so, how did you build
the URB? I can compare the 2 and see if there is a difference.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Friday, February 24, 2006 12:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfUsbTargetDeviceSendControlTransferSynchronously
and timeouts

If WDF_REQUEST_SEND_OPTION_TIMEOUT is set, then we pass the value from
Options->Timeout directly to KeWaitForSingleObject after we call
IoCallDriver when sending the I/O.

Based on the error code returned and the trace log (see my previous msg)
it doesn’t look like I’m experiencing a timeout. I guess I’ll have to
start spelunking deeper into the framework.

Thanks,

  • Steve -

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

>

Did you have previous WDM code that worked ? if so, how did you build
the URB? I can compare the 2 and see if there is a difference.

I do have a WDM driver that works. However I have determined that under
some conditions which I still haven’t isolated even the WDM driver fails
with a C0000001 return code so I’m not sure that this problem has
nothing to do with WDF but is due to some oddness on the USB device.

Thanks for all your help.

  • Steve -