KMDF virtual display driver possible?

I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster sample that enumerates a single device. For that device I have successfully installed a functional virtual display driver, that incorporates the KMDF functions from the “featured” toaster sample bus driver.

When the DriverEntry function of the functional bus driver calls WdfDriverCreate, an exception is generated when the WdfFunction array is called, apparently because the table is filled with zeros.

Checking the link map, I see that my functional driver is bound to a stub driver. Apparently the KMDF binding never occurs and the KMDF function table is unitialized.

I’ve concluded that it’s not a matter of KMDF load order as the bus enumerator driver was successfully bound to KMDF. Is there some reason KMDF will not bind to a WDDM driver?

  1. KMDF will not help in WDDM driver. Why do you think KMDF will give you here?

  2. this is a build problem, not a load order problem. The WdfFunction array is setup by the KMDF stub library which is linked to your driver. Among other things, we change your entrypoint to FxDriverEntry (where we setup the array) and then call your DriverEntry. My guess is that the stub library and entry point are not being set up b/c the makefile rules for a WDDM driver override some of the KMDF rules

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jupiter.com
Sent: Tuesday, February 24, 2009 4:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF virtual display driver possible?

I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster sample that enumerates a single device. For that device I have successfully installed a functional virtual display driver, that incorporates the KMDF functions from the “featured” toaster sample bus driver.

When the DriverEntry function of the functional bus driver calls WdfDriverCreate, an exception is generated when the WdfFunction array is called, apparently because the table is filled with zeros.

Checking the link map, I see that my functional driver is bound to a stub driver. Apparently the KMDF binding never occurs and the KMDF function table is unitialized.

I’ve concluded that it’s not a matter of KMDF load order as the bus enumerator driver was successfully bound to KMDF. Is there some reason KMDF will not bind to a WDDM driver?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Well, I’ve been out of the graphics driver business (THANK GOD) for couple years but this is what I remembered at the time it was called LDDM.

In xpdm, video miniport talks to videoprt.sys.? its km rendering (display) driver(s) talk to kernel mode gdi and d3d.

In WDDM, kernel mode miniport is loaded by displdr.sys, and mainly talk to dxgkrnl. Its rendering (display) drivers are in um. None of them has anything to do with kmdf.

What is your definition of “virtual display driver”


Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Tue, 2/24/09, xxxxx@jupiter.com wrote:

From: xxxxx@jupiter.com
Subject: [ntdev] KMDF virtual display driver possible?
To: “Windows System Software Devs Interest List”
Date: Tuesday, February 24, 2009, 4:25 PM

I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster sample that enumerates a single device.???For that device I have successfully installed a functional virtual display driver, that incorporates the KMDF functions from the “featured” toaster sample bus driver.

When the DriverEntry function of the functional bus driver calls WdfDriverCreate, an exception is generated when the WdfFunction array is called, apparently because the table is filled with zeros.???

Checking the link map, I see that my functional driver is bound to a stub driver.???Apparently the KMDF binding never occurs and the KMDF function table is unitialized.???

I’ve concluded that it’s not a matter of KMDF load order as the bus enumerator driver was successfully bound to KMDF.???Is there some reason KMDF will not bind to a WDDM driver??


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

  1. Based on information in this thread: http://www.techtalkz.com/microsoft-device-drivers/251481-iogetdmaadapter-root-enumerated-device-64-bit-windows.html it appears that root-enumerated devices on x64 systems can’t count on the HAL for handling IRP_MN_QUERY_INTERFACE for the BUS_INTERFACE_STANDARD. And this is precisely what I observed with initial testing of my Vista64 root-enumerated virtual display driver.

The thread remarks from Eliyas Yakub seemed to indicate that the alternatives I faced were
a) support IRP_MN_QUERY_INTERFACE in the virtual display driver (along with a myriad of additional IRPs sent for PnP and ACPI)
b) develop a virtual bus enumerator.
Based on the belief that KMDF would simply the handling of WMI, ACPI and PnP issues, I chose to use the dynambus KMDF sample as the basis for a bus enumerator.

The KMDF bus-enumerator loads fine and enumerates a single virtual device. The device driver that I install for this device is a WDDM display driver. It’s not necessary for this WDDM driver to be based on KMDF, however during my testing, I found that although the WDDM driver was now enumerated via the dynambus-derived enumerator, the IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD query was failing. In order to avoid handling this in the functional driver, I concluded that it would be necessary to add the corresponding KMDF functional driver code (toaster.c and power.c) from the “featured” sample driver to my WDDM driver.

