Getting USBD_PIPE_INFORMATION without reconfiguring the device?

NTDEV
1

I’m in a situation where I’m trying to debug a device and use some of the
unused endpoints on the device for said debugging purpose, but my PDO’s
device extension is pretty much opaque (long story short - I can get to it,
but the structure is so unwieldy and complicated that it’s painful). And I
don’t have direct control over the device extension (format is fixed) - so I
can’t just stuff my USBD_PIPE_INFORMATION in some kind of associative array
with endpoint and stick it in there.

After looking around a bit, it seems like the only way to get at your
USBD_PIPE_INFORMATIONs is to create an URB via
USBD_CreateConfigurationRequestEx and submit it to the USB stack. My guess
is that calling this a second time is going to reconfigure the device,
possibly invalidating your existing PipeHandles - which I do not want. Is
this correct?

Basically, I want to get the pipe handle for a particular endpoint and I
can’t reconfigure the device or share info from the native driver. Is there
a way around this?

Thanks in advance,
Christina Peterson

2

Christina Peterson wrote:

I’m in a situation where I’m trying to debug a device and use some of
the unused endpoints on the device for said debugging purpose, but my
PDO’s device extension is pretty much opaque (long story short - I can
get to it, but the structure is so unwieldy and complicated that it’s
painful). And I don’t have direct control over the device extension
(format is fixed) - so I can’t just stuff my USBD_PIPE_INFORMATION in
some kind of associative array with endpoint and stick it in there.

At some point, your existing driver must have done a SetConfiguration
call. That call returns a set of USBD_INTERFACE_INFORMATION structures,
and those structures contain USBD_PIPE_INFORMATION structures. Most
drivers make a complete copy of the USBD_INTERFACE_INFORMATION in their
device extensions, exactly so they can get pipe handles later on. My
guess is, if you look through the device extension, you will find the
information you need.

I’m confused about your environment. Are you writing a filter driver?
If not, if you are actually working with the source code of the driver,
then I find the whole “unwieldy and complicated” comment to be odd.
It’s just a data structure. If it’s just the case that you don’t
understand the code well enough yet to make this kind of modification,
then I would suggest that you go take the time to understand it. It’s
always better to write new code to fit the existing philosophy than it
is to attach another wart on the side.

After looking around a bit, it seems like the only way to get at your
USBD_PIPE_INFORMATIONs is to create an URB via
USBD_CreateConfigurationRequestEx and submit it to the USB stack. My
guess is that calling this a second time is going to reconfigure the
device, possibly invalidating your existing PipeHandles - which I do
not want. Is this correct?

Correct.

Basically, I want to get the pipe handle for a particular endpoint and
I can’t reconfigure the device or share info from the native driver.
Is there a way around this?

Well, sort of. You can also get a USBD_INTERFACE_INFORMATION structure
back from a SelectInterface request (URB_FUNCTION_SELECT_INTERFACE).
Assuming that you only have one interface with one alternate setting,
you can just select interface 0, alternate setting 0. And in that case,
the call will probably have no effect on the device itself.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Tim Roberts wrote:

>Christina Peterson wrote:
> Basically, I want to get the pipe handle for a particular endpoint and
> I can’t reconfigure the device or share info from the native driver.
> Is there a way around this?
Well, sort of. You can also get a USBD_INTERFACE_INFORMATION structure back from a
SelectInterface request (URB_FUNCTION_SELECT_INTERFACE). Assuming that you only have one >interface with one alternate setting, you can just select interface 0, alternate setting 0. And in that >case, the call will probably have no effect on the device itself.

I’ll give this a try. Our device doesn’t care about interface (it only supports 1 anyways), so this shouldn’t matter. Thanks a bunch.

Christina Peterson

4

xxxxx@gmail.com wrote:

Tim Roberts wrote:

>> Christina Peterson wrote:
>> Basically, I want to get the pipe handle for a particular endpoint and
>> I can’t reconfigure the device or share info from the native driver.
>> Is there a way around this?
>>
> Well, sort of. You can also get a USBD_INTERFACE_INFORMATION structure back from a
> SelectInterface request (URB_FUNCTION_SELECT_INTERFACE). Assuming that you only have one >interface with one alternate setting, you can just select interface 0, alternate setting 0. And in that >case, the call will probably have no effect on the device itself.
>

I’ll give this a try. Our device doesn’t care about interface (it only supports 1 anyways), so this shouldn’t matter. Thanks a bunch.

OK, but turning on my “scolding” mode, unless you are a filter driver,
the RIGHT solution is to wade through the device extension and find
where the existing driver has tucked the USBD_INTERFACE_INFORMATION it
already fetched.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Christina Peterson wrote:

but my PDO’s device extension is pretty much opaque

What exactly do you mean here by a PDO having a device extension? What does that even mean?

If you are a lower filter, just watch for the pipes during select-config.

If you are the FDO, I don’t understand the vague claim that you can “get” to the device extension but can’t parse it.

If you are an upper filter or anyone else, I submit that you don’t have any business messing with the device directly. So what gives?