I am writing a virtual USB Bus driver (usb over Ethernet)
implementation. Basically my Bus driver and some other code provides all
the USB lower layer functionality that windows stack provides. I have
USB Mass Storage working fine with this implementation.
Now I’m trying to support a device that installs its own driver/user
mode software. Their driver loads fine and at some point sends down
IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME. I’m supposing It forwards the
response of this to its user mode component (after some manipulation may
be). Later user mode calls into the host controller driver and gets info
about this device.
I’m failing in this step here (i.e. after I return a controller name, I
don’t get anything after that). I’m confused about what to send as
controller name. Documentation says Symbolic name for the controller.
I’m responding with a name
“\.\root#system#0003#{3abf6f2d-71c4-462a-8a92-1e6861e6af27}”,
This name can be used from user mode to open my kernel mode driver (I
have tried it). Is that the right format? Windows responds with
“??\PCI#VEN_8086&DEV_27CA&SUBSYS_200A17AA&REV_02#3&b1bfb68&0&EA#{3abf6f
2d-71c4-462a-8a92-1e6861e6af2}”
Also I’m supposed to fill in USB_HUB_NAME structure with this name. It
unclear if the ActualLength field of this structure has to include
string length + 4 bytes for its own. I’m assuming a UNICODE_NULL is
included in it too. I have tried all permutations here and none seem to
work. May be my symbolic name format is wrong.
Any help is appreciated?
-pankaj
Pankaj Garg wrote:
I’m failing in this step here (i.e. after I return a controller name, I
don’t get anything after that). I’m confused about what to send as
controller name. Documentation says Symbolic name for the controller.
I’m responding with a name
“\.\root#system#0003#{3abf6f2d-71c4-462a-8a92-1e6861e6af27}”,
This name can be used from user mode to open my kernel mode driver (I
have tried it). Is that the right format? Windows responds with
“??\PCI#VEN_8086&DEV_27CA&SUBSYS_200A17AA&REV_02#3&b1bfb68&0&EA#{3abf6f
2d-71c4-462a-8a92-1e6861e6af2}”
Does it make a difference if you return ??\ instead of \.\ ?
Also I’m supposed to fill in USB_HUB_NAME structure with this name. It
unclear if the ActualLength field of this structure has to include
string length + 4 bytes for its own. I’m assuming a UNICODE_NULL is
included in it too. I have tried all permutations here and none seem to
work.
The documentation seems pretty clear:
*ActualLength*
The size of the entire data structure in bytes.
So, if you have a string that is 3 characters long, ActualLength would
be 12 (4 + 3*2 for the string + 2 for the zero terminator).
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Pankaj Garg[SMTP:xxxxx@panologic.com]
Reply To: Windows System Software Devs Interest List
Sent: Monday, January 07, 2008 8:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME
Also I’m supposed to fill in USB_HUB_NAME structure with this name. It
unclear if the ActualLength field of this structure has to include
string length + 4 bytes for its own. I’m assuming a UNICODE_NULL is
included in it too. I have tried all permutations here and none seem to
work. May be my symbolic name format is wrong.
I’ve experimented with these IOCTLs in the past but unfortunately removed all the code as I found different solution for my problem. What I remember is sometimes things were a bit different that docs and comments in headers say in the way how parameters and results are passed. I’m not sure for what IOCTLs as I experimented with the lot of them. Also not all IOCTLs work on all OS versions but it shoudln’t influence you.
I’d recommend to write a simple client code using these IOCTLs and test it with standard USB drivers. When it works return the same results as OS drivers do. It should be easy as I presume you have already written client drivers for testing your bus driver.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
>I’m failing in this step here (i.e. after I return a controller name, I
don’t get anything after that). I’m confused about what to send as
controller name.
Try this on MS’s HC driver and see the results.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
It was part of my original message.
??\PCI#VEN_8086&DEV_27CA&SUBSYS_200A17AA&REV_02#3&b1bfb68&0&EA#{3abf6f2
d-71c4-462a-8a92-1e6861e6af2}
It’s now clear to me that this is a symbolic name that is not the same
as symbolic name that you’d use from user mode to open this controller.
From user mode this has to change to a “\.\xxxxx” format.
Now the question is how do I create a kernel mode style symbolic name
for my Bus driver’s FDO?
WdfDeviceCreateSymbolicLink makes a user mode accessible name. (and I
don’t think I need that here).
-pankaj
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Monday, January 07, 2008 4:03 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME
I’m failing in this step here (i.e. after I return a controller name, I
don’t get anything after that). I’m confused about what to send as
controller name.
Try this on MS’s HC driver and see the results.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
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