views:

33

answers:

2

Hello,

We are a small hardware manufacturer. Most of our products use USB for programming the controllers used. The current situation is that programming the hardware (part of the assembly processor) is rather labour intensive. Each time a new USB device gets plugged in Windows prompts for a driver install. This means that for each new product we have to go through a process of "no, don't go to internet" --> "yes, search automatically" --> "done". We even have to do this twice for each product.

I have been experimenting with the Windows preinstaller (DPInst), but this seems to only facilitate a succesful "yes, search automatically" part. Is there a way to have the drivers installed fully automatically after plugging in the USB device?

Kind Regards,

Ronald

+1  A: 

I had the same problem 5 years ago.

The main problem is that the installation of USB drivers after Plug&Play of the coresponding device works under the LocalSystem account. To have no security problems Microsoft allows silent installation of drivers only signed by Microsoft. Starting with Windows Server 2003 there are documented way (see http://www.microsoft.com/whdc/driver/install/authenticode.mspx).

If you have a managed corporate environment (you can prepare computers which will use your Plug&Play devices), then there are a workaround which solves the problem on Windows XP. I suggested it 5 years ago for one of my customer. It works perfect since about 5 years in environment with some of 10000 Windows XP computers.

The idea for the solution is very easy: your drivers (for example the CAT file) must be signed with the signature which

  • has both 1.3.6.1.5.5.7.3.3 ("Code Signing") and 1.3.6.1.4.1.311.10.3.6 ("Windows System Component Verification") OIDs as Enhanced key usage (EKU) extension
  • the certificate or it's parent certificate must be installed in the Machine's Root (Trusted Root Certification) or AuthRoot (Third-Party Root Certification Authorities) certificate store

If you do this on a Windows XP computer, the operating system will interpret your driver like Microsoft signed driver.

Morver you shoud insert in the registry the path to the source of the driver.

Oleg
This is all true, but if the devices are just different units of the same type, then there doesn't need to be more than one driver installation run anyway.
Will Dean
You must not install the driver at all. If they are signed "as Microsoft signature" and a path to the driver will be found, than a silent installation will be done. So it seems to me it is indepandend whether you have different units of the same type or not. The new device will be installed without any interection with the user. Just try what I written. If you will have problems I could post you an example how to create a Self-Signed certificate with respect of MakeCert.exe and test all what I wrote.
Oleg
Thanks for your input.The drivers I am trying to use are actually signed. Yet still the driver wizard asks me for input. Maybe the DPInst does not recognize the signature.I found a workaround now by disabling the USB serial number. This is done by adding a registry key to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\USBFlags\The key is: IgnoreHwSerNum04306001, meaning IgnoreHwSerNum{VID}{PID}.The drivers are installed after adding this key.The result is that all devices with this VID/PID are treated as the same. The same driver connects within seconds.
By the way. This does not solve the problem of easy driver install for our customers. But our version of the driver is indeed unsigned. Is it legal to use MakeCert.exe? I guess Windows wants to certify themselves?It could be legal as I actually use FTDIs drivers, only added my VID/PID to it.
MakeCert.exe use Crypto API and produce certificate corresponds to all known standards. It is absolute legal to use MakeCert.exe. The main idea of my solution is usage of 1.3.6.1.4.1.311.10.3.6 ("Windows System Component Verification") enhanced key usage extension and not only 1.3.6.1.5.5.7.3.3 ("Code Signing") used typically. You can use MakeCert.exe if your customer are ready to include your certificate in the list of Root certificates only. This is the main restriction of the solution. If the customer has own PKI you can resign CAT file with your driver with the customers certificate.
Oleg
By the way 5 years ago my customer, for which I suggested the olution, sent my suggestion to Microsoft for proving. Microsoft conformed, that it is work on Windows XP and all is absolutely legal.
Oleg
+1  A: 

I take it your devices have a unique USB serial number, and hence each one is detected as a new device that hasn't been seen before.

If so, then the solution is this, from http://www.lvr.com/usbfaq.htm:

During device testing, we attach many devices that are identical except for the serial numbers. How can I prevent Windows from asking to install a new driver every time a device is attached?

The method described below causes Windows 2000 and XP to ignore a device's serial number. It's recommended for test environments only.

This registry key controls whether Windows uses or ignores device serial numbers:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags]

It's possible to ignore all serial numbers, though this approach is NOT recommended. To ignore all serial numbers, in the above key, change this value to zero:

GlobalDisableSerNumGen = 1

To ignore the serial number for an individual device, create an entry under the above ...\UsbFlags key. The name must start with "IgnoreHWSerNum" followed by the vendor and product ID of the device. A value of 1 = "disable the serial number."

Example (Vendor ID = 0925h, Product ID = 016Ah):

IgnoreHWSerNum0925016A= 1

An alternative hardware/firmware solution is to disable the device USB serial number during production (e.g. with a link, possibly one made by a test fixture). Without a USB serial number, Windows will assign a pseudo serial-number to the device, based on its position in the connection tree. That wouldn't be likely to change during a production run, so all devices would then be treated as identical and Windows wouldn't bother with the new driver stuff.

Will Dean