Require connected non-WHQL PnP USB driver for install?

NTDEV
1

I’ve noticed on Win8.1 x64 that I can add my USB driver package without the device connected, and have it automatically install on next connection. So far this has worked in every permutation of usage I’ve tested, which seems great. With the right devcon incantations of package removal and adding, it works for updates, too. This is a non-WHQL driver.

Unfortunately, on Windows 7 x64 I can’t reliably do this more than once. What happens is that the old version of the driver still exists at system32\drivers and is still associated with the (disconnected) USB device. I can’t see any way of getting rid of, or updating that old driver installation in order to forcibly upgrade it to a new version of my driver – at least while the device is disconnected.

If Microsoft changed this for Win8.1, that’s wonderful, but currently I also need to support Win7 and Win8, where we consistently see the above problem in our testing.

From googling and reading previous OSR forum discussions, many people have evidently struggled with this. I would be willing to go to a fair amount of trouble if there’s any way to improve the update process, since my users will have multiple different hardware devices that the driver matches. In fact, they are even likely to share access to these (multi-port) audio mixer devices at their musical gigs. So I can’t predict when they will plug something in.

My questions:

  1. Must a non-WHQL PNP USB device be connected during driver installation in order to upgrade the driver from a previous version reliably?
  2. Is my only option to run some kind of Windows service to detect when a device is connected with the old driver and offer to launch an installer?
  3. Would I have this same problem with a WHQL driver? (Guessing yes.)
2

My post was mistaken – Win7 x64 doesn’t let me do a disconnected install of my USB driver. An end user who connects the device after my disconnected install would have to go to Device Manager, Update Driver, and Search Automatically, and then it’s fine. Presumably that’s the part that WHQL would fix, but it’s still not clear to me even with WHQL what would be the best way to replace an existing PnP driver, except via a connected install.

So far it seems like once I do an install with a matching device connected, other devices that connect later are assigned the same new driver, which is good as far as that goes.

Not clear whether replacing files in the installed package and replacing the *.sys file in system32\drivers would be sufficient to upgrade. Deleting registry entries under CurrentControlSet seems like quite a long shot.

3

> Not clear whether replacing files in the installed package and replacing the *.sys file in system32

Just call UpdateDriverForPlugAndPlayDevices instead.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

4

UpdateDriverForPlugAndPlayDevices via “devcon update” doesn’t work when installing disconnected, with a non WHQL USB driver on Win7 x64. With the device connected, it works fine.

5

xxxxx@yahoo.com wrote:

I’ve noticed on Win8.1 x64 that I can add my USB driver package without the device connected, and have it automatically install on next connection. So far this has worked in every permutation of usage I’ve tested, which seems great. With the right devcon incantations of package removal and adding, it works for updates, too. This is a non-WHQL driver.

Unfortunately, on Windows 7 x64 I can’t reliably do this more than once. What happens is that the old version of the driver still exists at system32\drivers and is still associated with the (disconnected) USB device. I can’t see any way of getting rid of, or updating that old driver installation in order to forcibly upgrade it to a new version of my driver – at least while the device is disconnected.

This should not be a problem. My driver installers are written in NSIS,
which call DPInst to do the dirty work. In my installer, if I detect
that a previous installation exists (by looking for the Uninstall
registry key), I just run “dpinst /u”. That removes the old package. I
can then continue with my installation. I’ve never had the “dangling”
issues you mention.

The fact that a driver file exists in system32\drivers does not mean it
is “associated” with a device. Even after uninstalling, you will often
have the .sys file hanging around. That doesn’t mean anything. When
you plug in a device, there is a multi-layer search to get a driver running.

First, we look in CurrentControlSet\Enum to see if we already know this
device. If that is present, it eventually points to the Services entry
that identifies the .SYS file.

If it is not in CCS\Enum, then we go searching through the INF files to
see if a driver has previously been installed. If so, we run an install
process again, creating a new CCS\Enum key.

If it is not in the INF directory, we go searching through the driver
store to see if a driver package was previously pre-installed. If it
was, we run an install, copying new files into place, including another
OEMxx.INF file.

If it is not in the driver store, we give up and present a yellow bang.

  1. Must a non-WHQL PNP USB device be connected during driver installation in order to upgrade the driver from a previous version reliably?

No. You just need to trigger an uninstall.

  1. Is my only option to run some kind of Windows service to detect when a device is connected with the old driver and offer to launch an installer?

No. How would you do that, anyway? If they had an old driver, how
would you know that a new driver was available?

  1. Would I have this same problem with a WHQL driver? (Guessing yes.)

WHQL is irrelevant. The only effect of the WHQL signature is to
eliminate the “Do you trust this publisher?” dialog.

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

1 Like