It’s important to note that the WDDM driver is based on a working WDDM driver that works properly when loaded on real hardware enumerated from a PCIe bus. And it does so without any special handling of the IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD. It’s only when the same WDDM code is modified to load as a root-enumerated or virtual device that the problems with querying the BUS_INTERFACE_STANDARD occur.

  1. Thank you for the tip as to why the WdfFunctions table is not being initialized. I’ll investigate the makefile rules.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, February 24, 2009 4:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF virtual display driver possible?

  1. KMDF will not help in WDDM driver. Why do you think KMDF will give you here?

  2. this is a build problem, not a load order problem. The WdfFunction array is setup by the KMDF stub library which is linked to your driver. Among other things, we change your entrypoint to FxDriverEntry (where we setup the array) and then call your DriverEntry. My guess is that the stub library and entry point are not being set up b/c the makefile rules for a WDDM driver override some of the KMDF rules

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jupiter.com
Sent: Tuesday, February 24, 2009 4:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF virtual display driver possible?

I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster sample that enumerates a single device. For that device I have successfully installed a functional virtual display driver, that incorporates the KMDF functions from the “featured” toaster sample bus driver.

When the DriverEntry function of the functional bus driver calls WdfDriverCreate, an exception is generated when the WdfFunction array is called, apparently because the table is filled with zeros.

Checking the link map, I see that my functional driver is bound to a stub driver. Apparently the KMDF binding never occurs and the KMDF function table is unitialized.

I’ve concluded that it’s not a matter of KMDF load order as the bus enumerator driver was successfully bound to KMDF. Is there some reason KMDF will not bind to a WDDM driver?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

The term “virtual display driver” as I’m using it in this context, is meant to refer to a kernel-mode device driver that has no hardware resources. Like the toaster sample driver. It handles all upper-level driver calls as a regular device driver would but merely emulates the hardware functionality.

Ken

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Tuesday, February 24, 2009 5:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF virtual display driver possible?

Well, I’ve been out of the graphics driver business (THANK GOD) for couple years but this is what I remembered at the time it was called LDDM.

In xpdm, video miniport talks to videoprt.sys. its km rendering (display) driver(s) talk to kernel mode gdi and d3d.

In WDDM, kernel mode miniport is loaded by displdr.sys, and mainly talk to dxgkrnl. Its rendering (display) drivers are in um. None of them has anything to do with kmdf.

What is your definition of “virtual display driver”


Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Tue, 2/24/09, xxxxx@jupiter.com wrote:

From: xxxxx@jupiter.com
Subject: [ntdev] KMDF virtual display driver possible?
To: “Windows System Software Devs Interest List”
Date: Tuesday, February 24, 2009, 4:25 PM

I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster sample that enumerates a single device. For that device I have successfully installed a functional virtual display driver, that incorporates the KMDF functions from the “featured” toaster sample bus driver.

When the DriverEntry function of the functional bus driver calls WdfDriverCreate, an exception is generated when the WdfFunction array is called, apparently because the table is filled with zeros.

Checking the link map, I see that my functional driver is bound to a stub driver. Apparently the KMDF binding never occurs and the KMDF function table is unitialized.

I’ve concluded that it’s not a matter of KMDF load order as the bus enumerator driver was successfully bound to KMDF. Is there some reason KMDF will not bind to a WDDM driver?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

To work around this issue you do not need to create a bus driver, just a KMDF lower filter below your WDDM driver which answers the query interface irp correctly. In either the filter of bus case you call WdfDeviceAddQueryInterface passing in the filter’s WDFDEVICE or in the bus case the PDO’s WDFDEVICE (not the bus’s FDO!). I would use a lower filter, it is simpler, fewer moving parts and more succinctly solves your problem

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Nicholson
Sent: Tuesday, February 24, 2009 6:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF virtual display driver possible?

  1. Based on information in this thread: http://www.techtalkz.com/microsoft-device-drivers/251481-iogetdmaadapter-root-enumerated-device-64-bit-windows.html it appears that root-enumerated devices on x64 systems can’t count on the HAL for handling IRP_MN_QUERY_INTERFACE for the BUS_INTERFACE_STANDARD. And this is precisely what I observed with initial testing of my Vista64 root-enumerated virtual display driver.

