How to get PDO from PortCls miniport driver on Win7

NTDEV
1

I am developing a PortCls+KMDF miniport driver and have a need to access the PDO in StartDevice.

With AVStream it’s no big deal, as you have KsGetDeviceForDeviceObject(), but that doesn’t help me. Somebody found experimentally that you can peek at PortCls’s own device extension from the FDO to find a pointer to the PDO:

http://www.winvistatips.com/threads/portcls-getting-the-pdo-inside-startdevice.191725/

Currently my code uses the shiny new Win8 function PcGetPhysicalDeviceObject, but my customer requires Win7 support.

Should I attempt the hack described above, or does anybody know a better idea?

Also, is there an easy way in kernel mode that I can build one driver for Win7 and up, but dynamically link to the PcGetPhysicalDeviceObject function when it’s available, to minimize my use of the dirty hack, or should I just build separate drivers for the 7 versus 8+?

2

I tried MmGetSystemRoutineAddress(“PcGetPhysicalDeviceObject”) and it returned NULL on Windows 8.1, so I’m guessing PortClass support functions don’t fit in MmGetSystemRoutineAddress’s category of “routines exported by the kernel or HAL, not for any driver-defined routine”.

3

How do you get the PDO to pass to WdfMiniportDeviceCreate? You can retrieve that PDO from the WDFDEVICE by calling WdfDeviceWdmGetPhysicalDeviceObject later

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, June 30, 2015 12:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to get PDO from PortCls miniport driver on Win7

I am developing a PortCls+KMDF miniport driver and have a need to access the PDO in StartDevice.

With AVStream it’s no big deal, as you have KsGetDeviceForDeviceObject(), but that doesn’t help me. Somebody found experimentally that you can peek at PortCls’s own device extension from the FDO to find a pointer to the PDO:

http://www.winvistatips.com/threads/portcls-getting-the-pdo-inside-startdevice.191725/

Currently my code uses the shiny new Win8 function PcGetPhysicalDeviceObject, but my customer requires Win7 support.

Should I attempt the hack described above, or does anybody know a better idea?

Also, is there an easy way in kernel mode that I can build one driver for Win7 and up, but dynamically link to the PcGetPhysicalDeviceObject function when it’s available, to minimize my use of the dirty hack, or should I just build separate drivers for the 7 versus 8+?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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