Device node parent

NTDEV
1

Hello,

is there WDM API function to obtain parent device node in kernel mode? I know that _DEVICE_NODE->Parent points to parent node, but _DEVICE_NODE isn’t officially documented. For KMDF there is WdfPdoGetParent available and for user mode CM_Get_Parent. In portingtables.doc (Summary of KMDF and WDM Equivalents) there is no WDM equivalent for WdfPdoGetParent. So is there really no way how to get it?

Thanks.

2

If you are the bus driver, you track the parent FDO in the child PDO device extension. From a function or filter FDO, there is no way to query for the parent device higher in the tree. What bigger problem are you trying to solve?

d

-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@centrum.cz
Sent: Thursday, April 5, 2018 10:33 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device node parent

Hello,

is there WDM API function to obtain parent device node in kernel mode? I know that _DEVICE_NODE->Parent points to parent node, but _DEVICE_NODE isn’t officially documented. For KMDF there is WdfPdoGetParent available and for user mode CM_Get_Parent. In portingtables.doc (Summary of KMDF and WDM Equivalents) there is no WDM equivalent for WdfPdoGetParent. So is there really no way how to get it?

Thanks.

—
NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

3

We have more use cases for parent PDO:

  • One is for example we need to know if disk device is removable, so we look at its parent PDO and check for removable flag in DO.
  • Other use case is we need to detect kernel streaming proxy device stack, so we register our device filter driver in MEDIA device class and we know that parent PDO of PDO in kernel streaming proxy stack implements “KSNAME_Server” interface. We are attached to kernel streaming proxy stack by Windows and we need to query its parent PDO for that interface.
4

xxxxx@centrum.cz wrote:

We have more use cases for parent PDO:
…

  • Other use case is we need to detect kernel streaming proxy device stack, so we register our device filter driver in MEDIA device class and we know that parent PDO of PDO in kernel streaming proxy stack implements “KSNAME_Server” interface. We are attached to kernel streaming proxy stack by Windows and we need to query its parent PDO for that interface.

You’re going to have to explain that one to me, because there are things
here that don’t make sense.

I’ve been doing KS for 20 years, but I’ve never heard of a “kernel
streaming proxy device”.  The phrase “kernel streaming proxy” refers to
the user-mode ksproxy.ax DLL that connects a KS driver to DirectShow.

You are using the phrase “device filter driver,” but each of those terms
has multiple meanings.  The term “filter” in kernel streaming refers to
the top-level objects that KS driver implement.  The driver exposes
“filters”, and each “filter” contains “pins”, which do the real work. 
That meaning is unrelated to the term “filter driver” as used in WDM
device stacks.  Which one do you mean here?  If you have a driver in
MEDIA device class, then you have an FDO, and you are not a filter
driver.  In that case, you can certainly get the PDO for your FDO. 
AVStream tracks that, and you need it to submit I/O requests to your
hardware.  But, that driver is not going to be another KS driver.

I hope you can enlighten me about your real architecture.

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

5

By filter driver I mean “filter driver” as used in WDM. It is registered in MEDIA device class as UpperFilter and it is attached to device stacks of MEDIA devices.

Purpose of our driver is to control application’s access to camera device. We can be registered in new Camera device class introduced since Win10 RS3, but then we always see requests coming from svchost.exe. We need to know real process (application) accessing camera. When we are as upper filter driver above device “SW{96E080C7-143C-11D1-B40F-00A0C9223196}{3C0D501A-140B-11D1-B40F-00A0C9223196}” then we see real processes accessing camera. Here is output of !devnode 0 1:

DevNode 0x84d6fe28 for PDO 0x84d70d30
InstancePath is “ROOT\SYSTEM\0000”
ServiceName is “swenum”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xbc5d89d0 for PDO 0xb2249a30
InstancePath is “SW{96E080C7-143C-11D1-B40F-00A0C9223196}{3C0D501A-140B-11D1-B40F-00A0C9223196}”
ServiceName is “MSKSSRV”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)

Driver mskssrv.sys is “Microsoft Streaming Service Proxy”. Our filter driver registered in MEDIA device class is attached by Windows to device stack where MSKSSRV is functional driver. We had idea to detect it via its parent device node (where swenum is functional driver) implementing KSNAME_Server interface.