The thread remarks from Eliyas Yakub seemed to indicate that the alternatives I faced were
a) support IRP_MN_QUERY_INTERFACE in the virtual display driver (along with a myriad of additional IRPs sent for PnP and ACPI)
b) develop a virtual bus enumerator.
Based on the belief that KMDF would simply the handling of WMI, ACPI and PnP issues, I chose to use the dynambus KMDF sample as the basis for a bus enumerator.

The KMDF bus-enumerator loads fine and enumerates a single virtual device. The device driver that I install for this device is a WDDM display driver. It’s not necessary for this WDDM driver to be based on KMDF, however during my testing, I found that although the WDDM driver was now enumerated via the dynambus-derived enumerator, the IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD query was failing. In order to avoid handling this in the functional driver, I concluded that it would be necessary to add the corresponding KMDF functional driver code (toaster.c and power.c) from the “featured” sample driver to my WDDM driver.

It’s important to note that the WDDM driver is based on a working WDDM driver that works properly when loaded on real hardware enumerated from a PCIe bus. And it does so without any special handling of the IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD. It’s only when the same WDDM code is modified to load as a root-enumerated or virtual device that the problems with querying the BUS_INTERFACE_STANDARD occur.

  1. Thank you for the tip as to why the WdfFunctions table is not being initialized. I’ll investigate the makefile rules.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, February 24, 2009 4:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF virtual display driver possible?

  1. KMDF will not help in WDDM driver. Why do you think KMDF will give you here?

  2. this is a build problem, not a load order problem. The WdfFunction array is setup by the KMDF stub library which is linked to your driver. Among other things, we change your entrypoint to FxDriverEntry (where we setup the array) and then call your DriverEntry. My guess is that the stub library and entry point are not being set up b/c the makefile rules for a WDDM driver override some of the KMDF rules

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jupiter.com
Sent: Tuesday, February 24, 2009 4:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF virtual display driver possible?

I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster sample that enumerates a single device. For that device I have successfully installed a functional virtual display driver, that incorporates the KMDF functions from the “featured” toaster sample bus driver.

When the DriverEntry function of the functional bus driver calls WdfDriverCreate, an exception is generated when the WdfFunction array is called, apparently because the table is filled with zeros.

Checking the link map, I see that my functional driver is bound to a stub driver. Apparently the KMDF binding never occurs and the KMDF function table is unitialized.

I’ve concluded that it’s not a matter of KMDF load order as the bus enumerator driver was successfully bound to KMDF. Is there some reason KMDF will not bind to a WDDM driver?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OK, that’s a good tip regarding the KMDF lower filter driver. Keeping the bus driver still appeals to me as it allows more flexibility in device enumeration.

I’ve discovered the reason for the build problem that resulted in the symptom where the WdfFunctions table is unitialized. The toaster func driver sources file defines KMDF_VERSION_MAJOR=1. I noticed this before but thought it was solely used for .INF file stamping. It turns out it triggers some different build options which are hinted at in the file sdv_determine_driver_type.mak. Suffice it to say that KMDF_VERSION_MAJOR must be defined in your sources or your KMDF driver will crash during the WdfDriverCreate call. This requirement is mentioned in MSDN documentation under the topic Building and Loading a Framework-based Driver at http://msdn.microsoft.com/en-us/library/aa490028.aspx

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, February 24, 2009 8:59 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF virtual display driver possible?

To work around this issue you do not need to create a bus driver, just a KMDF lower filter below your WDDM driver which answers the query interface irp correctly. In either the filter of bus case you call WdfDeviceAddQueryInterface passing in the filter’s WDFDEVICE or in the bus case the PDO’s WDFDEVICE (not the bus’s FDO!). I would use a lower filter, it is simpler, fewer moving parts and more succinctly solves your problem

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Nicholson
Sent: Tuesday, February 24, 2009 6:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF virtual display driver possible?

  1. Based on information in this thread: http://www.techtalkz.com/microsoft-device-drivers/251481-iogetdmaadapter-root-enumerated-device-64-bit-windows.html it appears that root-enumerated devices on x64 systems can’t count on the HAL for handling IRP_MN_QUERY_INTERFACE for the BUS_INTERFACE_STANDARD. And this is precisely what I observed with initial testing of my Vista64 root-enumerated virtual display driver.

