none
Creating Driver stacks using INF Files RRS feed

  • Question

  • I have two sample KMDF drivers. Is it possible to create a driver stack with these two drivers using these INF files? So that I can attach one driver on top of another when these two drivers are installed using INF files? I have seen quesions on this forum where people have done disk driver stacks but it is not clear how they have done it.
    Tuesday, January 21, 2014 1:10 AM

Answers

  • You must use one inf. The inf will specify one driver as the fdo and the other driver as an upper or lower service (depending on which driver should be on top of the stack). Why have two drivers when you could combine them into one, making install and testing simpler?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, January 21, 2014 2:26 AM

All replies

  • First you have to write the drivers to support this.   There are multiple possible ways here, for instance you can have two filter drivers, that both filter the same type of device.   One can be a bus driver and the other a function driver for the device object the device creates.   What you can't do is take two random drivers and make a stack out of them.

    But the real question is what problem are you trying to solve?   There a good reasons for splitting things in multiple driver, but without some idea of the problem you are looking at, there is no way to say if it something that should be done as multiple drivers, or how you should approach it.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Tuesday, January 21, 2014 2:23 AM
  • You must use one inf. The inf will specify one driver as the fdo and the other driver as an upper or lower service (depending on which driver should be on top of the stack). Why have two drivers when you could combine them into one, making install and testing simpler?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, January 21, 2014 2:26 AM
  • What I am trying to do is just doing a sample driver stack. One with a filter driver and below that a FDO. I just want to check passing of  WDF Requests( of IRPs if possible) down this device stack
    Tuesday, January 21, 2014 5:12 AM
  • Can this be done by attaching an upper WDF filter to the WDF FDO driver? Send the request to the filter first and create new request at the filter and pass it down? Hope the filter can be specified as an upper filter in its INF file , like in the Toaster WDM sample. Hope the upper filer can be mentioned in WDF INF also.

    Tuesday, January 21, 2014 3:29 PM
  • Yes you can do things like the toaster sample.  Doron's examples are for device specific filters, in many cases I write a class filter that is smart enough not to attach to device unless it is the one of interest.  While this can be more complex, it has the advantage of allowing one to filter a device that you do not have the sources or at least release control of, since you can use a totally seperate INF / driver package.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Tuesday, January 21, 2014 3:47 PM
  • There seems to be some differences in opinions on the forums: I would like to get some points clarified:

    1. If I need to attach a filter above or below a device( I mean a FDO, if possible at all ), in whose INF should I specify the AddReg section for the filter? In the filter driver's INF or in the device's INF? Most of the implmentations I have seen is in a filter INF. Or should one write a third INF and refer the filter and function INF in it?

    2. If in either case above, will the filter be installed and attached above or below the device when I install the INF?

    3. In order to attach a filter driver to a device, should the filter have been first installed on the system before I install the device?

    4. Once the filter has been attached, is there anyway we can physicaly see the layering , say via Device Manager?

    5. Whats the difference between a class wide filter and device-specific filter?

    6. Once a filter has been attached above a device, can I directly send a request to the device only ? If so, will the request be first accepted by the filter and then passed down?


    • Edited by its_me_here Wednesday, January 22, 2014 6:10 PM
    Wednesday, January 22, 2014 6:09 PM
  • There seems to be some differences in opinions on the forums: I would like to get some points clarified:

    1. If I need to attach a filter above or below a device( I mean a FDO, if possible at all ), in whose INF should I specify the AddReg section for the filter? In the filter driver's INF or in the device's INF? Most of the implmentations I have seen is in a filter INF. Or should one write a third INF and refer the filter and function INF in it?

    2. If in either case above, will the filter be installed and attached above or below the device when I install the INF?

    3. In order to attach a filter driver to a device, should the filter have been first installed on the system before I install the device?

    4. Once the filter has been attached, is there anyway we can physicaly see the layering , say via Device Manager?

    5. Whats the difference between a class wide filter and device-specific filter?

    6. Once a filter has been attached above a device, can I directly send a request to the device only ? If so, will the request be first accepted by the filter and then passed down?


    #1 It depends on how you write the filter. A class filter typically has a seperate INF, a device specific filter needs to be in the devices INF.

    #2 The filter is defined as being either an upper or lower filter, so if it is upper it above the device driver, if it is lower is is below.

    #3 If it is a lower filter, the system must be aware of it before the device driver, though it can be in the device INF. If it an upper class driver it can be installed after the fact in most cases.

    #4 The layers will not appear in the device manager. OSR has a tooi called DeviceTree see http://www.osronline.com/article.cfm?article=97 that will do this.

    5. A class filter is called for every device in that class. A device specific filter is only called for the device you specify.

    6. Once the filter is installed the filter sees the request, it depends on what it does whether the device sees it. For instance, you could write a filter that fails all write operations and completes them in the filter.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, January 22, 2014 6:24 PM
  • 1) this depends on if the FDO is shipped by Windows and has a named INF or if the FDO is shipped by a third party where the INF, after import, will be named oemXxx.inf. For a filter driver to installed by an INF separate from the FDO, the filter's INF needs to use the Needs and Include INF directives. these require a named INF which means that you can only use this pattern on a driver shipped by Windows. Since you cannot deterministically know the oemXxx.inf you can't use these directives and thus the filter and FDO must be installed with the same INF

    2 the filter is attached above if specified in an UpperFilters AddReg commdn, the filter is attached below the FDO if specified in LowerFilters

    3) install order doesn't quite matter, the install can be though of as an atomic operation at a high level

    4) not in device manager. in the debugger you can run !devstack <your stack's Physical Device Object (PDO)> and it will dump the stack.

    5) a class filter is specified in the class key, not the device node and is attached to all devices of that class. there is no INF install for a class filter.  so a device filter targets a specific device (e.g. a Microsoft wedge mouse) while a class filter targets all devices in that class (all mice). Upper class filters are layered on top of device filters when the stack is being built, if there is only a class or device filter in the stack, it looks exactly the same, there is an FDO with a filter device object attached. Let's be clear, class vs device filter describes order of how the filters are installed, it does NOT define what the filter does. Both a class and device filter can do exactly the same thing

    6) it is unclear what "I" is. if "I" is an app, it opens a handle to the stack and the top of the stack (the upper filter, if installed) sees it first. If "I" is the upper filter, the upper filter can send io to the stack below it. in this case the filter doesn't see the request flow through the filter driver since the filter is the one sending it.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, January 22, 2014 6:37 PM
  • 6) it is unclear what "I" is. if "I" is an app, it opens a handle to the stack and the top of the stack (the upper filter, if installed) sees it first. If "I" is the upper filter, the upper filter can send io to the stack below it. in this case the filter doesn't see the request flow through the filter driver since the filter is the one sending it.



         Thank you Doron.Sorry by "I", I meant an app itself. Suppose the filter and the FDO has both implemented EvtIOWrite() callbacks. So I guess "by opening a handle to the stack" you meant calling CreateFile(), obtaining a handle and calling WriteFile() . Also I suppose the CreateFile() should be called with the device interface GUID of the Filter driver if it is an upper filter, right?
    • Edited by its_me_here Thursday, January 23, 2014 4:34 AM
    Thursday, January 23, 2014 4:34 AM
  •  I have found that we can also attach a filter driver over another driver( say a fuction driver) via registry settings. I tried to attach an upper filter to a FDO by specifying the filter driver in the HKLM\System\Control\CurrentControlSet\Class entry of the function driver. The attaching seems success and I can see the filter driver attached to the FDO in DeviceTree( osronline tool ). In this case I was installing the two drivers separately. The resgistry doesnt allow modification in other areas like ENUM\ROOT  . Modification is seen allowed in Class section as mentioned above. But modifying in class level makes it  a class level filter. But I need to set an upper filter to  particualar device only. How can this be done?

    The service installation section of the INF I set as follows:

    ;-------------- Service installation
    [KMDFFilterDriver_Device.NT.Services]
    AddService = KMDFFilterDriver,, KMDFFilterDriver_Service_Inst
    
    ; -------------- KMDFFilterDriver driver install sections
    [KMDFFilterDriver_Service_Inst]
    DisplayName    = %KMDFFilterDriver.SVCDESC%
    ServiceType    = 1               ; SERVICE_KERNEL_DRIVER
    StartType      = 3               ; SERVICE_DEMAND_START
    ErrorControl   = 1               ; SERVICE_ERROR_NORMAL
    ServiceBinary  = %12%\KMDFFilterDriver.sys
    LoadOrderGroup = Extended Base
    In the AddService section I have omitted the flag section as it should be done in the case of filters. But when I install this INF using devcon utility, iinstall fails. But on restaring the machine, then installation runs and is success. Is this the expected behaviour? Since we have specified StartType as 3, shouldnt the driver get installed and started shortly after installing without the need for a system restart? But some times after installation and restarting the installation fails. Any inputs regarding this?
    Thursday, January 23, 2014 6:31 PM