> So you are saying that if a coinstaller is signed in the .cat and retested with WHQL that it can execute admin only
calls like SetupDiCreateDeviceInfo?
Devnode setup is executed in the PnP Service context (one of the svchosts) and runs under LocalSystem IIRC.
Nevertheless, this procedure is prohibited from displaying any UI (coinstallers are called with the special flag, for instance).
In this case, if any component of the devnode setup procedure (SetupAPI, class installer or coinstaller) cannot continue without showing an UI, then - with this special flag provided - they fail with proper error code.
This failure causes PnP Service to leave the devnode not-fully-set-up till admin will log on. Then, in the interactive context of logged-on admin, the procedure is restarted from its stopping point, with the ability of displaying the UI. The special flag is not used in this case, and coinstallers are allowed to show UI.
So, either
a) the whole devnode setup will complete without showing any UI
or
b) the devnode setup will only be completed when the admin will log on and answer the UI boxes displayed.
This is true for ANY UI in driver install procedure.
Now note that the first phase of it (on Vista+) is to copy the package (all files referenced by the .inf) to the Driver Store, with the .inf copied to \windows\inf\oem%02d.inf, with .pnf generated, and with .cat copied to catroot{GUID_DRIVER_ACTION_VERIFY}, and CatDb entry created in catroot2{GUID_DRIVER_ACTION_VERIFY}\CatDb.
And yes, at this phase, the digital signature check of the .cat is done, which sometimes requires the UI, namely:
a) the whole cert chain is valid and ascends to a trusted root, BUT there is no trusted publisher in the chain - yellow box. In this case, the admin can say “Always trust software from ThisCorp”, which adds the cert to Machine\Trusted Publishers.
b) any other error related to cert - does not ascend to a trusted root, expired, bad crypto BLOBs or damaged original data (signature mismatch) - red box.
And, since this is the UI, which only admin can answer - see above - then this will require the admin to log on interactively to add the driver package to the machine.
All later phases of devnode creation - for unlimited number of devnodes - runs fine UIless and thus does not require the admin to log on.
Now about WHQL. WHQL’s cert is just plain preinstalled to Windows’s Trusted Publishers, so all steps of the driver install for WHQLed driver can run UIless (coinstallers are prohibited from UI displaying in the install path by WHQL requirement) and thus there is no requirement for the admin to log on.
On Vista+ (all of the above text from “Driver Store” being first mentioned and later is about Vista+), you can do the same by installing your company’s cert to Trusted Publishers from your install app executed by the admin.
Now about “your device appearing on the bus”. You cannot create the root devnode of your bus without running as admin (or at least to have “Load/Unload drivers” privilege, which is IIRC the notion of “admin” used by SetupAPI), just plain and simple.
Non-admins cannot create devnodes in the Device Manager tree. This is reserved for a) admin user mode code c) kernel mode code. Nothing else.
Yes, the drivers for a new devnode can be silently installed by the OS in some cases, but creation of this new devnode can only be done by admin code or kmode code.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com