How to test for presence of non-HID USB device?

[Dean Roddey]

Ok, I'm a little stumped here. I want to test for the presence of certain
devices during the installation of our product so that I can automatically
install support for them. One of these currently (and probably more of them
in the future) is a non-HID USB device. I can handle HID devices easily
enough, but if HidD_GetAttributes() only works for HID devices, how does one
get the vendor/product id of a non-HID device? We are warned specifically
not to parse the device path to get this stuff, so what is the generic equiv
of HidD_GetAttributes?

Without something of this sort, I can't even see how vendors themselves
would find their own devices, right?

-------------------------------------
Dean Roddey
The Charmed Quark Controller
www.charmedquark.com

[Tim Roberts]

"Dean Roddey" <dro...@charmedquark.com> wrote:

>Ok, I'm a little stumped here. I want to test for the presence of certain
>devices during the installation of our product so that I can automatically
>install support for them. One of these currently (and probably more of them
>in the future) is a non-HID USB device. I can handle HID devices easily
>enough, but if HidD_GetAttributes() only works for HID devices, how does one
>get the vendor/product id of a non-HID device? We are warned specifically
>not to parse the device path to get this stuff, so what is the generic equiv
>of HidD_GetAttributes?
>
>Without something of this sort, I can't even see how vendors themselves
>would find their own devices, right?

Generally, the driver for such a device creates a device interface during
AddDevice processing, and applications search for the GUID using the
SetupDi functions.

If you don't know the device interface GUID for the devices you need to
find, and you don't actually need to talk to their drivers, I don't see
anything wrong with trolling the registry for VIDs and PIDs. Yes, it's
possible that the device path stuff will change for Longhorn, but that's
still a LONG ways away.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc

[Dean Roddey]

I know the GUID, the problem is getting the vendor/product ids for the
devices during the interation. For HID devices there is a 'get attributes'
call to get that info, given the path you get duirng iteration, but how do
you do it for a non-HID device?

"Tim Roberts" <ti...@probo.com> wrote in message
news:137dp0h45rtu3svfl...@4ax.com...

[Doron Holan [MS]]

there is no generic documented mechanism to get the VID/PID of any device
plugged in

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.

"Dean Roddey" <dro...@charmedquark.com> wrote in message
news:ePPlVWe...@TK2MSFTNGP11.phx.gbl...

[Dean Roddey]

Well that sucks pretty loudly. I understand that if you don't know what the
device is you have no business talking to it, but checking for its presence
is clearly a legitimate operation that many applications would want to do.
In our case we have a driver that does understand the device, but the
installer itself cannot load these drivers because it's installing the
infrastucture that supports them (which is one of a set of services that get
installed.) So the installer wants to check just for the presence of the
device so that it can inform the user that it knows that device X is present
and ask if they want to install a driver for it.

"Doron Holan [MS]" <dor...@nospam.microsoft.com> wrote in message
news:%23ey2CZq...@TK2MSFTNGP14.phx.gbl...

[Dean Roddey]

But wait, I don't need to find out what the vendor/product id is, I need to
know if a device with a known vendor/product id is present. Surely people
who write drivers for their own devices must be able to find them via their
known ids, right?

"Doron Holan [MS]" <dor...@nospam.microsoft.com> wrote in message
news:%23ey2CZq...@TK2MSFTNGP14.phx.gbl...

[Tim Roberts]

"Dean Roddey" <dro...@charmedquark.com> wrote:
>
>But wait, I don't need to find out what the vendor/product id is, I need to
>know if a device with a known vendor/product id is present. Surely people
>who write drivers for their own devices must be able to find them via their
>known ids, right?

No, actually. That's all handled by the plug-n-play subsystem, which looks
up the VID/PID in the INF file database and automatically loads the
appropriate driver. The driver for a USB device can fetch the device
descriptor to determine the exact VID/PID, if it needs to.

It would be unusual for an end-user to tolerate a device that has no
driver, what with all the confusing warnings and such.

Can you describe your use case in a bit more detail? I'm sure there must
be a way to solve your problem, but we're only seeing one narrow view.

