How Windows uses .inf files to load the correct drivers

Question

What happens when a hardware device matches two or more inf files when Windows is loading the drivers for that devices?

For example, the disk drive in my PC has two drivers loaded for it, cdrom.sys and iaStorF.sys. cdrom.sys was loaded from the cdrom.inf file and iaStorF.sys was loaded from the oem2.inf file that I installed from Intel.

Does Windows search all inf files and load anything that matches?

If so which is the 'primary INF file', what I mean by this in Device Manager when I click on the disk drive and go to the 'Details' tab, and then look at inf name, it shows cdrom.inf file, even though it also matched oem2.inf.

If I then look at my monitor, which also has two drivers for it loaded from two inf files, oem22.inf and monitor.inf. Under 'Details' and inf name, it shows oem22.inf.

Why did it choose oem22.inf over monitor.inf?

Solution 1

Its actually one main driver. The other one you see is a filter driver -- iaStorF.sys, where F means filter.

A filter driver is a Microsoft Windows driver that extends or modifies the function of peripheral devices or supports a specialized device in the personal computer. It is a driver or program or module that is inserted into the existing driver stack to perform some specific function.(wikipedia)

Here is a screenshot of my system, for disk drives, its in

HKLM\System\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}

The main driver is disk.sys, the other 3 are all filter drivers, EhStoreClass.sys and partmgr.sys are default MS drivers in Windows 8, edevmon.sys is from eset.

For monitors, the additional inf is optional, used for extending the capacity, like color profile(.icm) or EDID information, these inf are not required for monitor to operate, only monitor.sys is necessary. (MSDN)

---

Some more info about filter driver, I'll just reproduce it here for future reference.(MSDN)

Filter drivers are optional drivers that add value to or modify the behavior of a device. A filter driver can service one or more devices. Bus Filter Drivers

Bus filter drivers typically add value to a bus and are supplied by Microsoft or a system OEM (see the Possible Driver Layers figure). Bus filter drivers are optional. There can be any number of bus filter drivers for a bus.

A bus filter driver could, for example, implement proprietary enhancements to standard bus hardware.

For devices described by an ACPI BIOS, the power manager inserts a Microsoft-supplied ACPI filter (bus filter driver) above the bus driver for each such device. The ACPI filter carries out device power policy and powers on and off devices. The ACPI filter is transparent to other drivers and is not present on non-ACPI machines. Lower-Level Filter Drivers

Lower-level filter drivers typically modify the behavior of device hardware (see the Possible Driver Layers figure). They are typically supplied by IHVs and are optional. There can be any number of lower-level filter drivers for a device.

A lower-level device filter driver monitors and/or modifies I/O requests to a particular device. Typically, such filters redefine hardware behavior to match expected specifications.

A lower-level class filter driver monitors and/or modifies I/O requests for a class of devices. For example, a lower-level class filter driver for mouse devices could provide acceleration, performing a nonlinear conversion of mouse movement data. Upper-Level Filter Drivers

Upper-level filter drivers typically provide added-value features for a device (see the Possible Driver Layers figure). Such drivers are usually provided by IHVs and are optional. There can be any number of upper-level filter drivers for a device.

An upper-level device filter driver adds value for a particular device. For example, an upper-level device filter driver for a keyboard could enforce additional security checks.

An upper-level class filter driver adds value for all devices of a particular class.

Solution 2

Some information can be found in this old Microsoft article (XP time)
How Windows determines the most suitable device driver to install during Setup :

When you run Windows Setup, you may have more than one set of device drivers or .inf files that work with a particular device. Both Setup and Plug and Play attempt to resolve these conflicts by selecting the device driver that is the most suitable match for the device that is being installed.

Plug and Play can search all the .inf files for the most suitable device driver to install for a particular device. Plug and Play does not stop its search on the first match that Plug and Play finds. Plug and Play continues to search all the .inf files that are listed in the search path of Plug and Play, as defined in the following registry entry:

HKEY-LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion

DevicePath:Reg_Expand_SZ:%Systemroot%\Inf

Setup builds a list of compatible device drivers that contained a match in an .inf file and assigns a "rank" for each one that had been located. The rank can range from "0" to "0xFFFF" with 0 being the most suitable possible match and 0xFFFF the worst possible match. The device driver with the lowest rank is considered the most suitable possible match and is the device driver installed.

However, if two device drivers have the same lowest rank, Setup uses the device driver with the most recent date. If one of the device drivers is signed and the other device driver is unsigned, the unsigned device driver date is assigned a value of 0xFFFFFFFF, and the signed device driver is selected and installed.

It should be noted that by default a 64-bit Windows version will not accept unsigned drivers as candidates. This is only possible in 32-bits Windows.

The following article contains the latest algorithm : How Windows Ranks Drivers

Windows assigns a rank to a driver that matches a device. The rank indicates how well the driver matches the device. A driver rank is represented by an integer that is equal to or greater than zero. The lower the rank, the better a match the driver is for the device.

The rank of a driver is a composite value that depends on how a driver is signed, the features that are supported by the driver, and the type of match between the device identification strings that are reported by a device and the device identification strings that are specified in the entries of an INF Models section of a driver INF file.

A rank is represented by a value of type DWORD. A rank is sum of a signature score, a feature score, and an identifier score. A rank is formatted as 0xSSGGTHHH, where S, G, T, and H are four-bitfields and the SS, GG, and THHH fields represent the three ranking scores, as follows:

• The signature score ranks a driver according to how a driver is signed. The signature score depends only on the value of the SS field. An unspecified signature score is represented as 0xSS0000000.

For an overview on how Windows Vista and later versions of Windows use a driver's signature to determine how the driver is installed, see Signature Categories and Driver Installation.

Basically, digital signatures by a Windows signing authority score the highest.

• The feature score ranks a driver based on the features that the driver supports. The feature score depends only on the value of the GG field. An unspecified feature score is represented as 0x00GG0000.

This information is specified inside the .inf file, so a manufacturer can order his own drivers.

• The identifier score ranks a driver based on the type of match between a device identification string that is reported by a device and a device identification string that is listed in an entry of an INF Models section of a driver INF file. The identifier score depends only on the value of the THHH field. An unspecified identifier score is represented as 0x0000THHH.

This text is quite confused and confusing. See the link for a much better description for identifier score.

Comments

[Moab]

Usually it loads the latest version of the driver.

[Moab]

Some homework

[RJSmith92]

Thanks @Moab, I had looked through all them before posting the question and couldn't find the answer. The date thing doesn't seem to hold true, as with the disk drive it uses the cdrom.inf file, which says 2006, over the Intel file, from 2010.

[Moab]

Its probably a balance between best fit and latest version. Since Windows is closed source code we may never know.

[RJSmith92]

Hi Chris, thanks for the great info. I actually think I've figured it out. For my monitor, the class ID matches two inf files and Windows seems to show the newer one as the driver (even though all it does it load the .ICM file and a few reg settings, while Microsoft's older inf file actually loads monitor.sys). My confusion was why the disk dive showing the older Microsoft driver and not the newer Intel one like the monitor. I now realise the iaStorF.sys driver is being loaded from OEM2.inf as I thought, but that inf file is for the ACHI controller, and contains a small section that installs..

[RJSmith92]

..isStorF.sys for the disk drive class ID. Only one inf file's class ID actually matches the disk drive, which is Microsoft's and that's why it shows up. Thanks again.

[RJSmith92]

Thanks harrymc, I think I've found the reason which I've explained under Chris's answer. Again, thanks for taking the time to look for all that info which helped find the solution.