windowsdriverwdkkmdfwdf

Windows driver with or without INF file


I've seen two ways to install Windows drivers.
a. Using both SYS file and INF file. (such as NDIS driver)
b. Only use SYS file, the driver will be loaded by a service. (such as drivers in C:\Windows\System32\drivers)

So, my question is:
1. What kind of drivers or situations require INF a file?
2. What is the root cause of this difference?


Solution

  • There are different kinds of drivers on Windows. Each type of driver has its own story for how the driver is installed. Here are a few common types of drivers.

    PNP device driver. A PNP device driver operates a device in the device tree. PNP drivers are loaded by PNP when the device is enumerated by its parent bus. In order for PNP to know which type of device your driver supports (and a bunch of other stuff), you need a PNP-style INF that describes your driver.

    SCM-managed driver (sometimes called "legacy driver"). SCM loads these drivers based on the same rules it uses to start NT services. SCM does not require any INF. You can register a new driver with SCM by simply running sc.exe create my_cool_driver type=kernel binPath=c:\my\driver.sys start=auto or calling the CreateService API. But if you already have an INF for other reasons, you can use any style of INF to do the same via the AddService directive.

    NDIS lightweight filter (LWF) driver. LWFs are not loaded by NDIS; NDIS doesn't care how they're loaded. Most LWFs choose to be loaded by SCM, since that's easy to control. An NetCfg-style INF is still required, though, since NDIS needs to know what types of network adapters to attach the filter to (Ethernet vs WLAN, for example).

    Export driver. An export driver is loaded by the memory manager when Mm is trying to load some other driver that imports functions from it. An export driver is just a kernel equivalent of a DLL — it just provides APIs to other drivers. Export drivers don't need an INF; they just need to be put into the right directory on disk. If you already have an INF for other reasons, you can use the CopyFiles directive to do this.

    WinUSB driver. WinUSB is a built-in driver that delegates most of the responsibilities of managing a USB device to usermode APIs, so any application can easily do simple things with the device. This means pretty much any application can be the driver for the device. If the USB device puts certain data in its hardware descriptor, Windows will know to automatically set up WinUSB, so no INF is required. But if the hardware does not advertise that it needs WinUSB, then you'll need a WinUSB-style INF to tell Windows to set up WinUSB for you. Beyond that, you don't need an INF to call WinUSB APIs from your application.

    If you're just experimenting and want to call a few kernel APIs for fun, you can choose any type of driver. Most people find that an SCM-managed driver is the easiest, since you don't need any INF and you get full control over when the driver starts and stops. But in any other situation, the choice of driver type is largely dictated by the problem you're trying to solve. For example, if you're writing a driver for a PCI GPU, you must use a PNP driver, and therefore must have a PCI-style INF.