A funny thing happened on the way to the keyboard

So as I was crafting some UMDF HID driver code for your consumption, and I was working with one of you (and you know who you are *g*) during some of that time frame, we sort of discovered everything already exists between my earlier blog posts and some of the WDK samples.  So rather than reinvent the wheel and the internal combustion engine, let’s just dump all that information in a blog post.

First up, I touched upon secure HID stacks and how to get your UMDF HID Collection Filter driver working in them and a little on how to use impersonation.  And in retrospect, the 30 second and little technical extension in that post are really all that was / is required for getting a basic driver up and running.  Make a note that not all HID stacks require secure connection, so you kind of have to do some debugging or digging around to determine those requirements for your own driver.  Sorry. :) 

The second part was to alleviate the issues with Windows session spaces in order to access some Win32 desktop APIs.  As one of the driving forces to craft a HID Collection filter in UMDF is to have access to those APIs, that session work around is vital.

The last part is proper implementation required for a secure HID stack is using IImpersonateCallback::OnImpersonate method and its invocation from the IWDFIoRequest::Impersonate method.  Turns out one of the existing samples available in the WDK has a really good implementation; src\usb\osrusbfx2\umdf\fx2_driver\impersonation\

Put all that together and you can easily craft a HID collection filter driver for the majority of HID devices. Remember though, UMDF cannot be used to filter keyboard and mouse collections.  But you can go crazy writing drivers for a load of other HID devices.

As always, feel free to ask me questions if you run in to any road blocks.

Now Playing – Rush Show Don’t Tell

Comments (4)
  1. Baggiz says:


    I have run into a huge road block and need some advice πŸ˜‰ Hope it's OK to ask it here πŸ™‚

    The problem is a software only UMDF driver which acts as a virtual serial port using sockets in the other end. Sort of extending two serial ports over the Internet. The driver itself is working fine. The problem is the installation of the driver. It only works if one struggle through the long winding manual add new hardware wizard, but the boss wants it to be a simple installation file πŸ˜‰

    I have tried lots of ways, including 'devcon.exe', 'dpinst.exe', a Wxi project, some SetupAPI code, all in vain. It seems to either fail on the methods expecting some PnP hardware being plugged in or no COMx gets created.

    I have read that version 1.9 supports 'IWDFDevice2::CreateSymbolicLinkWithReferenceString()

    '  and also the interface 'IWDFPropertyStoreFactory' which both seem to address a similar problem. But I don't understand how the driver could create a 'COMx" link if I can't install it programmatically in the first place?

    So the question is, how to programmatically install a software only virtual serial port UMDF driver in order to eliminate the manuel multi step hazzle?

    Thanks in advance!


  2. Baggis says:

    I wrote a comment and it vanished into the air!! Hmmm….!

  3. Baggis says:

    Trying once more to get the original comment into the system…

    Since no answer has come I will answer the question myself: πŸ™‚

    The important thing was to use same Hardware Id in both the INF file and in the API calls(like UpdateDriverForPlugAndPlayDevices and SetupDiSetDeviceRegistryProperty). Maybe it's obvious to some of you, but to me it wasn't πŸ˜‰

  4. pat.man says:

    Apologies Jan!

    I never got mail saying there were comments posted. (d'OH!).  In the future, the fastest and generally best way to ask me a question is to use the "Email Blog Owner"  That goes straight to an inbox I can't avoid. πŸ™‚

    Glad you were able to find the solution!

Comments are closed.

Skip to main content