The thread remarks from Eliyas Yakub seemed to indicate that the alternatives I faced were
a) support IRP_MN_QUERY_INTERFACE in the virtual display driver (along with a myriad of additional IRPs sent for PnP and ACPI)
b) develop a virtual bus enumerator.
Based on the belief that KMDF would simply the handling of WMI, ACPI and PnP issues, I chose to use the dynambus KMDF sample as the basis for a bus enumerator.

The KMDF bus-enumerator loads fine and enumerates a single virtual device. The device driver that I install for this device is a WDDM display driver. It’s not necessary for this WDDM driver to be based on KMDF, however during my testing, I found that although the WDDM driver was now enumerated via the dynambus-derived enumerator, the IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD query was failing. In order to avoid handling this in the functional driver, I concluded that it would be necessary to add the corresponding KMDF functional driver code (toaster.c and power.c) from the “featured” sample driver to my WDDM driver.

It’s important to note that the WDDM driver is based on a working WDDM driver that works properly when loaded on real hardware enumerated from a PCIe bus. And it does so without any special handling of the IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD. It’s only when the same WDDM code is modified to load as a root-enumerated or virtual device that the problems with querying the BUS_INTERFACE_STANDARD occur.

  1. Thank you for the tip as to why the WdfFunctions table is not being initialized. I’ll investigate the makefile rules.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, February 24, 2009 4:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF virtual display driver possible?

  1. KMDF will not help in WDDM driver. Why do you think KMDF will give you here?

  2. this is a build problem, not a load order problem. The WdfFunction array is setup by the KMDF stub library which is linked to your driver. Among other things, we change your entrypoint to FxDriverEntry (where we setup the array) and then call your DriverEntry. My guess is that the stub library and entry point are not being set up b/c the makefile rules for a WDDM driver override some of the KMDF rules

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jupiter.com
Sent: Tuesday, February 24, 2009 4:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF virtual display driver possible?

I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster sample that enumerates a single device. For that device I have successfully installed a functional virtual display driver, that incorporates the KMDF functions from the “featured” toaster sample bus driver.

When the DriverEntry function of the functional bus driver calls WdfDriverCreate, an exception is generated when the WdfFunction array is called, apparently because the table is filled with zeros.

Checking the link map, I see that my functional driver is bound to a stub driver. Apparently the KMDF binding never occurs and the KMDF function table is unitialized.

I’ve concluded that it’s not a matter of KMDF load order as the bus enumerator driver was successfully bound to KMDF. Is there some reason KMDF will not bind to a WDDM driver?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Doron, this doesn’t actually work for video drivers. The guys who own
videoport decided that they would limit their stack to only working on PCI
(or PCIe) devices which have interrupts. (This is true for WDDM. XDDM
drivers have a little more lee way.) They read the config space of the
device and fail if it isn’t video class. It also needs an interrupt to
succeed.

To everybody else you might be reading this, I can’t defend or explain these
choices, so please don’t ask me to.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


