How does Windows know which UMDF driver to load when a device connects?

[Ranju V]

Hi,

I am just getting started with learning driver development with UMDF and
everything seems fairly straightforward enough but I am still kind of
puzzled on how exactly the driver gets loaded, i.e. how does the system know
which UMDF driver to load when a new device hot-plugs to the system? Is it
that it gets loaded for all devices but is expected to query the device to
verify that it is the right one? I am looking to write a "bridge" driver
for a Bluetooth HID device using UMDF and was wondering if the framework can
somehow trigger the loading of the driver automatically when the OS pairs
with the device. Thoughts?

Thank you!

--
Ranju. V
http://blogorama.nerdworks.in/
--

[Don Burn]

The driver's INF file associates a devices hardware ID with a driver for
function drivers, and the INF file associates a filter driver with either a
particular device or a class of devices (such as all disks). Take a look
at http://msdn.microsoft.com/en-us/library/ms790220.aspx for information on
INF files.

--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"Ranju V" <avr...@gmail.com> wrote in message
news:C5386333-2B74-4AE3...@microsoft.com...

> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4720 (20091227) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4720 (20091227) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Maxim S. Shatskih]

> which UMDF driver to load when a new device hot-plugs to the system?

This is done the same way for all drivers, UMDF and not. This is called PnP.

When the device arrives, the OS tries to find the devnode registry key (it's name is derived from the device's hardware IDs). If it is found - then the driver name is there.

Otherwise, the OS creates the new devnode registry key. In this case, the control is passed to user-mode PnP service to do the driver installation for the new devnode.

The user-mode PnP service scans the INF files present on the machine and finds a hardware IDs match. On a match, the INF is executed for this particular devnode, and the driver name is set there.

--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com

[Ranju V]

Thanks for your replies Don and Maxim. I did some reading on INF files and
driver installation as directed and discovered that the link between the
driver and the device is specified via the "Model" section using a device
ID or a hardware ID. So when a PnP device plugs in with the OS, the
hardware installation system scans the installed INFs (if the driver hasn't
been associated with that device already) looking for one where the
device/hardware ID matches with the ID reported by the device on the bus.
If it finds one then it associates that driver for that device and if it
doesn't then it further explores to see if a generic class level driver can
be used instead. I was hoping to write a UMDF driver for the Windows 7
Sensor platform for a Bluetooth HID device and was wondering if it can be
loaded whenever the device pairs with the system. To test this out I
quickly built the sample skeleton sensor driver from the DDK and tweaked the
INX file to use a hardware ID (like this: HID\VID_1234&PID_5678). I was
thinking that the system would somehow figure out that my UMDF driver needs
to be stacked on top of the Bluetooth HID driver for accessing this device -
that it would show up as my custom device in the Bluetooth devices control
panel.

After tussling with "devcon" a bit (turns out I was using the 32-bit version
of devcon on my 64-bit Win7 system which is a strict no-no; not that the
error message "devcon failed" was very helpful!) I managed to get the driver
installed and it showed up just fine in the Sensors control panel. I
noticed that the driver got loaded as soon as I installed it. The OS didn't
seem to know anything about this driver when I next paired the device (after
removing it from the system first) - it continued to show up as a Bluetooth
HID device. In retrospect this makes sense and I assume specifying the
hardware ID using the HID enumerator (HID\VID_1234&PID_5678) will cause the
Bluetooth HID driver to be stacked below the sensor driver. I'll test this
out soon and see how it goes.

Thanks again!