none
Can you have a filter driver inbetween Display port driver and Display miniport driver pair? RRS feed

  • Question

  • As title asks. I want to insert a filter driver in between the System supplied driver and the vender driver. Is this possible? are there any pre existing templates? Seems filter drivers should exist for most interfaces as all's they have to do at a minimum is relay everything over to next driver. Any help is appreciated.
    Wednesday, December 7, 2016 5:10 PM

All replies

  • what bigger problem are you trying to solve? 

    the simple answer is no, you can't filter between them. this is because the interface between the two is at the import level which means they are bound together by the loader when the driver is initialized. as opposed to a pnp stack which is simple to filter because it is interface based due to driver placement in the stack.

    the complicated answer is that you could perform some type of import address resolution interception such that your driver is loaded as the video port driver (dxgkrnl.sys) and then forwards on the calls to the real implementation. once you do that, you need to understand how the runtime interfaces are created and how to shim each. this is all very complicated and you can't get anything like this signed. So this begs the question, what bigger problem are you trying to solve and this path might be the best choice to solve that problem.


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

    Wednesday, December 7, 2016 5:38 PM
  • I wanted to modify the monitor object by adding additional i2c functionality with i2c read/write functions which are callbacks. I believed the arachitecture was like this.

    Display Port driver (provided by windows and is part of system, formally videoprt.sys )

    [interface]

    Display Mini Port Driver (provided by adapter vendor and was video mini port driver in XDDM)

    So what I would do is this

    Display Port Driver (provided by windows ) dxgkrnl.sys https://msdn.microsoft.com/en-us/library/windows/hardware/ff570589(v=vs.85).aspx

    [interface]

    My miniport driver which implements all interfaces listed here https://msdn.microsoft.com/en-us/library/windows/hardware/hh451569(v=vs.85).aspx

    [interface]

    hardware supplied Display miniport driver.

    Wednesday, December 7, 2016 6:26 PM
  • there is no supported way to do what you want. even if you piece something together, it can't be used at scale or put into production

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

    Wednesday, December 7, 2016 11:12 PM
  • I did this for the XPDDM about 20 years ago, and that became the basis for the multi-monitor support in Windows. If he created a miniport driver that was loaded for the device, and that miniport then loaded the real miniport then he could see the calls going back and forth. In the past, the video drivers were very restricted to what APIs could be called, and if that has continued to the current driver model (WDDM) then it might not be possible.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Friday, December 9, 2016 2:30 AM
    Moderator
  • Are you sure that you remember correctly what you did 20 years ago?

    I cannot see what you could achieve by substituting the MINIPORT driver.
    DriverEntry is the MINIPORT driver's only export function.

    Wasn't it the other way round?
    Didn't you substitute the PORT driver (videoprt.sys) with your own?
    Didn't your own substitute PORT driver expose the same exports as real videoprt.sys?
    Didn't your own substitute PORT driver delegate to the exports of real videoprt.sys?

    PS: The above mentioned technique is strictly research-only. No relevance for practical implementation. It works for certain areas (including contemporary NDIS on Windows 10). However, it does NOT WORK FOR WDDM because the port driver dxgkrnl.sys does not have any meaningful exports reflecting the DDI.
    Saturday, December 10, 2016 11:38 AM
  • Sorry, I meant the display driver not the miniport, which is where just about all the work was done. Back then, the miniport didn't do a lot beyond minor interaction with the hardware (initialization, mode switches, color table, etc.), the display driver did all the work. My display driver loaded first, and then it loaded the other display drivers for the physical video cards. My display driver queried the display drivers for the physical cards, and presented a single large display to the system. When drawing commands came from the system into my display driver, I clipped them and delivered them to the appropriate physical display drivers that were mapped to that portion of the large display.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Tuesday, December 13, 2016 4:12 AM
    Moderator
  • OK, this makes sense. I remember these old days. Probably the display driver DLL was even still in user mode (before NT4.0). Today's WDDM display driver DLLs are in user mode again. The same hooking technique would probably still work nowadays. Just that it would not help in this case because WDDM user mode DDI does not include I2C operations. These are handled in WDDM kernel mode DDI only.

    Now back to Doron's answers to both of which I agree:
    1. Simple answer - WDDM Hooking unsupported.
    2. Complicated answer - WDDM Hooking possible but far beyond the reach of regular driver development skills (minor irrelevant detail: WDDM hooking does not involve module import nor exports).

    Now, how about a 3. option applying to I2C operations on WDDM adapters only?
    Couldn't one write a simple PNP lower filter driver?
    Couldn't one install it above the monitor PDO and below the FDO of monitor driver (monitor.sys)?
    Couldn't this PNP filter driver intercept IRP_MN_QUERY_INTERFACE asking for DXGK_I2C_INTERFACE?
    Couldn't this PNP filter driver send its own query for DXGK_I2C_INTERFACE in case monitor driver doesn't send any query?
    I never tried this, but I assume it could have a realistic chance to work...
    Tuesday, December 13, 2016 10:02 AM
  • That seems reasonable

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Tuesday, December 13, 2016 6:55 PM
    Moderator