“Doron Holan” wrote in message
news:xxxxx@ntdev…
> To work around this issue you do not need to create a bus driver, just a
> KMDF lower filter below your WDDM driver which answers the query interface
> irp correctly. In either the filter of bus case you call
> WdfDeviceAddQueryInterface passing in the filter’s WDFDEVICE or in the bus
> case the PDO’s WDFDEVICE (not the bus’s FDO!). I would use a lower filter,
> it is simpler, fewer moving parts and more succinctly solves your problem
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Nicholson
> Sent: Tuesday, February 24, 2009 6:09 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] KMDF virtual display driver possible?
>
> 1) Based on information in this thread:
> http://www.techtalkz.com/microsoft-device-drivers/251481-iogetdmaadapter-root-enumerated-device-64-bit-windows.html
> it appears that root-enumerated devices on x64 systems can’t count on the
> HAL for handling IRP_MN_QUERY_INTERFACE for the BUS_INTERFACE_STANDARD.
> And this is precisely what I observed with initial testing of my Vista64
> root-enumerated virtual display driver.
>
> The thread remarks from Eliyas Yakub seemed to indicate that the
> alternatives I faced were
> a) support IRP_MN_QUERY_INTERFACE in the virtual display driver
> (along with a myriad of additional IRPs sent for PnP and ACPI)
> b) develop a virtual bus enumerator.
> Based on the belief that KMDF would simply the handling of WMI, ACPI and
> PnP issues, I chose to use the dynambus KMDF sample as the basis for a bus
> enumerator.
>
> The KMDF bus-enumerator loads fine and enumerates a single virtual device.
> The device driver that I install for this device is a WDDM display driver.
> It’s not necessary for this WDDM driver to be based on KMDF, however
> during my testing, I found that although the WDDM driver was now
> enumerated via the dynambus-derived enumerator, the IRP_MN_QUERY_INTERFACE
> :: BUS_INTERFACE_STANDARD query was failing. In order to avoid handling
> this in the functional driver, I concluded that it would be necessary to
> add the corresponding KMDF functional driver code (toaster.c and power.c)
> from the “featured” sample driver to my WDDM driver.
>
> It’s important to note that the WDDM driver is based on a working WDDM
> driver that works properly when loaded on real hardware enumerated from a
> PCIe bus. And it does so without any special handling of the
> IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD. It’s only when the same
> WDDM code is modified to load as a root-enumerated or virtual device that
> the problems with querying the BUS_INTERFACE_STANDARD occur.
>
> 2) Thank you for the tip as to why the WdfFunctions table is not being
> initialized. I’ll investigate the makefile rules.
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, February 24, 2009 4:31 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] KMDF virtual display driver possible?
>
> 1) KMDF will not help in WDDM driver. Why do you think KMDF will give you
> here?
>
> 2) this is a build problem, not a load order problem. The WdfFunction
> array is setup by the KMDF stub library which is linked to your driver.
> Among other things, we change your entrypoint to FxDriverEntry (where we
> setup the array) and then call your DriverEntry. My guess is that the
> stub library and entry point are not being set up b/c the makefile rules
> for a WDDM driver override some of the KMDF rules
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@jupiter.com
> Sent: Tuesday, February 24, 2009 4:26 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] KMDF virtual display driver possible?
>
>
> I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster
> sample that enumerates a single device. For that device I have
> successfully installed a functional virtual display driver, that
> incorporates the KMDF functions from the “featured” toaster sample bus
> driver.
>
> When the DriverEntry function of the functional bus driver calls
> WdfDriverCreate, an exception is generated when the WdfFunction array is
> called, apparently because the table is filled with zeros.
>
> Checking the link map, I see that my functional driver is bound to a stub
> driver. Apparently the KMDF binding never occurs and the KMDF function
> table is unitialized.
>
> I’ve concluded that it’s not a matter of KMDF load order as the bus
> enumerator driver was successfully bound to KMDF. Is there some reason
> KMDF will not bind to a WDDM driver?
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

Doron Holan wrote:

To work around this issue you do not need to create a bus driver, just a KMDF lower filter below your WDDM driver which answers the query interface irp correctly.

Is a WDDM driver filterable? XPDM drivers are not.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I don’t think WDDM itself is filterable (not port/miniport model with a direct call interface is really filterable), but the IRPs that WDDM sends down the stack (in this case a QI irp) is certainly filterable b/c they are using std WDM mechanisms to get what they need from the underlying bus

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, February 25, 2009 9:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF virtual display driver possible?

Doron Holan wrote:

To work around this issue you do not need to create a bus driver, just a KMDF lower filter below your WDDM driver which answers the query interface irp correctly.

Is a WDDM driver filterable? XPDM drivers are not.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Well, XPDM is semi-filterable, but not in the irp/wdm path. You write a dummy display driver(.dll) which in turn loads the real display driver and captures the real entry points. In the miniport’s inf file, specify the dummy display driver as if it were a real display driver. In such way, may gdi calls can be routed to the dummy driver first but I remember having problem with d3d stuff. I had such a beast.

Filtering on WDDM is cleaner and probably easier for d3d stuff.

Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Wed, 2/25/09, Tim Roberts wrote:

From: Tim Roberts
Subject: Re: [ntdev] KMDF virtual display driver possible?
To: “Windows System Software Devs Interest List”
Date: Wednesday, February 25, 2009, 9:56 AM

Doron Holan wrote:
> To work around this issue you do not need to create a bus driver, just a KMDF lower filter below your WDDM driver which answers the query interface irp correctly.