[Dean Roddey]

Our product is a very large control and automation system named CQC
(www.charmedquark.com). It is a highly network distributed system, and there
is an 'app shell' that runs as a service and in turn manages one or more
other back end servers according to configuration. Among them is a driver
server which loads up drivers (our kind of drivers, which make all
controlled devices look conceptually the same) and distributes control of
those devices to any other CQC applications. We can control pretty much any
kind of devices as long as it provides some sort of control mechanism.

During installation, long before any of that huge back end is up and
running, we want to auto-sense as many devices as possible and has them be
automatically loaded without the user having to manually load them up, by
leaving a file for the driver server to see when it first loads. Since our
produce is completely open ended and third parties can do drivers, there is
no way we can hard code our installer to do this kind of checking
specifically for all devices. So it must be something that can be done
generically, using information in the 'driver manifest file' which is an XML
file that describes each driver.

So, for instance, it would be straightforward to have a driver manifest file
list a set of criteria that need to be checked to see if it's device is
present, such as "see if foobar.dll is the path" or "see if USB device
vid/pid" is present or "send broadcast packet XXXX to port Y and see if you
get response ZZZ" or "Send IOCTL X and see if you get response Y" and so
forth. It has to be that generic in order for this to really be feasible
because of the huge breadth of devices that can be involved. It would be
very hard, OTOH, to say "Load up DLL X and call function foobar with
parameters of this type" because those types could be anything.

There is a considerable amount of infrastructure involved in the driver
system, since it is heavily multi-threaded and runs in an instance of our
object server and it has significant interactions with management logic in
that object server. So we don't want to have to try to load up drivers
within the installer. And we also don't want to put any more burden on the
writers of device drivers to support auto-discovery mechanisms in the driver
code, since it is already too complex for many people. So it would be far
and away better if it could be done via the generic manifest file hints
scheme.

Anyway, that's basically the deal.

"Tim Roberts" <ti...@probo.com> wrote in message

news:794jp0db9k0k8bohd...@4ax.com...

[V.V....@nospam.com]

You may envisage registry mining:
Check
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\
and then the path of the device itself. If the device has actually been
attached and detected
by Windows PnP manager, there should be a key named "Control".
If not, the "Control" key is not present.

for instance, currently no control key for the device
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&Ven_Fujifilm&Prod_USB_Drive&Rev_3.04\020343122B00AF04&0
in my laptop's registry: This device is NOT attached to the USB bus and
has not been detected
by PnP manager.
OTOH, the device
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_03f0&Pid_1016\5&344cc669&0&2
has been detected by PnP.

A drawback with this method at this point:
If the device is removable and has been attached to the PC and then
removed, the
"Control" key stays. The same if the device has been disabled through
Device Manager

BUT

the "control" key stores a value named "ActiveService". This gives you the
name of
the service (device drivers are services) that handles the device.
Then you can open the driver object or you can go on registry mining:
In HKLM\SYSTEM\CCS\Services\<ActiveService>\Enum
there are the list of the instances for said device driver.
And these instance are usually built with Vid and Pid, for instance:
USB\Vid_05fe&Pid_0007\5&344cc669&0&1 for my UsbMouse

Some little tests will let you know figure by yourself if you can
rely on registry mining for your purposes

HTH

V.V.

On Sun, 14 Nov 2004 18:29:10 -0800, Dean Roddey <dro...@charmedquark.com>
wrote:

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Dean Roddey]

Thanks, but I probably wouldn't do that. If there's no blessed way of doing
it, I won't do it. This is a huge system and it's already a burden to keep
it sane and robust over time. So just I don't use hacks of any sort. This is
clearly a hole in the USB support on Windows, and I hope that they will fix
it. There is certainly a legimate reason to at least check that a given
device is present.

<V.V....@nospam.com> wrote in message
news:opshocym...@news.microsoft.com...

[Dean Roddey]

No more ideas?

"Dean Roddey" <dro...@charmedquark.com> wrote in message

news:OaXzyrPy...@tk2msftngp13.phx.gbl...