[KMDF USB] My DeviceAdd is being called twice for one device!

Yeah, it's me again. This time, I have a composite device here that is
configured like the below.

Interface 0:
- bulk IN endpoint
- bulk OUT endpoint
- interrupt IN endpoint

Interface 1:
- bulk IN endpoint
- bulk OUT endpoint

I load the generic parent driver (usbhub, I'm on Win2k) for this device
which then enumerates two child devices. So far, so good.

I am using the same function driver binary for both interfaces (PDOs)
-- although it is set up with a different service name and different
binary name in the other INF file. If the interrupt endpoint is not
seen, the driver just removes some functionality on the fly.

If it matters, the first interface is "modem" class and the second is
"ports" class. I call WdfDeviceCreateDeviceInterface conditionally,
either passing GUID_DEVINTERFACE_MODEM or GUID_DEVINTERFACE_COMPORT.

I can load my function driver successfully on the first interface
without any trouble.

When it loads on the second, I am getting *two* calls into my AddDevice
routine, and *two* calls into my PrepareHardware. Inside
PrepareHardware, I can see that the two WDFDEVICE handles that I'm
given are different (say, 0x7CAD0FF8 versus 0x7CA97FF8). Naturally,
when I go to call WdfUsbTargetDeviceCreate() inside PrepareHardware,
the second call fails out.

I can't even fathom a guess as to why this happens. Any ideas?

Doron
Fri Sep 08 00:57:31 CDT 2006

this is an installation issue that you somehow got yourself into. you can
do the following
1) put a breakpoint in your prepare hw callback
2) before the bp, get the WDM devobj from the WDFDEVICE and store it in a
local (or print it out to the debugger) so that once the bp hits, you can
see the value
3) run !devstack <PDEVICE_OBJECT> and look at the devnode path. note the
path for both instances. I bet you have a root enumerated device or you
actually have 3 interfaces and don;t realize it.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<chris.aseltine@gmail.com> wrote in message
news:1157669936.830007.40040@h48g2000cwc.googlegroups.com...
> Yeah, it's me again. This time, I have a composite device here that is
> configured like the below.
>
> Interface 0:
> - bulk IN endpoint
> - bulk OUT endpoint
> - interrupt IN endpoint
>
> Interface 1:
> - bulk IN endpoint
> - bulk OUT endpoint
>
> I load the generic parent driver (usbhub, I'm on Win2k) for this device
> which then enumerates two child devices. So far, so good.
>
> I am using the same function driver binary for both interfaces (PDOs)
> -- although it is set up with a different service name and different
> binary name in the other INF file. If the interrupt endpoint is not
> seen, the driver just removes some functionality on the fly.
>
> If it matters, the first interface is "modem" class and the second is
> "ports" class. I call WdfDeviceCreateDeviceInterface conditionally,
> either passing GUID_DEVINTERFACE_MODEM or GUID_DEVINTERFACE_COMPORT.
>
> I can load my function driver successfully on the first interface
> without any trouble.
>
> When it loads on the second, I am getting *two* calls into my AddDevice
> routine, and *two* calls into my PrepareHardware. Inside
> PrepareHardware, I can see that the two WDFDEVICE handles that I'm
> given are different (say, 0x7CAD0FF8 versus 0x7CA97FF8). Naturally,
> when I go to call WdfUsbTargetDeviceCreate() inside PrepareHardware,
> the second call fails out.
>
> I can't even fathom a guess as to why this happens. Any ideas?
>

chris
Fri Sep 08 10:26:28 CDT 2006

Doron Holan [MS] wrote:

> this is an installation issue that you somehow got yourself into. you can
> do the following
> 1) put a breakpoint in your prepare hw callback
> 2) before the bp, get the WDM devobj from the WDFDEVICE and store it in a
> local (or print it out to the debugger) so that once the bp hits, you can
> see the value
> 3) run !devstack <PDEVICE_OBJECT> and look at the devnode path. note the
> path for both instances. I bet you have a root enumerated device or you
> actually have 3 interfaces and don;t realize it.

I haven't run the debugger yet, but I did print the results of
WdfDeviceWdmGetPhysicalDevice(Device) and
WdfDeviceWdmGetDeviceObject(Device), and I also moved the operation
from my Win2k machine to an XP 64-bit machine. The result was the
same.

When I check the debug trace, my PDO is exactly the same value
(0x8365C5D0) in both calls to PrepareHardware(), but the FDO is
different (0x83AAB7D0 vs. 0x83661470).

Here's my questions:

1) This device is plugged in over USB, so I don't see how I could have
created a root enumerated device. I haven't messed with the Toaster
bus or anything like that.

2) I'm certain the device has two interfaces. Plus, if it had three
interfaces, wouldn't usbhub/usbccgp create three child objects?

3) If my PDO value is the same in both calls to PrepareHardware(), I'm
assuming !devstack is going to show me the same driver stack in both
cases, but I can still try.

-Chris

chris
Fri Sep 08 12:07:44 CDT 2006

Doron Holan [MS] wrote:

> this is an installation issue that you somehow got yourself into. you can
> do the following
> 1) put a breakpoint in your prepare hw callback
> 2) before the bp, get the WDM devobj from the WDFDEVICE and store it in a
> local (or print it out to the debugger) so that once the bp hits, you can
> see the value
> 3) run !devstack <PDEVICE_OBJECT> and look at the devnode path. note the
> path for both instances. I bet you have a root enumerated device or you
> actually have 3 interfaces and don;t realize it.

Ok. Sorry, this was my fault -- and thanks for the tip about
!devstack. It immediately made the problem obvious.

What I saw was two instances of my driver on the stack, i.e.

1) mydriver
2) mydriver
3) usbhub

First, I was trying to do a "modem" and "port" at the same time from
this composite device, but didn't make the connection that a "modem"
USB driver is really a lower filter (*only*) to Modem.sys, and a "Port"
is its *own* function driver (only).

So when I loaded Modem with Addservice=xxx,0x00000002, I was getting
duplicate loads on the stack. But then when I loaded Ports with
Addservice=xxx,0x00000000, I wasn't getting any function drivers at
all.

After switching these around (modem == lower filter [0], port ==
function driver [2]), everything works perfectly. Sorry for the false
alarm.

-Chris

chris
Fri Sep 08 12:52:40 CDT 2006

chris.aseltine@gmail.com wrote:

> So when I loaded Modem with Addservice=xxx,0x00000002, I was getting
> duplicate loads on the stack. But then when I loaded Ports with
> Addservice=xxx,0x00000000, I wasn't getting any function drivers at
> all.
>
> After switching these around (modem == lower filter [0], port ==
> function driver [2]), everything works perfectly. Sorry for the false
> alarm.

Or, I should say: this was really caused by copying-and-pasting the
modem INF to the ports INF -- of course the modem INF loaded itself as
a lower filter -- combined with 0x0000002 this caused the double-load.

So the real lesson for me today, I suppose, is: don't copy and paste
INFs without knowing what I'm doing!