Is a WDDM driver filterable?? XPDM drivers are not.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Thank you for the information, Jake. To clarify my understanding of this issue, I’ll refer to slide 3 of this architecture presentation.
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWPR05005_WinHEC05.ppt

It shows that the WDDM kernel mode driver binds to DXGKNRL.SYS, not the XPDM module videoprt.sys. So I’m assuming that you mean that dxgkrnl.sys, and not some other layer, examines the PCI (or PCIe) config space looking for the device type. I would have thought that such a check was only done for testing compatibility with an OS-supplied default VGA driver. And indeed the registry does seem to have a way of keeping track of which display drivers are VGA compatible.

Do you know the name of the dxgkrnl function that checks the config space? I’d like to observe this process while running a checked build.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Wednesday, February 25, 2009 8:18 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KMDF virtual display driver possible?

Doron, this doesn’t actually work for video drivers. The guys who own
videoport decided that they would limit their stack to only working on PCI
(or PCIe) devices which have interrupts. (This is true for WDDM. XDDM
drivers have a little more lee way.) They read the config space of the
device and fail if it isn’t video class. It also needs an interrupt to
succeed.

To everybody else you might be reading this, I can’t defend or explain these
choices, so please don’t ask me to.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


“Doron Holan” wrote in message
news:xxxxx@ntdev…
> To work around this issue you do not need to create a bus driver, just a
> KMDF lower filter below your WDDM driver which answers the query interface
> irp correctly. In either the filter of bus case you call
> WdfDeviceAddQueryInterface passing in the filter’s WDFDEVICE or in the bus
> case the PDO’s WDFDEVICE (not the bus’s FDO!). I would use a lower filter,
> it is simpler, fewer moving parts and more succinctly solves your problem
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Nicholson
> Sent: Tuesday, February 24, 2009 6:09 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] KMDF virtual display driver possible?
>
> 1) Based on information in this thread:
> http://www.techtalkz.com/microsoft-device-drivers/251481-iogetdmaadapter-root-enumerated-device-64-bit-windows.html
> it appears that root-enumerated devices on x64 systems can’t count on the
> HAL for handling IRP_MN_QUERY_INTERFACE for the BUS_INTERFACE_STANDARD.
> And this is precisely what I observed with initial testing of my Vista64
> root-enumerated virtual display driver.
>
> The thread remarks from Eliyas Yakub seemed to indicate that the
> alternatives I faced were
> a) support IRP_MN_QUERY_INTERFACE in the virtual display driver
> (along with a myriad of additional IRPs sent for PnP and ACPI)
> b) develop a virtual bus enumerator.
> Based on the belief that KMDF would simply the handling of WMI, ACPI and
> PnP issues, I chose to use the dynambus KMDF sample as the basis for a bus
> enumerator.
>
> The KMDF bus-enumerator loads fine and enumerates a single virtual device.
> The device driver that I install for this device is a WDDM display driver.
> It’s not necessary for this WDDM driver to be based on KMDF, however
> during my testing, I found that although the WDDM driver was now
> enumerated via the dynambus-derived enumerator, the IRP_MN_QUERY_INTERFACE
> :: BUS_INTERFACE_STANDARD query was failing. In order to avoid handling
> this in the functional driver, I concluded that it would be necessary to
> add the corresponding KMDF functional driver code (toaster.c and power.c)
> from the “featured” sample driver to my WDDM driver.
>
> It’s important to note that the WDDM driver is based on a working WDDM
> driver that works properly when loaded on real hardware enumerated from a
> PCIe bus. And it does so without any special handling of the
> IRP_MN_QUERY_INTERFACE :: BUS_INTERFACE_STANDARD. It’s only when the same
> WDDM code is modified to load as a root-enumerated or virtual device that
> the problems with querying the BUS_INTERFACE_STANDARD occur.
>
> 2) Thank you for the tip as to why the WdfFunctions table is not being
> initialized. I’ll investigate the makefile rules.
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, February 24, 2009 4:31 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] KMDF virtual display driver possible?
>
> 1) KMDF will not help in WDDM driver. Why do you think KMDF will give you
> here?
>
> 2) this is a build problem, not a load order problem. The WdfFunction
> array is setup by the KMDF stub library which is linked to your driver.
> Among other things, we change your entrypoint to FxDriverEntry (where we
> setup the array) and then call your DriverEntry. My guess is that the
> stub library and entry point are not being set up b/c the makefile rules
> for a WDDM driver override some of the KMDF rules
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@jupiter.com
> Sent: Tuesday, February 24, 2009 4:26 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] KMDF virtual display driver possible?
>
>
> I have a Vista 64 Virtual bus enumerator driver based on the KMDF toaster
> sample that enumerates a single device. For that device I have
> successfully installed a functional virtual display driver, that
> incorporates the KMDF functions from the “featured” toaster sample bus
> driver.
>
> When the DriverEntry function of the functional bus driver calls
> WdfDriverCreate, an exception is generated when the WdfFunction array is
> called, apparently because the table is filled with zeros.
>
> Checking the link map, I see that my functional driver is bound to a stub
> driver. Apparently the KMDF binding never occurs and the KMDF function
> table is unitialized.
>
> I’ve concluded that it’s not a matter of KMDF load order as the bus
> enumerator driver was successfully bound to KMDF. Is there some reason
> KMDF will not bind to a WDDM driver?
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

