The only solution I know that gives the exact behavior of production WHQL
signed drivers on W2K3 is to use WHQL test signing. I worked on a virtual
I/O product where nic and storage devices were dynamically created on a
virtual bus. Part of the QA was to dynamically add and remove devices many
times from scripted tests. Scripted tests included scenarios like migrating
workloads along with their virtual I/O devices between physical servers, so
having to manually click on a found new hardware dialog on the destination
machine was exceedingly painful. These migration tests might runs thousands
of cycles (or across a dozen QA machines at once) with dozens of virtual
devices, so that would be a lot of clicking ok on a dialog if done manually.
An ugly workaround that helped QA before was: you can have a class
coinstaller for your device class that changes the ranking field of the
device under test. If you look at the setup API’s, there is a structure that
contains the driver ranking, and I believe the high bit means unsigned. It
is possible to update this ranking field to indicate the driver is signed,
which has the effect of bypassing the found new hardware dialog (during
client side install only, server side install will always fail due to no
WHQL signature). This ranking hack was reported to Microsoft as a security
bug a while ago, so may no longer work (their analysis was it was low risk
anyway). This also does not bypass the requirement to have an administrator
logged into the console. This also alters the actual behavior from what a
real system would do as real signed drivers will successful do server side
installs, so is a limited solution for later QA stages.
Another QA workaround I’ve see is to write an application that periodically
scans for (like every 10 seconds) the found new hardware dialog box (by
reading back the window title of every window), and if it finds it, sends
the correct events to the dialog controls to satisfy it. Using one of the
window spy utilities will help you figure out the child control id’s to send
messages to.
I believe the dtm test client can install unsigned drivers on W2K3, so some
reverse engineering might figure out the voodoo it uses, although it might
require using some component that’s part of the dtm client. You could use
dtm to run custom test scripts, and just get the benefit of it’s capability.
Dtm I believe was expected to be used to run IHV tests in addition to WHQL
tests, although most places doing automated QA that I’ve seen have their own
QA automation environment.
Another strategy might be to write a scripted interface to the WHQL website
than can submit a new build for test signing automatically. If you don’t do
that many builds for QA, just manually getting the WHQL test signature is
also an option. WHQL test signatures I believe are the only QA solution I’ve
seen that can successfully do server side installs with no logged in
administrator.
Some of these workaround may be days (or more) of programming, so you would
need to balance the pain of manually getting WHQL test signatures against
the cost of some more automated solution. You can also get people a little
less expensive than kernel developers to walk new QA builds though the WHQL
test signing workflow. There isn’t an easy fix if you really want to do
extensive QA on W2K3.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-404165-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, March 05, 2010 9:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver test signing on Win 2003.
I do sign my drivers for release. The problem is that I want to test
sign them for QA . 
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer