Virtually enumerated NetAdapterCx client fails NetAdapterCreate() call

Hi

I have a bus driver (FD0-0) which statically creates 2 PDOs (PDO-1 and PDO-2)
My bus driver INF has below.
%DeviceDesc%=Device, PCI\VEN_vvvv&DEV_dddd
So when PCI creates the PDO(-1) for my device, my FDO-0 gets loaded, and then I act as a bus driver as well.

The FDO (Say FDO-2) for PDO-2 will eventually be a NetAdapter CxClient.
To quickly test the loading of this FDO-2 under this virtual/static enumeration model, I used the NetAdapterCx Client sample driver that MS has on github.

That INF has below
%RTL8168.DeviceDesc% = RTL8168.ndi, PCI\VEN_10EC&DEV_8168&REV_03
%RTL8168.DeviceDesc% = RTL8168.ndi, PCI\VEN_10EC&DEV_8168&SUBSYS_816810EC&REV_03

So changed the DeviceId/HW-ID to what was there in that sample INF during the PDO-2 creation in my bus driver (FDO-0).

Then during loading of the FDO-2, I see below

  • DriverEntry() o.k.
  • Inside EvtAddDevice, a NetAapterCx client has to call NetAdapterCreate() –> FAILING !!! - NTSTATUS ffffffff`c00000bb STATUS_NOT_SUPPORTED
    Was doing WDF/NetAdapterCx src debug, so exact call stack back below.

Not sure if this has to do anything the way the PDO-2 got exposed to system ( I created it) rather than PCI.SYS etc.
Please let me why this NetAdapterCreate() is failing. This in fact is the first call a client makes into NetAdapterCx framework.

Thanks!


00 ffff9d00587e68d8 fffff805dd50d898 ndis!NdisWdfPnPAddDevice
01 ffff9d00587e68e0 fffff805dd503234 NetAdapterCx!NxDevice::AdapterAdd+0x98 [minio\ndis\cx\sys\nxdevice.cpp @ 144]
02 ffff9d00587e6930 fffff805dd50880c NetAdapterCx!NxAdapter::_Create+0x218 [minio\ndis\cx\sys\nxadapter.cpp @ 559]
03 ffff9d00587e69d0 fffff805dd4eb78c NetAdapterCx!imp_NetAdapterCreate+0x2fc [minio\ndis\cx\sys\nxadapterapi.cpp @ 240]
04 ffff9d00587e6a30 fffff805dd4eaf2a RtEthSample!NetAdapterCreate+0x5c [c:\program files (x86)\windows kits\10\include\10.0.17134.0\km\netadaptercx\1.2\netadapter.h @ 835]
05 ffff9d00587e6a80 fffff805d6b3e930 RtEthSample!EvtDriverDeviceAdd+0x63a [c:_projects\netadapter-cx-driver-samples-master\rtethsample\driver.cpp @ 136]
06 (Inline Function) ---------------- Wdf01000!FxDriverDeviceAdd::Invoke+0x53 [minkernel\wdf\framework\shared\inc\private\common\fxdrivercallbacks.hpp @ 61] 07 ffff9d00587e7020 fffff805d6b41c96 Wdf01000!FxDriver::AddDevice+0xac [minkernel\wdf\framework\shared\core\km\fxdriverkm.cpp @ 72] 08 ffff9d00587e7440 fffff801679f1a83 Wdf01000!FxDriver::AddDevice+0x26 [minkernel\wdf\framework\shared\core\km\fxdriverkm.cpp @ 51] 09 ffff9d00587e7470 fffff80167eab789 nt!PpvUtilCallAddDevice+0x3b 0a ffff9d00587e74b0 fffff80167e77687 nt!PnpCallAddDevice+0x59 0b ffff9d00587e7540 fffff80167e768c9 nt!PipCallDriverAddDevice+0x813 0c ffff9d00587e76f0 fffff80167efb7fd nt!PipProcessDevNodeTree+0x1f1 0d ffff9d00587e7970 fffff801679d4839 nt!PiProcessStartSystemDevices+0x59 0e ffff9d00587e79c0 fffff801678c6445 nt!PnpDeviceActionWorker+0x469 0f ffff9d00587e7a80 fffff80167981ae7 nt!ExpWorkerThread+0xf5 10 ffff9d00587e7b10 fffff80167a3fb86 nt!PspSystemThreadStartup+0x47 11 ffff9d00587e7b60 00000000`00000000 nt!KiStartSystemThread+0x16

I tried below scenario instead and that works.
This was just to ensure my target container has all the components well etc.

Change the sample NetAdapterCx client INF to instead used my PCI vendor/device ID, so the sample driver gets loaded.
In this scenario, AddDevice succeeds (and obviously in later in EvtPrepareHW it fails when it expects some signature in expected mmio space).

So looks like when User creates the PDO, the NetAdapterCreate() fails, but if PCI.sys creates it, it is successful.

7: kd> k

Child-SP RetAddr Call Site

00 ffff820283a8a1c0 fffff80160228980 RtEthSample!RtInitializeHardware+0x4bd [c:_projects\netadapter-cx-driver-samples-master\rtethsample\device.cpp @ 170]
01 ffff820283a8a630 fffff8015b2f4a08 RtEthSample!EvtDevicePrepareHardware+0x130 [c:_projects\netadapter-cx-driver-samples-master\rtethsample\device.cpp @ 281]
02 ffff820283a8a7a0 fffff8015b3209c6 Wdf01000!FxPnpDevicePrepareHardware::InvokeClient+0x28 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 347]
03 ffff820283a8a7f0 fffff8015b2eaa37 Wdf01000!FxPrePostCallback::InvokeStateful+0x2c0c6 [minkernel\wdf\framework\shared\irphandlers\pnp\cxpnppowercallbacks.cpp @ 496]
04 (Inline Function) ---------------- Wdf01000!FxPnpDevicePrepareHardware::Invoke+0x1b [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 321] 05 ffff820283a8a830 fffff8015b2e1efa Wdf01000!FxPkgPnp::PnpPrepareHardware+0xe7 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 3599] 06 ffff820283a8a880 fffff8015b2eac56 Wdf01000!FxPkgPnp::PnpEventHardwareAvailable+0x7a [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1399] 07 (Inline Function) ---------------- Wdf01000!FxPkgPnp::PnpEnterNewState+0xce [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1234]
08 ffff820283a8a8c0 fffff8015b2ee7e8 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x1a6 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1150]
09 ffff820283a8a970 fffff8015b2ee6ff Wdf01000!FxPkgPnp::_PnpProcessEventInner+0x58 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 981]
0a (Inline Function) ---------------- Wdf01000!FxEventQueue::EventQueueWorker+0x83 [minkernel\wdf\framework\shared\irphandlers\pnp\eventqueue.cpp @ 277] 0b ffff820283a8a9b0 fffff801fe45ef6c Wdf01000!FxWorkItemEventQueue::_WorkItemCallback+0x9f [minkernel\wdf\framework\shared\irphandlers\pnp\km\eventqueuekm.cpp @ 110] 0c ffff820283a8aa10 fffff801fe42b445 nt!IopProcessWorkItem+0x12c 0d ffff820283a8aa80 fffff801fe4e6ae7 nt!ExpWorkerThread+0xf5 0e ffff820283a8ab10 fffff801fe5a4b86 nt!PspSystemThreadStartup+0x47 0f ffff820283a8ab60 00000000`00000000 nt!KiStartSystemThread+0x16

xxxxx@yahoo.com wrote:

I have a bus driver (FD0-0) which statically creates 2 PDOs (PDO-1 and PDO-2)
My bus driver INF has below.
%DeviceDesc%=Device, PCI\VEN_vvvv&DEV_dddd
So when PCI creates the PDO(-1) for my device, my FDO-0 gets loaded, and then I act as a bus driver as well.

The FDO (Say FDO-2) for PDO-2 will eventually be a NetAdapter CxClient.
To quickly test the loading of this FDO-2 under this virtual/static enumeration model, I used the NetAdapterCx Client sample driver that MS has on github.

That INF has below
%RTL8168.DeviceDesc% = RTL8168.ndi, PCI\VEN_10EC&DEV_8168&REV_03
%RTL8168.DeviceDesc% = RTL8168.ndi, PCI\VEN_10EC&DEV_8168&SUBSYS_816810EC&REV_03

So changed the DeviceId/HW-ID to what was there in that sample INF during the PDO-2 creation in my bus driver (FDO-0).

I can’t tell what you’re saying there.  Your real hardware INF should
match PCI\VEN_vvvv&DEV_dddd.  That loads your FDO-1.  Your FDO creates
PDO-2 with some hardware ID, entirely up to you.  Your NetAdapterCx
client INF needs to match whatever hardware ID you invented in your
FDO-1.  Is that what you did?  Did you change the INF to state that your
device is not a physical device, and is not on the PCI bus?

Did any of your callbacks get called?  There isn’t really enough
information in the config structure to accept or reject you, so I’m
wondering if it called a callback and got a strange answer.


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

Hi Tim

Issue is resolved now, I had to expose GUID_BUS_INTERFACE_STANDARD on the PDO-2 I created to make OS happy…

>
I can’t tell what you’re saying there.? Your real hardware INF should
match PCI\VEN_vvvv&DEV_dddd.? That loads your FDO-1.? Your FDO creates
PDO-2 with some hardware ID, entirely up to you.? Your NetAdapterCx
client INF needs to match whatever hardware ID you invented in your
FDO-1.? Is that what you did?? Did you change the INF to state that your
device is not a physical device, and is not on the PCI bus?
<<
This exercise was just for test purposes.
Since a) NetAdapterCreate() call was failing while loading the FDO-2 on a PDO-2 created by me, I just wanted to ensure such issue doesn’t exist if the b) same FDO-2 is loaded instead on a PCI.sys created PDO.
I do not yet have a NetAdapterCx client driver for my HW. MS has a sample NetAdapterCx Client for some HW. So to test b) I just changed the sample INF to load for my HW. Again this is just for quick test purpose to ensure NetAdapterCreate() succeeds in this case.

Thanks

Hi

> whatever hardware ID you invented
My other PDO (PDO-1) is a USB Host controller (emulated, it?s FDO will be using UDECX).
Does the HW-ID needs to be in any specific/standard format? I just gave one string I invented myself and it works.


MSDN has below on setup classes
*This class includes USB host controllers and USB hubs, but not USB peripherals. Drivers for this class are system-supplied.
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-reserved-for-system-use
* USBDevice includes all USB devices that do not belong to another class. This class is not used for USB host controllers and hubs.
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors

For this PDO-1 (emulated USB Host controller) calls, I am using the values listed. But none of these seem to matter, they just seem to be used to show up in device properties tab and seem to get overridden by what?s inside the INF eventually.
WdfDeviceInitSetDeviceType FILE_DEVICE_USBEX
WdfDeviceInitSetDeviceClass GUID_DEVCLASS_USB


Also my bus driver (FDO-0) is of SYSTEM class. My FD0-2 (NIC driver) gets listed under Network-Adapters. But this FDO-1 (emulated USB host controller) gets listed as child of FDO-0.

Is there a way to get it listed separately (under system devices or better under USB host controllers) in device manager?
I tired giving in INF the CLASS as USB, but it doesn’t matter, it just gets listed beneath its creator, the bus_Driver.
If I give my own CLASS/CLASSGUID it just doesn?t even show up in Device-Manager, but is loaded/running! That I suppose due to https://www.osr.com/blog/2017/10/11/universal-infs-classinstall32-section/ ?

Thanks

xxxxx@yahoo.com wrote:

My other PDO (PDO-1) is a USB Host controller (emulated, it?s FDO will be using UDECX).
Does the HW-ID needs to be in any specific/standard format? I just gave one string I invented myself and it works.

If you are providing your own INF for that PDO, then it doesn’t matter
at all.  The only time it matters is if you are planning to be driven by
a standard driver with an existing INF.

MSDN has below on setup classes
*This class includes USB host controllers and USB hubs, but not USB peripherals. Drivers for this class are system-supplied.
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-reserved-for-system-use
* USBDevice includes all USB devices that do not belong to another class. This class is not used for USB host controllers and hubs.

Yes, although remember that USBDevice is brand-new, and does not exist
prior to Windows 10.

 

For this PDO-1 (emulated USB Host controller) calls, I am using the values listed. But none of these seem to matter, they just seem to be used to show up in device properties tab and seem to get overridden by what?s inside the INF eventually.
WdfDeviceInitSetDeviceType FILE_DEVICE_USBEX
WdfDeviceInitSetDeviceClass GUID_DEVCLASS_USB

Right.  In the vast majority of cases, the device type is merely
decorative.  If there is an INF, that’s what is important.

Also my bus driver (FDO-0) is of SYSTEM class. My FD0-2 (NIC driver) gets listed under Network-Adapters. But this FDO-1 (emulated USB host controller) gets listed as child of FDO-0.

Well, FDO-0 created PDO-1, so it IS a child of FDO-0, but that should
only be shown in the “Devices by Connection” view.  As long as you have
an INF for FDO-1, it should be listed in the section identified by the
INF.  Do you have an INF for PDO-1?

 

> Is there a way to get it listed separately (under system devices or better under USB host controllers) in device manager?
> I tired giving in INF the CLASS as USB, but it doesn’t matter, it just gets listed beneath its creator, the bus_Driver.
> If I give my own CLASS/CLASSGUID it just doesn?t even show up in Device-Manager, but is loaded/running! That I suppose due to https://www.osr.com/blog/2017/10/11/universal-infs-classinstall32-section/ ?

Are you writing a universal driver?  Given your design, I don’t see how
you can.


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

Setting the device type and device class will not change what device manager shows as the class of the device. This is entirely controlled by the INF which is installed on the device and the class of that INF. Do you have separate INFs for each of your different FDOs?

-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@yahoo.com
Sent: Monday, May 14, 2018 12:47 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtually enumerated NetAdapterCx client fails NetAdapterCreate() call

Hi

>> whatever hardware ID you invented
My other PDO (PDO-1) is a USB Host controller (emulated, it?s FDO will be using UDECX).
Does the HW-ID needs to be in any specific/standard format? I just gave one string I invented myself and it works.


MSDN has below on setup classes
This class includes USB host controllers and USB hubs, but not USB peripherals. Drivers for this class are system-supplied.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Finstall%2Fsystem-defined-device-setup-classes-reserved-for-system-use&amp;data=02|01|Doron.Holan%40microsoft.com|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=3KfH57DP%2F4blUR%2FtCRPaO95ia5ezwAzBQW4BDf2IlA4%3D&amp;reserved=0
USBDevice includes all USB devices that do not belong to another class. This class is not used for USB host controllers and hubs.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Finstall%2Fsystem-defined-device-setup-classes-available-to-vendors&amp;data=02|01|Doron.Holan%40microsoft.com|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=GEwbhPBlwYz3aAgJN5XWPS2%2BXosRIHKjYDq7au2YWhg%3D&amp;reserved=0

For this PDO-1 (emulated USB Host controller) calls, I am using the values listed. But none of these seem to matter, they just seem to be used to show up in device properties tab and seem to get overridden by what?s inside the INF eventually.
WdfDeviceInitSetDeviceType FILE_DEVICE_USBEX
WdfDeviceInitSetDeviceClass GUID_DEVCLASS_USB


Also my bus driver (FDO-0) is of SYSTEM class. My FD0-2 (NIC driver) gets listed under Network-Adapters. But this FDO-1 (emulated USB host controller) gets listed as child of FDO-0.
> Is there a way to get it listed separately (under system devices or better under USB host controllers) in device manager?
> I tired giving in INF the CLASS as USB, but it doesn’t matter, it just gets listed beneath its creator, the bus_Driver.
> If I give my own CLASS/CLASSGUID it just doesn?t even show up in Device-Manager, but is loaded/running! That I suppose due to https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.osr.com%2Fblog%2F2017%2F10%2F11%2Funiversal-infs-classinstall32-section%2F&amp;data=02|01|Doron.Holan%40microsoft.com|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=sQds%2BoN971XXor7oRSbj4u%2F6Ix%2BkHmpkmJ2W6OOL6Ec%3D&amp;reserved=0 ?

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:>

Thanks Tim/Doron.

>Are you writing a universal driver?? Given your design, I don’t see how you can.<<
My driver build spew says below, though looks like there are some INF restrictions for universal drivers?
“1>Driver is a Universal Driver.”

>Well, FDO-0 created PDO-1, so it IS a child of FDO-0, but that should only be shown in the “Devices by Connection” view.? <<
O.k. then that is the case I am observing.
But I was wondering if it just shows up by itself separate either in SYSTEM or ‘USB controllers’, then I can set the ‘Disable UI’ for PDO-0 bus driver, so that it doesn’t shown up in device/manager.

>As long as you have an INF for FDO-1, it should be listed in the section identified by the INF.? Do you have an INF for PDO-1? <<
My 3 INFs are below

— PDO-0 / Bus Driver —
Class=System
ClassGuid={4d36e97d-e325-11ce-bfc1-08002be10318}
[Standard.NTamd64]
%My.DeviceDesc%=MyDevice, PCI\VEN_vvvv&DEV_dddd

— PDO-1 / Host Controller —
Class=USB
ClassGUID={36FC9E60-C465-11CF-8056-444553540000}
%My.HC%=MyDeviceHC, MySubDevice\HostContoller ;-> Just made up string like this
;%My.HC%=MyDeviceHC, PCI\VEN_vvvv&DEV_dddd\HostController ;–> Didn’t work, but my Class/GUID could have still been either USB or SYSTEM though.

— PDO-2 / NIC Driver —
Class = Net
ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318}
%MyNet.DeviceDesc% = MyNet.ndi, PCI\VEN_vvvv&DEV_dddd&REV_03

Device manager is a power user tool. I would not hide the device (and you can still show hidden devices)

Bent from my phone


From: xxxxx@yahoo.com
Sent: Tuesday, May 15, 2018 8:16 PM
Subject: RE:[ntdev] Virtually enumerated NetAdapterCx client fails NetAdapterCreate() call
To: Windows System Software Devs Interest List

Thanks Tim/Doron.

>>Are you writing a universal driver?? Given your design, I don’t see how you can.<<
My driver build spew says below, though looks like there are some INF restrictions for universal drivers?
“1>Driver is a Universal Driver.”

>>Well, FDO-0 created PDO-1, so it IS a child of FDO-0, but that should only be shown in the “Devices by Connection” view.? <<
O.k. then that is the case I am observing.
But I was wondering if it just shows up by itself separate either in SYSTEM or ‘USB controllers’, then I can set the ‘Disable UI’ for PDO-0 bus driver, so that it doesn’t shown up in device/manager.

>>As long as you have an INF for FDO-1, it should be listed in the section identified by the INF.? Do you have an INF for PDO-1? <<
My 3 INFs are below

— PDO-0 / Bus Driver —
Class=System
ClassGuid={4d36e97d-e325-11ce-bfc1-08002be10318}
[Standard.NTamd64]
%My.DeviceDesc%=MyDevice, PCI\VEN_vvvv&DEV_dddd

— PDO-1 / Host Controller —
Class=USB
ClassGUID={36FC9E60-C465-11CF-8056-444553540000}
%My.HC%=MyDeviceHC, MySubDevice\HostContoller ;-> Just made up string like this
;%My.HC%=MyDeviceHC, PCI\VEN_vvvv&DEV_dddd\HostController ;–> Didn’t work, but my Class/GUID could have still been either USB or SYSTEM though.

— PDO-2 / NIC Driver —
Class = Net
ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318}
%MyNet.DeviceDesc% = MyNet.ndi, PCI\VEN_vvvv&DEV_dddd&REV_03


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:>

>> I would not hide the device (and you can still show hidden devices)<<
O.k.

I have related question on this. While creating the child PDOs, it has context, state in it, corresponding accessor WDF_DECLARE_CONTEXT_TYPE_WITH_NAME.
I exposed an driver-defined interface on PDO-1 (same one on PDO-2 as well), for corresponding child FDO-1 to communicate and could successfully call it.

But within interface func given wdfdevice(fdo-1), how do I get hold of say Wdfdevice(pdo-1) or even the wdfdevice(fdo-0)? I was not able to find any Wdf[Device/Fdo]Get[Parent/Pdo]…() funcs that do this?
I guess I could do this by providing that info as part of an accessor func in the interface itself and enforcing semantics on the rest of the interface funcs to send that back as a param etc. But wanted to see if I can do this in less number of steps.

My !wdfdevice dumps below - Basically from !wdfdevice(3) below, how do I get to !wdfdevice(2) or even Wdfdevice(1)
Also Wdfdevice(3) says no parent, should one of the two above it be a parent?

3: kd> !wdfdevice 0x000031fe`d2592f68 >>>>>>>>>(FDO-0 BUS driver)
WDM PDEVICE_OBJECTs: self ffffce012da66380, attached ffffce012da66040, pdo ffffce012a1d2800
Device is the power policy owner for the stack

3: kd> !wdfdevice 0x000031fe`d258cb38 >>>>>>(PDO-1 HostController)
WDM PDEVICE_OBJECTs: self ffffce012da75d10
Device is NOT the power policy owner for the stack

Parent WDFDEVICE 000031fed2592f68

3: kd> !wdfdevice 0x000031fe`d227df68 >>>>>>>>(FDO-1 Ude/cx client driver)
WDM PDEVICE_OBJECTs: self ffffce012dd87d10, attached ffffce012dd83de0, pdo ffffce012da75d10
Device is the power policy owner for the stack

Typically what you do is have the PDO wdfdevice as the context for the exposed interface functions, not the Fdo. Then the pdo can process the request and get the fdo as a part of that processing.
d

Bent from my phone


From: xxxxx@yahoo.com
Sent: Wednesday, May 16, 2018 6:09 PM
Subject: RE:[ntdev] Virtually enumerated NetAdapterCx client fails NetAdapterCreate() call
To: Windows System Software Devs Interest List

>> I would not hide the device (and you can still show hidden devices)<<
O.k.

I have related question on this. While creating the child PDOs, it has context, state in it, corresponding accessor WDF_DECLARE_CONTEXT_TYPE_WITH_NAME.
I exposed an driver-defined interface on PDO-1 (same one on PDO-2 as well), for corresponding child FDO-1 to communicate and could successfully call it.

But within interface func given wdfdevice(fdo-1), how do I get hold of say Wdfdevice(pdo-1) or even the wdfdevice(fdo-0)? I was not able to find any Wdf[Device/Fdo]Get[Parent/Pdo]…() funcs that do this?
I guess I could do this by providing that info as part of an accessor func in the interface itself and enforcing semantics on the rest of the interface funcs to send that back as a param etc. But wanted to see if I can do this in less number of steps.

My !wdfdevice dumps below - Basically from !wdfdevice(3) below, how do I get to !wdfdevice(2) or even Wdfdevice(1)
Also Wdfdevice(3) says no parent, should one of the two above it be a parent?

3: kd> !wdfdevice 0x000031fed2592f68 &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;(FDO-0 BUS driver)<br>WDM PDEVICE_OBJECTs: self ffffce012da66380, attached ffffce012da66040, pdo ffffce012a1d2800<br>Device is the power policy owner for the stack<br><br>3: kd&gt; !wdfdevice 0x000031fed258cb38 >>>>>>(PDO-1 HostController)
WDM PDEVICE_OBJECTs: self ffffce012da75d10
Device is NOT the power policy owner for the stack

Parent WDFDEVICE 000031fed2592f68

3: kd> !wdfdevice 0x000031fe`d227df68 >>>>>>>>(FDO-1 Ude/cx client driver)
WDM PDEVICE_OBJECTs: self ffffce012dd87d10, attached ffffce012dd83de0, pdo ffffce012da75d10
Device is the power policy owner for the stack


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:>

xxxxx@yahoo.com wrote:

>> I would not hide the device (and you can still show hidden devices)<<
But within interface func given wdfdevice(fdo-1), how do I get hold of say Wdfdevice(pdo-1) or even the wdfdevice(fdo-0)? I was not able to find any Wdf[Device/Fdo]Get[Parent/Pdo]…() funcs that do this?

Why would you need them?  Usually, the only way you’re going to
communicate between drivers like this is via IRPs.  The default I/O
target for FDO-1 is going to be the driver immediately below, so any
requests you send down will automatically trickle down.

Also, remember that KMDF objects are local to a driver.  If you have
three different drivers here, you can’t literally get the WDFDEVICE for
another driver.  The handle spaces are separate.  You can create an I/O
target for another driver, but that’s a driver-local target handle.


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

>>have the PDO wdfdevice as the context for the exposed interface functions
O.k. Anyways looks like i could have get to PDO context area through below
WdfDeviceWdmGetPhysicalDevice(FDO)->DeviceExtension
Above seems even shorter way to exchange interfaces (func ptrs) between FDO/PDO rather than a bit heavier driver-defined interfaces?

>Why would you need them?? Usually, the only way you’re going to communicate between drivers like this is via IRPs.?
Going through MSDN, ‘driver defined interfaces’ seemed best/low-effort for drivers in the same dev-stack, IO/Remote targets for drivers in different stack. They provide me native/direct func like interface compared to IO targets, ICOTLs/IRPS etc.

This interface is mostly for initial/final and occasional control calls. FDO-0 manages all the HW resources, these interface calls are just to pass/init/assign/manage the sub-device specific resources/life-time between individual sub-device FDO-x and FDO-0.

Also for now I have 3 drivers, but open to later just have the same driver for all 3 devobjs’ (i.e still 3 different INFs).