Raw PDO device visible in Windows 10 user interfaces

Having a lower level filter driver for HID devices using a raw POD device for sideband communication with the user app (, used a Control Device before but that creates PnP issues discussed in this forum, the advice is to use raw PDO devices).

Both pnpCapabilities.NoDisplayInUI and deviceState.DontDisplayInUI of the PDO device are set to WdfTrue (see code below).
As expected the PDO device does NOT appear in the Device Manager (except you turn on “Show hidden devices”), so far so good!

Nevertheless the PDO device is shown in:

  • Windows 10 Settings > Devices > Bluetooth & other devices > Other devices and
  • Control Panel > Devices and Printers > Unspecific.

Googled the web and the OSR forums and could not find a hint of an answer.
How can the PDO device be hidden in any Windows user interfaces?

Any help is really appreciated.
Thanks!

// Plug and Play Settings
WDF_DEVICE_PNP_CAPABILITIES_INIT(&pnpCapabilities);
pnpCapabilities.Removable = WdfTrue;
pnpCapabilities.SurpriseRemovalOK = WdfTrue;
pnpCapabilities.NoDisplayInUI = WdfTrue;
WdfDeviceSetPnpCapabilities(rawPdoDevice, &pnpCapabilities);

// Hide it in Device Manager
WDF_DEVICE_STATE_INIT(&deviceState);
deviceState.DontDisplayInUI = WdfTrue;
WdfDeviceSetDeviceState(rawPdoDevice, &deviceState);

I believe it is related to the (class) interface/adapter, not the PDO/FDO.
Windows retrieves the adapters by enumerating the interfaces. (IoGetDeviceInterfaces)

Well, that sort-of begs the question of whether you register a device interface, and if so, WHICH device interface.

I was also going to ask what Device Type you’re using…

Peter

@ThanksBerkan + @Peter
Thank you for trying to help, much appreciated!

Yes it’s the device interface of the PDO which is showing up in Windows UIs, more precisely the text which was set with WdfPdoInitAddDeviceText().

The actual code is same as in KbFiltr > RawPdo.c from the WDF examples.

Just tested the KbdFilter example and it also shows the device interface of the PDO in the Windows 10 UIs (but not in DeviceManager).

@Peter
Not really sure what you mean with “Device Type”. The actual driver is a HidClass lower filter driver for a keyboard. The “Device Type” is marked as such in EvtDriverDeviceAdd with:

WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_KEYBOARD);

For sideband communication with the user app the keyboard device creates a raw PDO device with a device interface, same as the KbFiltr example. That device interface is shown to the user, but it is needs to be hidden as it has no value to the user and only creates confusion.

So, to make my question more precisely: Is there a way to hide a “device interface” from the Windows 10 UIs?

PWilly

How about just not registering the device interface for your PDOs. This is effectively a private device object that you’re using. Just don’t call WdfDeviceCreateDeviceInterface. Open the device from your app(s) by name. Problem solved.

Peter

1 Like

Thanks Peter for your suggestion. Unfortunately I believe it’s not that simple.

  1. There can be multiple instances of the device. The device interface is needed to enumerate all current instances via SetupDiEnumDeviceInterfaces() in the user app at startup to get the actual device paths to open all PDOs for sideband communication. If there are other ways to enumerate all instances for a specific PDO DeviceClassGUID let me know.

  2. As it is a PnP device it might come and go at any time. Need the device interface for the user app to register notifications via RegisterDeviceNotification() to receive DBT_DEVICEARRIVAL and DBT_DEVICEREMOVECOMPLETE events for this specific device, which again provides the actual device path to open new devices and close removed devices. If there is any other way to achieve similar notifications without a device interface please let me know.

Best regards
PWilly

Why are you worried about this? Who cares if its visible in uncommon places? Just give it a friendly that lets people know it’s an internal device.

Good question Tim. In short: It’s the support queries we try to avoid.

In long: If customers see that device interface in “Windows 10 Settings > Devices”, which is btw THE COMMON place where you manage your Bluetooth devices, they will wonder why there is another device for that keyboard.

Getting worse, some keyboards can have a Bluetooth pairing while used via USB at the same time. Both USB and Bluetooth devices then have each a device interface, so the user will not see 2 devices (Bluetooth and USB) but 4 devices, even it’s only 1 keyboard. This will eventually create lots of support queries because users will be confused. And these support queries we try to avoid.

Best PWilly

Believe me most users do not care at all about that type of stuff.
Even Windows/Microsoft does not hide its generic keyboard/mouse filter driver.

I agree with @pwilly that, if users aren’t supposed to fool with it, not surfacing the GUID is highly desirable. At OSR we have a saying about such things: “Give them a knob and they will turn it” — it’s just better to not show people stuff they don’t need to see.

In terms of enumerating all the devices, that’s quite easily (if clumsily) solved for named devices with unit numbers. The arrival/departure requirement is harder to solve, and I agree a GUID is the right thing to use here.

Why not use your own device interface GUID (instead of a standard one)… Will this show up in the Windows UI (apologies for being too lazy to try it myself this morning)? You can name it anything and p, assuming it IS listed, it at least will be listed someplace where it’s least likely to confuse the users.

Peter

@Peter Thanks for your support in that matter :smile: The knobs will get noticed by some users and questions will arrive especially if something isn’t working as the user expects. You can even remove the device interface (turn the knob) even it isn’t really removed. BTW, the view from @ThatsBerkan is actually lot’s of visual sugar and does not (unlike the Device Manager) represent what really happens in the system, it’s often more a guess.

Already tried a private GUID, it doesn’t matter. Looks like we have to live with the visible device interfaces as Microsoft has forgotten to take care of the Dont/NoDisplayInUI flags.

Thanks for all your help and suggestions!
Best PWilly

Are you setting surprise remove ok on the PDO? If yes try not setting the property. Perhaps the ui is enumerating device containers and your PDO is showing up a new container.

Bingo @Doron_Holan!

Setting of pnpCapabilities.Removable = WdfFalse; does the trick, then the device interface is finally hidden!
Note: It doesn’t matter how you set SurpriseRemovalOK!

Doran you really made my day, thank you so much :slight_smile: !
Still have to double check if that has side effects but the first tests look very promising.

Best regards
PWilly

WDF_DEVICE_PNP_CAPABILITIES_INIT(&pnpCapabilities);
**pnpCapabilities.Removable = WdfFalse;**
pnpCapabilities.SurpriseRemovalOK = WdfTrue;
pnpCapabilities.NoDisplayInUI = WdfTrue;
WdfDeviceSetPnpCapabilities(rawPdoDevice, &pnpCapabilities);
1 Like