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.
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.
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.
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.
> 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.
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/ ?
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.
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.
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
>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-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-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
>> 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 >>>>>>>>>(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> !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
>> 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).