Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

Virtually enumerated NetAdapterCx client fails NetAdapterCreate() call

msrmsr Posts: 318
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 ffff9d00`587e68d8 fffff805`dd50d898 ndis!NdisWdfPnPAddDevice
01 ffff9d00`587e68e0 fffff805`dd503234 NetAdapterCx!NxDevice::AdapterAdd+0x98 [minio\ndis\cx\sys\nxdevice.cpp @ 144]
02 ffff9d00`587e6930 fffff805`dd50880c NetAdapterCx!NxAdapter::_Create+0x218 [minio\ndis\cx\sys\nxadapter.cpp @ 559]
03 ffff9d00`587e69d0 fffff805`dd4eb78c NetAdapterCx!imp_NetAdapterCreate+0x2fc [minio\ndis\cx\sys\nxadapterapi.cpp @ 240]
04 ffff9d00`587e6a30 fffff805`dd4eaf2a RtEthSample!NetAdapterCreate+0x5c [c:\program files (x86)\windows kits\10\include\10.0.17134.0\km\netadaptercx\1.2\netadapter.h @ 835]
05 ffff9d00`587e6a80 fffff805`d6b3e930 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 ffff9d00`587e7020 fffff805`d6b41c96 Wdf01000!FxDriver::AddDevice+0xac [minkernel\wdf\framework\shared\core\km\fxdriverkm.cpp @ 72]
08 ffff9d00`587e7440 fffff801`679f1a83 Wdf01000!FxDriver::AddDevice+0x26 [minkernel\wdf\framework\shared\core\km\fxdriverkm.cpp @ 51]
09 ffff9d00`587e7470 fffff801`67eab789 nt!PpvUtilCallAddDevice+0x3b
0a ffff9d00`587e74b0 fffff801`67e77687 nt!PnpCallAddDevice+0x59
0b ffff9d00`587e7540 fffff801`67e768c9 nt!PipCallDriverAddDevice+0x813
0c ffff9d00`587e76f0 fffff801`67efb7fd nt!PipProcessDevNodeTree+0x1f1
0d ffff9d00`587e7970 fffff801`679d4839 nt!PiProcessStartSystemDevices+0x59
0e ffff9d00`587e79c0 fffff801`678c6445 nt!PnpDeviceActionWorker+0x469
0f ffff9d00`587e7a80 fffff801`67981ae7 nt!ExpWorkerThread+0xf5
10 ffff9d00`587e7b10 fffff801`67a3fb86 nt!PspSystemThreadStartup+0x47
11 ffff9d00`587e7b60 00000000`00000000 nt!KiStartSystemThread+0x16

Comments

  • msrmsr Posts: 318
    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 ffff8202`83a8a1c0 fffff801`60228980 RtEthSample!RtInitializeHardware+0x4bd [c:\_projects\netadapter-cx-driver-samples-master\rtethsample\device.cpp @ 170]
    01 ffff8202`83a8a630 fffff801`5b2f4a08 RtEthSample!EvtDevicePrepareHardware+0x130 [c:\_projects\netadapter-cx-driver-samples-master\rtethsample\device.cpp @ 281]
    02 ffff8202`83a8a7a0 fffff801`5b3209c6 Wdf01000!FxPnpDevicePrepareHardware::InvokeClient+0x28 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 347]
    03 ffff8202`83a8a7f0 fffff801`5b2eaa37 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 ffff8202`83a8a830 fffff801`5b2e1efa Wdf01000!FxPkgPnp::PnpPrepareHardware+0xe7 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 3599]
    06 ffff8202`83a8a880 fffff801`5b2eac56 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 ffff8202`83a8a8c0 fffff801`5b2ee7e8 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x1a6 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1150]
    09 ffff8202`83a8a970 fffff801`5b2ee6ff 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 ffff8202`83a8a9b0 fffff801`fe45ef6c Wdf01000!FxWorkItemEventQueue::_WorkItemCallback+0x9f [minkernel\wdf\framework\shared\irphandlers\pnp\km\eventqueuekm.cpp @ 110]
    0c ffff8202`83a8aa10 fffff801`fe42b445 nt!IopProcessWorkItem+0x12c
    0d ffff8202`83a8aa80 fffff801`fe4e6ae7 nt!ExpWorkerThread+0xf5
    0e ffff8202`83a8ab10 fffff801`fe5a4b86 nt!PspSystemThreadStartup+0x47
    0f ffff8202`83a8ab60 00000000`00000000 nt!KiStartSystemThread+0x16
  • Tim_RobertsTim_Roberts Posts: 12,623
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • msrmsr Posts: 318
    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
  • msrmsr Posts: 318
    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
  • Tim_RobertsTim_Roberts Posts: 12,623
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Doron_HolanDoron_Holan Posts: 10,360
    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 <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 <xxxxx@lists.osr.com>
    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://docs.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-reserved-for-system-use&amp;data=02|01|[email protected]|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=3KfH57DP/4blUR/tCRPaO95ia5ezwAzBQW4BDf2IlA4=&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://docs.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors&amp;data=02|01|[email protected]|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=GEwbhPBlwYz3aAgJN5XWPS2+XosRIHKjYDq7au2YWhg=&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://www.osr.com/blog/2017/10/11/universal-infs-classinstall32-section/&amp;data=02|01|[email protected]|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=sQds+oN971XXor7oRSbj4u/6Ix+kHmpkmJ2W6OOL6Ec=&amp;reserved=0 ?

    Thanks


    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <https://na01.safelinks.protection.outlook.com/?url=http://www.osronline.com/showlists.cfm?list=ntdev&amp;data=02|01|[email protected]|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=ZWhiDmQyr5ByAqP0C8ChUYJeafBQyjCC3Dvzl/1xpdg=&amp;reserved=0&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <https://na01.safelinks.protection.outlook.com/?url=http://www.osr.com/seminars&amp;data=02|01|[email protected]|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=Do6P/fJknIIkAZ5IQD8cNdV0NqqszLrGaHqmsfJ11Iw=&amp;reserved=0&gt;

    To unsubscribe, visit the List Server section of OSR Online at <https://na01.safelinks.protection.outlook.com/?url=http://www.osronline.com/page.cfm?name=ListServer&amp;data=02|01|[email protected]|42d011197fdd41d94c1f08d5b9d384a6|72f988bf86f141af91ab2d7cd011db47|1|0|636619240469424996&amp;sdata=NjyIYpdifcMxHTq/p7Ip2uonR3z1dxYx+BYlKS/aDFA=&amp;reserved=0&gt;
  • msrmsr Posts: 318
    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
  • Doron_HolanDoron_Holan Posts: 10,360
    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:

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

    To unsubscribe, visit the List Server section of OSR Online at
  • msrmsr Posts: 318
    >> 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
  • Doron_HolanDoron_Holan Posts: 10,360
    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 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



    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

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

    To unsubscribe, visit the List Server section of OSR Online at
  • Tim_RobertsTim_Roberts Posts: 12,623
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • msrmsr Posts: 318
    >>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).
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!