Controlling enablement of a WDDM driver distributed via Windows Update

NTDEV
1

We have developed a WDDM driver based on the Microsoft KMDOD example (https://github.com/Microsoft/Windows-driver-samples/tree/master/video/KMDOD) and it works fine, including installation via dpinst.exe. We currently provide an installer for this driver, providing a copy to customers who wish to use it. However, we are investigating switching to a different distribution model, using Microsoft?s Window Update to distribute the driver. That is, the current installer for our product would remove the installation of our WDDM driver and delegate it to Windows Update, which would (somehow, see below) detect the installation of our product and trigger the installation of our WDDM driver.

Now, our WDDM driver should be enabled only when the rest of our product is installed, and remain disabled otherwise. Currently, our .INF file specifies the driver as being a Display type driver, with a FeatureScore of 0xF6, which ensures that when we explicitly run dpinst.exe or pnputil.exe to install the driver, that our WDDM driver is the one used. The existing devicenode (typically the Microsoft Basic Display Only Driver) gets replaced with our KMDOD-based WDDM devicenode. My understanding is that because of our FeatureScore, and that in our INF models section we specify CC_0300 (VGA), the PnPManager determines that our WDDM driver is the best driver (i.e. better than the MS DOD driver one) and replaces it.

This works well because our product?s installer is explicitly invoking dpinst on our INF file, triggering the driver?s installation. That is, our driver is installed only when our product is also being installed. That?s not the case when distributing the driver via Windows Update. In that case, our WDDM driver is likely to be installed on all WDDM-supporting machines, regardless of whether our product is installed or not. That is, any machine whose display drivers have a FeatureScore higher than the WDDM one of 0xF6 (the MS DoD ones have a FeatureScore of 0xFF) get replaced.

Our INF file has a rather broad target in the Models section, where it looks like:

[COMPANY.NTamd64]
%OUR_WDDM_DRIVER% = KDOD_Install, CC_0300

Obviously we don?t want it installed unless our product is also being installed. How can we control the installation of our WDDM driver? We were hoping to do this by creating a devicenode that uniquely matched our driver, and trigger the driver?s loading via a call to DiInstallDevice. That is, when the installer for our product was running, it would create a devicenode tailored for our WDDM driver, the causing PnPManager to replace the existing Display devicenode with ours. And if/when our product was uninstalled, we would delete this devicenode and the previous display driver would be restored.

I?ve experimented with changing our models section to specify something more specific e.g.

[COMPANY.NTamd64]
%OUR_WDDM_DRIVER% = KDOD_Install, PCI\VEN_1234&DEV_0001&CC_0300

However this simply created a sibling devicenode, so there were now two Display devicenodes, one being ours, and the other one belonging to MS DoD (there was also a problem with our device node not being recognized though). As an experiment I tried manually deleting the MS DoD device node, leaving just our WDDM device node, but if I triggered a ?Scan for hardware changes? then the MS DoD driver devicenode gets reintroduced.
I think either my strategy (and possibly execution) for solving this problem is invalid.

Is it indeed possible to distribute a miniport KMDOD driver via Windows Update and control exactly when it gets installed? If so, how does one do this?

Many thanks in advance for any help you may be able to provide.

2

Install via WU is controlled entirely by hardware id match. You can’t publish a driver that matches on a compatible id. You can’t control when Wu installs your driver based on if other software is installed. Your only only choice is to have your software create a new dev node which you can match on (don’t use a pci if)

Bent from my phone

From: xxxxx@lists.osr.com on behalf of xxxxx@teradici.com
Sent: Monday, June 12, 2017 6:23:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Controlling enablement of a WDDM driver distributed via Windows Update

We have developed a WDDM driver based on the Microsoft KMDOD example (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FWindows-driver-samples%2Ftree%2Fmaster%2Fvideo%2FKMDOD&data=02|01|Doron.Holan%40microsoft.com|f98ee6100fc04c09e57108d4b1fae35e|72f988bf86f141af91ab2d7cd011db47|1|0|636329138497868137&sdata=NB3kDet1Lyz9sQaju5FkBD9KJxuoBmmvAc8GvjLgQ7A%3D&reserved=0) and it works fine, including installation via dpinst.exe. We currently provide an installer for this driver, providing a copy to customers who wish to use it. However, we are investigating switching to a different distribution model, using Microsoft?s Window Update to distribute the driver. That is, the current installer for our product would remove the installation of our WDDM driver and delegate it to Windows Update, which would (somehow, see below) detect the installation of our product and trigger the installation of our WDDM driver.

Now, our WDDM driver should be enabled only when the rest of our product is installed, and remain disabled otherwise. Currently, our .INF file specifies the driver as being a Display type driver, with a FeatureScore of 0xF6, which ensures that when we explicitly run dpinst.exe or pnputil.exe to install the driver, that our WDDM driver is the one used. The existing devicenode (typically the Microsoft Basic Display Only Driver) gets replaced with our KMDOD-based WDDM devicenode. My understanding is that because of our FeatureScore, and that in our INF models section we specify CC_0300 (VGA), the PnPManager determines that our WDDM driver is the best driver (i.e. better than the MS DOD driver one) and replaces it.

This works well because our product?s installer is explicitly invoking dpinst on our INF file, triggering the driver?s installation. That is, our driver is installed only when our product is also being installed. That?s not the case when distributing the driver via Windows Update. In that case, our WDDM driver is likely to be installed on all WDDM-supporting machines, regardless of whether our product is installed or not. That is, any machine whose display drivers have a FeatureScore higher than the WDDM one of 0xF6 (the MS DoD ones have a FeatureScore of 0xFF) get replaced.

Our INF file has a rather broad target in the Models section, where it looks like:

[COMPANY.NTamd64]
%OUR_WDDM_DRIVER% = KDOD_Install, CC_0300

Obviously we don?t want it installed unless our product is also being installed. How can we control the installation of our WDDM driver? We were hoping to do this by creating a devicenode that uniquely matched our driver, and trigger the driver?s loading via a call to DiInstallDevice. That is, when the installer for our product was running, it would create a devicenode tailored for our WDDM driver, the causing PnPManager to replace the existing Display devicenode with ours. And if/when our product was uninstalled, we would delete this devicenode and the previous display driver would be restored.

I?ve experimented with changing our models section to specify something more specific e.g.

[COMPANY.NTamd64]
%OUR_WDDM_DRIVER% = KDOD_Install, PCI\VEN_1234&DEV_0001&CC_0300

However this simply created a sibling devicenode, so there were now two Display devicenodes, one being ours, and the other one belonging to MS DoD (there was also a problem with our device node not being recognized though). As an experiment I tried manually deleting the MS DoD device node, leaving just our WDDM device node, but if I triggered a ?Scan for hardware changes? then the MS DoD driver devicenode gets reintroduced.
I think either my strategy (and possibly execution) for solving this problem is invalid.

Is it indeed possible to distribute a miniport KMDOD driver via Windows Update and control exactly when it gets installed? If so, how does one do this?

Many thanks in advance for any help you may be able to provide.

—
NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

3

On Jun 12, 2017, at 6:23 PM, xxxxx@teradici.com wrote:

Now, our WDDM driver should be enabled only when the rest of our product is installed, and remain disabled otherwise.

What’s the point of that? There’s no benefit in user experience. You might as well install your driver with the rest of your product and skip Windows Update.

Obviously we don?t want it installed unless our product is also being installed.

It’s certainly not obvious to me. Why? What is the gain, either to you or to the user?
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

It looks like the modified WDDM driver works (in some degree) on all
possible hardware (as long as the display adaptor’s compatible IDs contain
PCI\CC_0300), and OP is trying to narrow down the driver installation such
that it only install on certain devices (eg. PCI\VEN_1234&DEV_0001&CC_0300).

So questions comes to my mind:

  1. Is the driver targeted to only specific hardware or it is targeted to
    all display cards? In general MS only allows vendor driver to match against
    specific hardware models , instead of a class of devices. (eg. Hardware Ids
    matching vs Compatible Ids matching). I guess that the OP’s intention is to
    install this particular driver against certain hardware model, otherwise it
    is something that MS get frown upon.

  2. Assuming that the driver is targeted to specific hardware model, then
    the question is more easy to cope with. OP said that the driver is
    sensitive to the order of the product installation. Then we can help to
    attack the timing sensitive issue using various OS equipped measure (eg.
    PNP stuff). Theoretically, a driver should be designed so that it works
    good in all condition.

2017-06-13 14:42 GMT+08:00 Tim Roberts :

> On Jun 12, 2017, at 6:23 PM, xxxxx@teradici.com wrote:
> >
> > Now, our WDDM driver should be enabled only when the rest of our product
> is installed, and remain disabled otherwise.
>
> What’s the point of that? There’s no benefit in user experience. You
> might as well install your driver with the rest of your product and skip
> Windows Update.
>
>
> > Obviously we don?t want it installed unless our product is also being
> installed.
>
> It’s certainly not obvious to me. Why? What is the gain, either to you
> or to the user?
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

5

yes indeed “make available from windows update” and “only if our product is
installed” are incompatible requirements.What is the motivation for this?

Mark Roddy

On Tue, Jun 13, 2017 at 2:42 AM, Tim Roberts wrote:

> On Jun 12, 2017, at 6:23 PM, xxxxx@teradici.com wrote:
> >
> > Now, our WDDM driver should be enabled only when the rest of our product
> is installed, and remain disabled otherwise.
>
> What’s the point of that? There’s no benefit in user experience. You
> might as well install your driver with the rest of your product and skip
> Windows Update.
>
>
> > Obviously we don?t want it installed unless our product is also being
> installed.
>
> It’s certainly not obvious to me. Why? What is the gain, either to you
> or to the user?
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

6

Thank you all for your quick replies, much appreciated. Let me clarify my question with some more motivating details.

Our product involves displaying a Windows desktop remotely, and the WDDM driver is the portion that grabs the pixels of the desktop to assist in this. There isn’t any actual hardware associated with this driver, and indeed the anticipated targets are primarily virtual machines. Because there’s no physical card being plugged in to activate our WDDM driver, I’m looking to create the appropriate devicenode via a small program which runs when we install our software.

The reason for distributing our software via Windows Update rather than continue to explicitly install the driver (via dpinst or pnputil) is that our driver can currently be overwritten after major Windows updates. For instance, if our software is installed on Windows 1607, and the user then updates from Windows 1607 to 1703, our WDDM driver will be uninstalled and replaced with the Microsoft Basic Display Only Driver. Currently our customers must then re-install our software, which for large fleets is undesirable. Well, it’s undesirable in general but even more of a pain-point the more customers there are. If our driver is distributed via Windows Update we *think* (to be confirmed by us once we get all the pieces working) that our driver would remain installed on the system.

There is also the ancillary benefit of distributing any driver fixes (should they be needed) without requiring our customers to perform upgrades they might not otherwise need to.

7

If you can have the VM enumerate your WDDM device node with a unique hardware ID, you can get the targeting you desire

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@teradici.com
Sent: Tuesday, June 13, 2017 10:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Controlling enablement of a WDDM driver distributed via Windows Update

Thank you all for your quick replies, much appreciated. Let me clarify my question with some more motivating details.

Our product involves displaying a Windows desktop remotely, and the WDDM driver is the portion that grabs the pixels of the desktop to assist in this. There isn’t any actual hardware associated with this driver, and indeed the anticipated targets are primarily virtual machines. Because there’s no physical card being plugged in to activate our WDDM driver, I’m looking to create the appropriate devicenode via a small program which runs when we install our software.

The reason for distributing our software via Windows Update rather than continue to explicitly install the driver (via dpinst or pnputil) is that our driver can currently be overwritten after major Windows updates. For instance, if our software is installed on Windows 1607, and the user then updates from Windows 1607 to 1703, our WDDM driver will be uninstalled and replaced with the Microsoft Basic Display Only Driver. Currently our customers must then re-install our software, which for large fleets is undesirable. Well, it’s undesirable in general but even more of a pain-point the more customers there are. If our driver is distributed via Windows Update we think (to be confirmed by us once we get all the pieces working) that our driver would remain installed on the system.

There is also the ancillary benefit of distributing any driver fixes (should they be needed) without requiring our customers to perform upgrades they might not otherwise need to.

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

8

> If you can have the VM enumerate your WDDM device node with a unique hardwa=
> re ID, you can get the targeting you desire

Yes, that does seem to work. From your initial response

Your only only choice is to have
> your software create a new dev node which you can match on (don’t use a pci if)

I tried a different Hardware ID based on ACPI. That is, I used a model specification like:

[COMPANY.NTamd64]
%OUR_WDDM_DRIVER% = KDOD_Install, ACPI\1234&DEV_0001 , CC_0300

(where our company vendor id would be something like 1234)

That does indeed create a device node and trigger the load of our WDDM driver. Event logs confirm the driver is loaded. Of the various hardwareIDs, ACPI seems the least inconsistent with a display driver for a virtual machine (the other options being things like USB, IDE, 1394, PMCIA etc), so that’s what I picked–would there be a better choice?

Unfortunately, the driver is stopped (code 31), and I can see that the DriverUnload callback is being invoked. sc query reports an error code of 1077, indicating that the driver was not loaded i.e. it looks like we started loading the driver, but then failed before loading was complete.

As mentioned, the miniport driver is no longer functioning. Not sure if it is a red herring (or a symptom rather than the cause), but when I look at the device stack for the working version of our WDDM driver (i.e. the one where we normally use dpinst to install it) I see

\Driver\OurKMDODdriver
\Driver\pci

whereas now, with the ACPI-based devicenode, the driver stack is

\Driver\PnpManager

Basically, I’m wondering if the driver on top of which the WDDM miniport driver is installed is able to implement the required functionality, or perhaps there are ACPI-specific requirements that are not being met by the WDDM driver?
There are comments in https://github.com/Microsoft/Windows-driver-samples/tree/master/video/KMDOD to the effect that we must load the WDDM driver on an WDDM 1.2 compliant driver, and I’m not quite sure that is happening when triggering the WDDM driver load by creating an ACPI devicenode.

Again, I apologize for the newbie questions and appreciate your feedback.