Install/update driver from Windows service

Question

To install a driver, you typically send the command:

DefaultInstall 128 {inf path}

to the InstallHinfSection via direct call or RunDLL.

This works wonderfully. I can install my driver anywhere (including 64-bit Win 2008 R2, which means I've got all the code signing right too).

HOWEVER, the above fails when launched from a Windows service. I've read about service vs client installs, and hoped I had met all the requirements for a silent service install (built a .CAT file, it is signed along with the driver, etc).

But no dice - it just fails. Comparing the errors in SetupAPI.log between an interactive install and the install from the service doesn't show any differences (other than the interactive takes the steps of copying the driver file and succeeds, where the other doesn't).

The driver itself is not in use (my service is the only one that uses it). Is there ANY way for a service to silently update a driver without requiring user interaction?

Answer 1

I called Microsoft and discussed this with a support engineer.

Turns out that using DefaultInstall with InstallHinfSection is somewhat obsolete, but still works. And it just happens to work without prompting the user if the driver is signed by a certificate that they recognize because DefaultInstall is 'dumb'. Yet the driver itself is still allowed to launch because it's cross-signed with the Microsoft cert. A nice little loop-hole I guess. The trick is it has to be installed by a service that is set to Interact with Desktop (a requirement). Using something like PsExec or RemCom is a way to do this if your service isn't currently running in that way.

In the future, this might not continue to work. At that point, get the driver's .cat file into the Windows\System32\Catroot{F7... folder but it can't just be copied directly in -- there is an API.

If the .cat was put in first, then the driver theoretically shouldn't need to prompt to ask if the certificate for the driver is acceptable to the user, because catroot is the 'acceptable to the user' list of certs and drivers.

Also, having the catalog file installed before attempting the driver install might help since the catalog contains the security certificate that the driver will present (though not necessarily in this case -- but it might help in the future (and possibly with Win 2003)

Basically the support engineer was surprised this worked at all and we went around and around on how it might be working... Hopefully this helps someone else.

share|improve this answer

answered Dec 1 '11 at 5:11

DougNDougN

2,601104974