Windows 7 driver signing conundrum

I've posted about various issues using drivers in Windows before. About a week ago I came across another issue that so far I have never seen, and it's a stubborn one.
Written by Chris Clay Clay, Contributor

I've posted about various issues using drivers in Windows before. About a week ago I came across another issue that so far I have never seen, and it's a stubborn one. This time, it was an issue with a driver released for an integrated wireless NIC by RALink Technology. The issue? Windows 7 refuses to automatically install it because it doesn't trust the source of the driver. The error that shows up for the properties of the device in Device Manager is:

Windows cannot verify the digital signature for the drivers required for this device. Error Code 52.

Now, while this may not pose as a big deal, the issue at hand is to have the Windows installer use the driver during an unattended installation of Windows 7. What's even more frustrating, the manufacturer of the PC and the device itself only release InstallShield packages that the user must run to obtain the drivers in the first place. To get the raw driver files for the unattended installation, I must run the InstallShield package to install it on a PC that has the device in it, then go back and look at the properties for the device in Device Manager, and under Driver Details get the list of files to extract, as well as find the oem*.inf file in the c:\windows\inf\ folder. The driver can be successfully installed manually once Windows is installed, where it prompts for the user to allow it to install. What adds to this puzzle is that the driver itself IS signed, because after it is installed, it shows the "Name of signer" for the driver itself as "Ralink Technology Corporation". So what is the deal here?

After doing some more research, it turns out this is a known issue with Windows, where it does not correctly determine that a driver is signed. Posts about this error show up all over. Microsoft's article on the error code says:

If the device is a CD or DVD drive, use the Automated Troubleshooting Service, at the Microsoft Support Web site (http://go.microsoft.com/fwlink/?LinkId=192997).

Go to the device manufacturer’s Web site and download and install the latest appropriate driver for the device.

Search for possible solutions for your particular device on the Microsoft Support Web site (http://support.microsoft.com). For example, for issues related with an iPod, you might search for “code 52” iPod.

Well, the first option is not possible as there is no disc, and the manufacturer's website already contains drivers are are signed and have the same issue. And no additional searches show show any useful information on this on Microsoft's site. Searching the rest of the Internet on the issue mainly supplies links for downloading the drivers from 3rd party sites, or for software that should "fix" the problem, like "DLL Suite". No thanks, I'm not about to start installing a bunch of unknown 3rd party products to try and help with a Windows problem.

Personally I think the whole driver model for Windows is a huge mess, especially when problems come up like this, they can be very difficult to fix. As a band-aid, Microsoft implemented its driver signing policy to help alleviate issues with unstable or malicious drivers being released by 3rd parties. Yes I know, most of the time drivers just install and all is good. I like to compare this to alternative operating systems like GNU/Linux, where all drivers for most Linux distributions are pre-compiled for the kernel and are automatically loaded when the kernel is running. There is no hunting for 3rd party packages, extracting driver files from system folders like there is in Windows, or driver signing. GNU/Linux is a huge improvement over Windows on how it handles drivers, since everything is included in the Linux distribution. There are cases where a driver might need to be compiled, but this is extremely rare, and I've never had to do this with the 2.6 series of Linux kernels.

This issue has a workaround for now, but it involves the tech to manually install the driver for each PC imaged. And yes, Windows 7 can be set to allow unsigned drivers after Windows is installed, and there are methods to address unattended setup for Windows XP, but so far we haven't discovered the right recipe for Windows 7's unattended installation. This is not a big deal for a few PCs, but for a large batch it is time consuming, and the tech should be spending that time doing other tasks like installing additional software.

Editorial standards