> Well, XPDM is semi-filterable, but not in the irp/wdm path. You write a
dummy display driver(.dll)

which in turn loads the real display driver and captures the real entry
points. In the miniport’s inf file,

specify the dummy display driver as if it were a real display driver. In
such way, may gdi calls can be

routed to the dummy driver first but I remember having problem with d3d
stuff. I had such a beast.

I just did this a few weeks ago and it works just fine. Not sure what D3D
problems you’re referring to though.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: 25. februar 2009 13:21
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF virtual display driver possible?

Well, XPDM is semi-filterable, but not in the irp/wdm path. You write a
dummy display driver(.dll) which in turn loads the real display driver and
captures the real entry points. In the miniport’s inf file, specify the
dummy display driver as if it were a real display driver. In such way, may
gdi calls can be routed to the dummy driver first but I remember having
problem with d3d stuff. I had such a beast.

Filtering on WDDM is cleaner and probably easier for d3d stuff.

Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Wed, 2/25/09, Tim Roberts wrote:

From: Tim Roberts
Subject: Re: [ntdev] KMDF virtual display driver possible?
To: “Windows System Software Devs Interest List”
Date: Wednesday, February 25, 2009, 9:56 AM

Doron Holan wrote:
> To work around this issue you do not need to create a bus driver, just a
KMDF lower filter below your WDDM driver which answers the query interface
irp correctly.

Is a WDDM driver filterable? XPDM drivers are not.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Good luck. I don’t want to remember anything that’s related to graphics:)

— On Wed, 2/25/09, Soren Dreijer wrote:

From: Soren Dreijer
Subject: RE: [ntdev] KMDF virtual display driver possible?
To: “Windows System Software Devs Interest List”
Date: Wednesday, February 25, 2009, 8:08 PM

> Well, XPDM is semi-filterable, but not in the irp/wdm path. You write a dummy display driver(.dll)
> which in turn loads the real display driver and captures the real entry points. In the miniport’s inf file,
> specify the dummy display driver as if it were a real display driver. In such way, may gdi calls can be
> routed to the dummy driver first but I remember having problem with d3d stuff. I had such a beast.

I just did this a few weeks ago and it works just fine. Not sure what D3D problems you?re referring to though.
?

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: 25. februar 2009 13:21
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF virtual display driver possible?
?

Well, XPDM is semi-filterable, but not in the irp/wdm path. You write a dummy display driver(.dll) which in turn loads the real display driver and captures the real entry points. In the miniport’s inf file, specify the dummy display driver as if it were a real display driver. In such way, may gdi calls can be routed to the dummy driver first but I remember having problem with d3d stuff. I had such a beast.

Filtering on WDDM is cleaner and probably easier for d3d stuff.

Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Wed, 2/25/09, Tim Roberts wrote:

From: Tim Roberts
Subject: Re: [ntdev] KMDF virtual display driver possible?
To: “Windows System Software Devs Interest List”
Date: Wednesday, February 25, 2009, 9:56 AM

Doron Holan wrote:
> To work around this issue you do not need to create a bus driver, just a KMDF lower filter below your WDDM driver which answers the query interface irp correctly.

Is a WDDM driver filterable?? XPDM drivers are not.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer