UpdateDriverforPlugAndPlayDevices driving me crazy!

NTDEV
1

Hi folks,

I’m, trying to improve the “silent install” capabilities of our driver
package. Currently it works well enough for customer release, but I’m
wanting to do a fully automated silent install in all cases for our
internal automated test facilities - and I’ve come up against a problem.

Our device co-installer keeps a ref-count of installed physical devices
on the system. When there are physical devices in the box, we create a
root-enumerated dev-node, and install the driver for it.

On the whole, it generally works well. Our drivers are authenticode
signed (but not WHQL signed, because they’re internal test drivers -
automatically built, loaded and tested). For most versions of windows
that we test on, the silent install works, provided we install our
root-test signing certificate, and set the driver signing config on the
machine appropriately (i.e. test signing allowed).

However, on Win2k3, there are several problems:

  1. If we have a device coinstaller, even though it doesn’t present any
    UI, we can’t do true silent installation or uninstallation.

  2. Using DPInst we set the “supress wizard” option. The supress wizard
    mode stops the pages appearing as a result of the install.
    Unfortunately, if “add hardware” wizard is already present, then the
    supress-wizard mode (which is not a quiet install) blocks, in the same
    way that all “noisy” installs block, to allow the GUI component of the
    install to complete.

  3. This is specifically a problem with our test framework because (as a
    result of uninstall issues (1)) the framework tends to clean out the
    previous install using “devcon remove”, and “pnputil -d”. It then does a
    “devcon rescan”, to get our PCI devices to be re-detected, but
    unfortunately, this causes the wizard to appear, and any subsequent
    attempts to install the drivers block until a user intervenes.

For OS’s after 2k3, we can turn test signing mode on, make our code
signing certificate trusted, and it all just “works magically”. How do
we do this for 2k3? Absolutely any and all hacks accepted - this is for
internal test use only - we could even go as far as automating debugger
intervention to set flags / memory if necessary (although it would be a
pain!).

MH.

2

> For OS’s after 2k3, we can turn test signing mode on, make our code

signing certificate trusted, and it all just “works magically”. How do
we do this for 2k3? Absolutely any and all hacks accepted - this is for
internal test use only - we could even go as far as automating debugger
intervention to set flags / memory if necessary (although it would be a
pain!).

One solution is to install the test root certificate in the local machine
trusted root certificate store and then get your drivers test signed by
WHQL. This will allow a server side install to run. This is not useful for
production. The actual test root certificate is hard to find, and the best
source I’ve found is to export it from a system where it’s already installed
(often systems running beta Microsoft OS components and perhaps an
unattended install/sysprep’ed system with the test root activated). Test
signing by the WHQL web site is a manual process (and seems to take a couple
hours in a processing queue), which as far as I know can’t be automatically
done by a build script. This method is not so useful for things like
automatic daily regression tests against a daily build (although I suppose
it might be possible to write scripts that log into the WHQL site, submit
the right data via https and then retrieves it a few hours later). It would
be nice of you could get a short term local signing certificate (which you
have the private keys for), signed by with the WQHL test root, that allowed
you to do automatic test signatures during a build without a round trip to
the WHQL site every day.

Another possibility is: my understanding is the requirement for WHQL
signatures under W2K3 ONLY applied for devices in classes with a WHQL device
class. So, if your device can be put it a custom class, you can Authenticode
sign it, and add your root to the trusted roots, and presto you get sever
side silent install. I’ve personally never successfully made this work, but
I’ve read it’s supposed to. Just yesterday, I was browsing one of the MSDN
entries on drivers signing, and it suggested this silent install of
Authenticode drivers only worked on x64 platforms.

There are ugly ways to make sort of silent installs happen for non-WHQL
signed drivers during testing. One way is you have a little application
sitting in the background (probably on a logged in admin local console
session) that periodically scans for the “found new hardware” dialog window,
and when it sees it, it sends some keystrokes to deal with it. I know of
some other strategies to prevent the found new hardware dialog, although
none are perfect and none allow the desired server side install.

I suppose there might be some really ugly hacks that involve patching the
crypto api or signing validation dll from a kernel driver (or injected a
user mode dll), although I personally feel going down these kinds of paths
to solve a problem is generally a really bad idea. If the success of your
business depends on it (and hundreds of peoples jobs and millions of dollars
of investor’s money are on the line), what’s right/elegant/proper/accepted
may get overridden by the end result you have to achieve. I’ve seen a number
of really ugly hacks in production products, sometimes by very respectable
companies.

It would be REALLY nice if Microsoft would back port the signing policy
logic of Vista (and W2K8) to W2K3.

It is also possible to get unclassified device WQHL signatures for devices
that would normally be in a WHQL device class. The requirements for the
unclassified signature are less stringent than normal signatures, and don’t
allow use of a WHQL certified logo, but do allow silent server side install.

If you have control over the underlying bus (like it’s a virtual bus) a
slightly ugly hack is to make the device have a compatible id of some bogus
device (like a no driver system device, or possibly a custom class with
Authenticode signatures). You then have an app that notices when your device
is installed with this bogus drivers and then reinstalls the correct one.
This strategy has some problematic cases (like synchronization between the
PnP system and your driver fixup app when devices dynamically come and go a
lot).

The solutions in Vista and W2K8 help a lot.

Jan

3

Jan Bottorff wrote:

One solution is to install the test root certificate in the local machine
trusted root certificate store and then get your drivers test signed by
WHQL.

Yep - I’m aware of this option, and we’ve batted the idea around a
little bit.

This method is not so useful for things like
automatic daily regression tests against a daily build (although I suppose
it might be possible to write scripts that log into the WHQL site, submit
the right data via https and then retrieves it a few hours later).

Okay - that’s what I suspected. Unfortunately, automatic regression
testing is precisely what we’re doing.

Generally we attempt to do things more frequently than daily: we have a
“change follower” which keeps track of all commits to certain branches
in the tree, and the moment anyone commits into the codebase, then jobs
get scheduled to start automatically building and testing the new
version. If we got it to automatically submit builds to the WHQL site, I
suspect it would end up submitting 30-50 per day, which is somewhat
excessive!

It would
be nice of you could get a short term local signing certificate (which you
have the private keys for), signed by with the WQHL test root, that allowed
you to do automatic test signatures during a build without a round trip to
the WHQL site every day.

Exactly. A daily turnaround is a bit slow for us: we like being able to
scroll back through a nicely formatted list of commits and see where the
“sea of green ticks” gets replaced with the “sea of red crosses”, which
allows us to pinpoint exactly where things got broken.

Having said that, for things like release candidates, WHQL test signing
may be a viable option.

Another possibility is: my understanding is the requirement for WHQL
signatures under W2K3 ONLY applied for devices in classes with a WHQL device
class. So, if your device can be put it a custom class, you can Authenticode
sign it, and add your root to the trusted roots, and presto you get sever
side silent install. I’ve personally never successfully made this work, but
I’ve read it’s supposed to. Just yesterday, I was browsing one of the MSDN
entries on drivers signing, and it suggested this silent install of
Authenticode drivers only worked on x64 platforms.

Okay - I’ll look into this - it may be worth creating a tree with
“hacked device classes” to see if I can get this to work. We could
probably cook something up that built a “modified device classes”
codebase for the purposes of daily regression, and it might be OK to
drop the 2k3-32 target provided we could test on x64.

There are ugly ways to make sort of silent installs happen for non-WHQL
signed drivers during testing. One way is you have a little application
sitting in the background (probably on a logged in admin local console
session) that periodically scans for the “found new hardware” dialog window,
and when it sees it, it sends some keystrokes to deal with it. I know of
some other strategies to prevent the found new hardware dialog, although
none are perfect and none allow the desired server side install.

I suppose there might be some really ugly hacks that involve patching the
crypto api or signing validation dll from a kernel driver (or injected a
user mode dll), although I personally feel going down these kinds of paths
to solve a problem is generally a really bad idea.

Well … if that particular piece of hackery never left the bulding
we’re in, then I think we’d call it an “acceptable testing compromise”.

It is also possible to get unclassified device WQHL signatures for devices
that would normally be in a WHQL device class. The requirements for the
unclassified signature are less stringent than normal signatures, and don’t
allow use of a WHQL certified logo, but do allow silent server side install.

This sounds very promising. How does it work?

If you have control over the underlying bus (like it’s a virtual bus) a
slightly ugly hack is to make the device have a compatible id of some bogus
device (like a no driver system device, or possibly a custom class with
Authenticode signatures).

We have control over the underlying bus for some of the devices, but
unfortunately not all of them (PCI and root enumerated devices), so this
won’t work for us :frowning:

Many thanks for your help.

MH.