Checking WdfUsbInterfaceGetConfiguredPipe result

NTDEV
1

Under the model KMDF for a USB device, I’ve just discovered the hard way
that each call to WdfUsbInterfaceGetConfiguredPipe must be checked for
success, otherwise a kernel bugcheck is possible - generally associated with
unplugging an active device. I confess that I borrowed the following code
fragment from the Win DDK USBSamp and did not perform a mental PREFast and
documentation validation:

pipe = WdfUsbInterfaceGetConfiguredPipe(pDevContext->UsbInterface,
i, //PipeIndex,
NULL
);

UsbSamp_DbgPrint(3, (“Aborting open pipe %d\n”, i));

status = WdfUsbTargetPipeAbortSynchronously(pipe,
WDF_NO_HANDLE, // WDFREQUEST
NULL);//PWDF_REQUEST_SEND_OPTIONS

That’s right: there is no check that the pipe is valid (not NULL) before
passing it to WdfUsbTargetPipeAbortSynchronously(). And the documentation
states that it will bugcheck if the passed handle is invalid. PREFast and
SDV don’t call this out.

2

You don’t have to check for the result if the inputs are good. How did you get the value in ‘i’? is it an internal value or something the user app sent to you? Do you change the state of the WDFUSBDEVICE after PrepareHardare (i.e. reconfigure it at runtime, thus invalidating the existing pipes) or just create the WDFUSBDEVICE, configure it and then let KMDF clean it up when the device is removed?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mike N.
Sent: Friday, June 05, 2009 7:41 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Checking WdfUsbInterfaceGetConfiguredPipe result

Under the model KMDF for a USB device, I’ve just discovered the hard way that each call to WdfUsbInterfaceGetConfiguredPipe must be checked for success, otherwise a kernel bugcheck is possible - generally associated with
unplugging an active device. I confess that I borrowed the following code
fragment from the Win DDK USBSamp and did not perform a mental PREFast and documentation validation:

pipe = WdfUsbInterfaceGetConfiguredPipe(pDevContext->UsbInterface,
i, //PipeIndex,
NULL
);

UsbSamp_DbgPrint(3, (“Aborting open pipe %d\n”, i));

status = WdfUsbTargetPipeAbortSynchronously(pipe,
WDF_NO_HANDLE, // WDFREQUEST
NULL);//PWDF_REQUEST_SEND_OPTIONS

That’s right: there is no check that the pipe is valid (not NULL) before passing it to WdfUsbTargetPipeAbortSynchronously(). And the documentation
states that it will bugcheck if the passed handle is invalid. PREFast and
SDV don’t call this out.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

3

The value in ‘i’ is in a loop based on pDevContext->NumberConfiguredPipes .
This is fine for normal operation - I am not reconfiguring the device at
runtime. KMDF cleans up when the device is removed.
The difficulty comes during a surprise disconnect when some of the original
configured pipes in the DeviceContext are no longer valid at the time of
Device Open and I attempt to touch a pipe without checking the return value
for validity. That’s why I was surprised to see a similar construct in the
original sample usbsamp.

From: “Doron Holan”
Sent: Friday, June 05, 2009 12:33 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Checking WdfUsbInterfaceGetConfiguredPipe result

> You don’t have to check for the result if the inputs are good. How did
> you get the value in ‘i’? is it an internal value or something the user
> app sent to you? Do you change the state of the WDFUSBDEVICE after
> PrepareHardare (i.e. reconfigure it at runtime, thus invalidating the
> existing pipes) or just create the WDFUSBDEVICE, configure it and then let
> KMDF clean it up when the device is removed?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike N.
> Sent: Friday, June 05, 2009 7:41 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Checking WdfUsbInterfaceGetConfiguredPipe result
>
> Under the model KMDF for a USB device, I’ve just discovered the hard way
> that each call to WdfUsbInterfaceGetConfiguredPipe must be checked for
> success, otherwise a kernel bugcheck is possible - generally associated
> with
> unplugging an active device. I confess that I borrowed the following
> code
> fragment from the Win DDK USBSamp and did not perform a mental PREFast and
> documentation validation:
>
> pipe = WdfUsbInterfaceGetConfiguredPipe(pDevContext->UsbInterface,
> i, //PipeIndex,
> NULL
> );
>
> UsbSamp_DbgPrint(3, (“Aborting open pipe %d\n”, i));
>
> status = WdfUsbTargetPipeAbortSynchronously(pipe,
> WDF_NO_HANDLE, // WDFREQUEST
> NULL);//PWDF_REQUEST_SEND_OPTIONS
>
> That’s right: there is no check that the pipe is valid (not NULL) before
> passing it to WdfUsbTargetPipeAbortSynchronously(). And the documentation
> states that it will bugcheck if the passed handle is invalid. PREFast
> and
> SDV don’t call this out.
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

4

The pipe remain valid in the surprise removed state, they are deleted when the device receives a pnp remove. For it to receive the remove, all outstanding file handles must be closed which means that there is no way for the app to send io once kmdf deletes the object (if kmdf cleaning it up is the only path where they get deleted). Thr only way to receive io in the removed state is if there is kernel sender without a file object.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mike N.
Sent: Sunday, June 07, 2009 10:30 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Checking WdfUsbInterfaceGetConfiguredPipe result

The value in ‘i’ is in a loop based on pDevContext->NumberConfiguredPipes .
This is fine for normal operation - I am not reconfiguring the device at
runtime. KMDF cleans up when the device is removed.
The difficulty comes during a surprise disconnect when some of the original
configured pipes in the DeviceContext are no longer valid at the time of
Device Open and I attempt to touch a pipe without checking the return value
for validity. That’s why I was surprised to see a similar construct in the
original sample usbsamp.

--------------------------------------------------
From: “Doron Holan”
Sent: Friday, June 05, 2009 12:33 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Checking WdfUsbInterfaceGetConfiguredPipe result

> You don’t have to check for the result if the inputs are good. How did
> you get the value in ‘i’? is it an internal value or something the user
> app sent to you? Do you change the state of the WDFUSBDEVICE after
> PrepareHardare (i.e. reconfigure it at runtime, thus invalidating the
> existing pipes) or just create the WDFUSBDEVICE, configure it and then let
> KMDF clean it up when the device is removed?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike N.
> Sent: Friday, June 05, 2009 7:41 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Checking WdfUsbInterfaceGetConfiguredPipe result
>
> Under the model KMDF for a USB device, I’ve just discovered the hard way
> that each call to WdfUsbInterfaceGetConfiguredPipe must be checked for
> success, otherwise a kernel bugcheck is possible - generally associated
> with
> unplugging an active device. I confess that I borrowed the following
> code
> fragment from the Win DDK USBSamp and did not perform a mental PREFast and
> documentation validation:
>
> pipe = WdfUsbInterfaceGetConfiguredPipe(pDevContext->UsbInterface,
> i, //PipeIndex,
> NULL
> );
>
> UsbSamp_DbgPrint(3, (“Aborting open pipe %d\n”, i));
>
> status = WdfUsbTargetPipeAbortSynchronously(pipe,
> WDF_NO_HANDLE, // WDFREQUEST
> NULL);//PWDF_REQUEST_SEND_OPTIONS
>
> That’s right: there is no check that the pipe is valid (not NULL) before
> passing it to WdfUsbTargetPipeAbortSynchronously(). And the documentation
> states that it will bugcheck if the passed handle is invalid. PREFast
> and
> SDV don’t call this out.
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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