Virtual Driver via Windows Update questions

NTDEV
1

I have a virtual device driver that I would like to upload to Windows Update so that it can be placed in the users driver store without admin access. However, as part of the installation of this driver I need to use calls from SetupAPI which require admin access:

SetupDiCreateDeviceInfo
SetupDiSetDeviceRegistryProperty
SetupDiCallClassInstaller

Is there some way that I can get these calls to be triggered without admin access (i.e. if they are somehow associated with the driver on Windows update via a co-installer?)

I am quite new to the drivers world so please excuse me if the question is a bad one. The end goal is to *somehow* get our virtual driver to be installable without admin access. If it were a regular driver it would seem to be easy with Windows update, but since I need to use the calls above (to associate the driver with a virtual device node) I am not sure what to do.

The driver is already WHQL signed so that end of it isn’t a problem.

thanks,
A

2

> The driver is already WHQL signed so that end of it isn’t a problem.

Is your device ID USB or PCI? If so, then from WHQL to Windows Update is just a few tick boxes away.

https://winqual.microsoft.com/member/ddc/default.aspx

Tim.

3

It’s USB - but getting the driver up to Windows Update isn’t what I’m wondering about - I’m unclear how (or if) I can execute the SetupAPI calls to create the virtual device on the system and associate it with my driver as a non-admin (i.e. by including a co-installer?).

4

> It’s USB - but getting the driver up to Windows Update isn’t what I’m wondering about - I’m unclear how (or if) I can execute the SetupAPI calls to create the virtual device on the system and associate it with my driver as a non-admin (i.e. by including a co-installer?).

The co-installer will be too late - it won’t be downloaded until the VID/PID is spotted on the bus. Do you have a virtual bus as well?

Tim.

5

> Do you have a virtual bus as well?

Yes. Does this influence which calls I can use to create the virtual device?

6

>can execute the SetupAPI calls to create the virtual device on the system and associate it with my driver as a non-

admin (i.e. by including a co-installer?).

If you call this from coinstaller DLL - then forget the very issue about admin/non-admin.

Just sign the coinstaller in the .cat and do the WHQL tests with it, then submit the package to WHQL.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

> If you call this from coinstaller DLL - then forget the very issue about admin/non-admin.

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?

8

xxxxx@gmail.com wrote:

> If you call this from coinstaller DLL - then forget the very issue about admin/non-admin.
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?

It can do so whether it is signed or not. The co-installer runs in the
context of the device manager, which is privileged.

However, your co-installer is part of the driver package. If you had a
co-installer, it should have been part of your original WHQL submission
to begin with.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

Ok, this is all clear, I guess now I need to know which (non-admin) SetupAPI calls to use so that my virtual device shows up on the bus (which will then (if I understand correctly) trigger a lookup on windows update which will populate the local driver store and launch my driver’s embedded co-installer).

10

xxxxx@gmail.com wrote:

Ok, this is all clear, I guess now I need to know which (non-admin) SetupAPI calls to use so that my virtual device shows up on the bus (which will then (if I understand correctly) trigger a lookup on windows update which will populate the local driver store and launch my driver’s embedded co-installer).

Well, that’s a problem.

Do you have a driver for your virtual bus? Are you using a root\
enumerated or sw\ enumerated device?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

> 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