Earlier in the year I blogged about discovering unknown devices in Windows for integration into an unattended build. What I didn’t detail at the time was how to work out which device driver files are needed for a particular device.

Some device driver packages are pretty simple, but others are several megabytes in size. Rarely is the whole driver package required and it is usually sufficient to just copy a few files to the (RIS) installation source – generally:

• An .INF (setup information) file with an associated .CAT (security catalog) file.
• One or more .SYS (system) files.
• Possibly some .EXE (application) and .DLL (application extension) files.

I usually start off by reading the setup information file which relates to the Windows XP version of a driver. It’s straightforward enough to identify the catalog file (used to confirm the digital signature for the other files) from the CatalogFile= line in the [Version] section and for many simple .INFs, it is easy to identify the device driver files from the [SourceDiskFiles] section, but sometimes the setup information file supports a variety of devices and not all of the files are required. For complex driver configurations (e.g. an ATI video driver), I usually copy the .INF and .CAT files to the installation source and then attempt to install the driver from a reference workstation. As Windows XP throws an error each time it is unable to locate a file, I add the requisite file to the installation source, retry and repeat until all the necessary files are present (which normally only takes a few minutes).

Some device drivers include a subfolder within the [SourceDiskNames] section. In this case you have a choice – either edit the .INF (not recommended as it will break the digital signature), or place the appropriate files (geneally all except the .INF and the .CAT into an appropriately named subfolder and extend the OemPnPDriversPath in the [Unattended] section of the unattended setup file.

One final note. In my unattended build, I have support for a variety of PC models, some of which use different drivers for what would seem to be identical hardware. For example, both the IBM ThinkPad T40 and the Compaq Evo N620c have an Agere Systems AC’97 Modem, but the driver version I downloaded from IBM and integrated into the build for the T40 was not recognised by the N620c (due to different PCI device instance IDs – the T40 implementation is PCI\VEN_8086&DEV_24C6&SUBSYS_05241014&REV_01\3&61AAA01&0&FE whilst the N620c is PCI\VEN_8086&DEV_24C6&SUBSYS_00580E11&REV_03\3&61AAA01&0&FE). I didn’t have access to a spare T40 in order to regression test a version of the driver with support for both device instances (assuming there is one), so I downloaded a version of the driver from HP, which does work with the N620c. Although the .INF and .CAT files are different, both the IBM and HP drivers have a number of files in common (AGRSM.SYS, AGRSMMSG.EXE and AGRSMDEL.EXE – albeit with different date and time stamps), so I left the newest versions of the common files in place (which happen to be the IBM versions). As I haven’t changed the files for the IBM driver, the T40 build should be fine, but the N620c build fails a check on the digital signature due to a mismatch between the file versions. There are two ways around this: either place the two driver versions into different folders and extend the OemPnPDriversPath in the [Unattended] section of the unattended setup file; or disable the check for signed drivers as detailed in Microsoft knowledge base article 314479.