My bus driver launched a virtual HID child device. In the bus driver, ChildPDO is correctly set to the created PDO and ChildPDO->NextDevice is correctly set to the Bus Driver’s FDO. However, in the HID Driver AddDevice callback function, the phdx->PhysicalDeviceObject and the phdx->NextDeviceObject both point to the Hid Driver’s PDO (Note: phdx = PHID_DEVICE_EXTENSION). Why doesn’t phdx->NextDeviceObject point to the Bus Driver’s FDO?
NextDeviceObject is a DO that’s directly under you. If there is no lower filters, NextDeviceObject and PhysicalDeviceObject are the same.
They relate to the stack (which ands at the PDO), not to the tree.
> NextDeviceObject is a DO that’s directly under you. If there is no lower filters,
NextDeviceObject and PhysicalDeviceObject are the same.
Actually, IIRC, NextDevice is a next DO created by the same driver. Furthermore, IIRC, this is undocumented field
(unlike AttachedDevice) so that it is not a very good idea to access it directly…
Anton Bassov
> Actually, IIRC, NextDevice is a next DO created by the same driver.
I don’t believe NextDevice points to a sibling; as you pointed out, AttachedDevice points there. BTW, phdx->PhysicalDeviceObject->NextDevice correctly points to the Bus Driver’s FDO but I believe that we are not supposed to use “NextDevice.”
IMHO, the WDK documentation is clear enough as to the meaning of NextDeviceObject. According to WDK documentation for “HID_DRIVER_EXTENSION” the NextDeviceObject is a “Pointer to the device object immediately below the functional device object in the HID device’s device stack.” One could read this as meaning the PDO but another definition in the WDK Doc (“Using the HID_DEVICE_EXTENSION Structure”) makes it more clear. “NextDeviceObject is a pointer to the top of the device stack beneath the FDO.” There is note at the bottom of this doc page, “When a HID minidriver sends an IRP down the device stack, it should use NextDeviceObject as the target device object.” This means to me that it should point to either the Lower Filter Driver or to the Bus Driver’s FDO. In other words, if it didn’t point to an FDO of the lower driver, how would one pass IRP’s down the stack? So, this begs the question, why does NextDeviceObject and PhysicalDeviceObject have the same value?
We’re not talking here about DEVICE_OBJECT::NextDevice.
Again, here NextDeviceObject is a device object that was obtained for you by calling IoAttachDeviceToDeviceStack, which is a DO immediately below your DO. Most of the time it’s a PDO, unless there is a lower filter.
It’s NEVER the same as the bus driver’s FDO. Normally, the bus driver’s FDO is the top of its stack. Its PDOs are bottoms of the child devices’ stacks.
You really ought not to be using any of these links. So, what are you
trying to do?
Mark Roddy
On Fri, Jan 7, 2011 at 11:22 AM, wrote:
>> Actually, IIRC, NextDevice is a next DO created by the same driver.
>
> I don’t believe NextDevice points to a sibling; as you pointed out, AttachedDevice points there. ?BTW, phdx->PhysicalDeviceObject->NextDevice correctly points to the Bus Driver’s FDO but I believe that we are not supposed to use “NextDevice.”
>
> IMHO, the WDK documentation is clear enough as to the meaning of NextDeviceObject. ?According to WDK documentation for “HID_DRIVER_EXTENSION” the NextDeviceObject is a “Pointer to the device object immediately below the functional device object in the HID device’s device stack.” ?One could read this as meaning the PDO but another definition in the WDK Doc (“Using the HID_DEVICE_EXTENSION Structure”) makes it more clear. ?“NextDeviceObject is a pointer to the top of the device stack beneath the FDO.” ?There is note at the bottom of this doc page, “When a HID minidriver sends an IRP down the device stack, it should use NextDeviceObject as the target device object.” ?This means to me that it should point to either the Lower Filter Driver or to the Bus Driver’s FDO. ?In other words, if it didn’t point to an FDO of the lower driver, how would one pass IRP’s down the stack? ?So, this begs the question, why does NextDeviceObject and PhysicalDeviceObject have the same value?
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
In my design, the WDF Bus Driver (based upon the Toaster example) is the only driver that knows how to extract data from the device. I would like to launch standard MS Class drivers for obtaining preprocessed data from the Bus Driver. I wanted to use standard MS drivers but, unfortunately, the Bus Driver is not receiving forwarded Irps from these drivers. So, I created a WDM HID driver only to find out why. Currently, the new HID Driver is attempting to forward the IOCTL_HID_READ_REPORT Irps to the Bus Driver using the “phdx->NextDeviceObject”. The Bus Driver is not seeing it. Similarly, the Bus Driver is not seeing requests for the Device Descriptors from any MS Class Drivers.
Ok, maybe I’m missing something here. Is the Child Driver’s FDO supposed to forward Irps to the Child Driver’s PDO, which in turn, is supposed to forward the Irp to the Bus Driver’s FDO? If so, the Bus Driver’s FDO is not seeing it and I’m trying to find out why. If I use “phdx->PhysicalDeviceObject->NextDevice”, I do see it. But, as mentioned above, we are not supposed to use NextDevice pointer and I don’t expect that standard MS Class drivers are going to use this mechanism anyway.
I can only assume that the drivers are not being launched correctly from the WDF Bus Driver. In the Bus Driver, the FDO->StackSize is 6 while in the Child Driver, the FDO->StackSize is 9. If I am counting correctly, there is 1 extra DeviceObject in the stack. The way I see it, there should be 1 for the ChildPDO and 1 for the ChildFDO. This should add up to 8, not 9. Where could the extra DeviceObject be coming from?
xxxxx@gmx.com wrote:
In my design, the WDF Bus Driver (based upon the Toaster example) is the only driver that knows how to extract data from the device. I would like to launch standard MS Class drivers for obtaining preprocessed data from the Bus Driver. I wanted to use standard MS drivers but, unfortunately, the Bus Driver is not receiving forwarded Irps from these drivers. So, I created a WDM HID driver only to find out why. Currently, the new HID Driver is attempting to forward the IOCTL_HID_READ_REPORT Irps to the Bus Driver using the “phdx->NextDeviceObject”. The Bus Driver is not seeing it.
When a WDM child driver calls IoAttachDeviceToDeviceStack, that call
returns the DO that the child driver needs to use for sending requests
down the stack. There is no promise that this DO is actually stored in
any standard structure. You need to store it in your context. KMDF
should handle this for you.
But, as mentioned above, we are not supposed to use NextDevice pointer and I don’t expect that standard MS Class drivers are going to use this mechanism anyway.
No, standard drivers will use the DO returned from
IoAttachDeviceToDeviceStack.
I can only assume that the drivers are not being launched correctly from the WDF Bus Driver. In the Bus Driver, the FDO->StackSize is 6 while in the Child Driver, the FDO->StackSize is 9. If I am counting correctly, there is 1 extra DeviceObject in the stack. The way I see it, there should be 1 for the ChildPDO and 1 for the ChildFDO. This should add up to 8, not 9. Where could the extra DeviceObject be coming from?
Are you running DriverVerifier or a software bus analyzer? Could you
possibly have filter drivers involved?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
You are forwarding requests to next device the driver supports not the
bus driver, so things are seriously broken. As far as the stack size
DeviceTree http://www.osronline.com/article.cfm?article=97 is your
friend.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmx.com” wrote in message
news:xxxxx@ntdev:
> In my design, the WDF Bus Driver (based upon the Toaster example) is the only driver that knows how to extract data from the device. I would like to launch standard MS Class drivers for obtaining preprocessed data from the Bus Driver. I wanted to use standard MS drivers but, unfortunately, the Bus Driver is not receiving forwarded Irps from these drivers. So, I created a WDM HID driver only to find out why. Currently, the new HID Driver is attempting to forward the IOCTL_HID_READ_REPORT Irps to the Bus Driver using the “phdx->NextDeviceObject”. The Bus Driver is not seeing it. Similarly, the Bus Driver is not seeing requests for the Device Descriptors from any MS Class Drivers.
>
> Ok, maybe I’m missing something here. Is the Child Driver’s FDO supposed to forward Irps to the Child Driver’s PDO, which in turn, is supposed to forward the Irp to the Bus Driver’s FDO? If so, the Bus Driver’s FDO is not seeing it and I’m trying to find out why. If I use “phdx->PhysicalDeviceObject->NextDevice”, I do see it. But, as mentioned above, we are not supposed to use NextDevice pointer and I don’t expect that standard MS Class drivers are going to use this mechanism anyway.
>
> I can only assume that the drivers are not being launched correctly from the WDF Bus Driver. In the Bus Driver, the FDO->StackSize is 6 while in the Child Driver, the FDO->StackSize is 9. If I am counting correctly, there is 1 extra DeviceObject in the stack. The way I see it, there should be 1 for the ChildPDO and 1 for the ChildFDO. This should add up to 8, not 9. Where could the extra DeviceObject be coming from?
There are Wdf interfaces for establishing the policy for bus pdos.
Either they process the request or they can forward the request for
processing to their parent FDO device. See for example
WdfRequestForwardToParentDeviceIoQueue.
As I said earlier, you really ought not to be using the device object
links for anything.
Mark Roddy
On Fri, Jan 7, 2011 at 1:50 PM, wrote:
> In my design, the WDF Bus Driver (based upon the Toaster example) is the only driver that knows how to extract data from the device. ?I would like to launch standard MS Class drivers for obtaining preprocessed data from the Bus Driver. ?I wanted to use standard MS drivers but, unfortunately, the Bus Driver is not receiving forwarded Irps from these drivers. ?So, I created a WDM HID driver only to find out why. ?Currently, the new HID Driver is attempting to forward the IOCTL_HID_READ_REPORT Irps to the Bus Driver using the “phdx->NextDeviceObject”. ?The Bus Driver is not seeing it. ?Similarly, the Bus Driver is not seeing requests for the Device Descriptors from any MS Class Drivers.
>
> Ok, maybe I’m missing something here. ?Is the Child Driver’s FDO supposed to forward Irps to the Child Driver’s PDO, which in turn, is supposed to forward the Irp to the Bus Driver’s FDO? ?If so, the Bus Driver’s FDO is not seeing it and I’m trying to find out why. ?If I use “phdx->PhysicalDeviceObject->NextDevice”, I do see it. ?But, as mentioned above, we are not supposed to use NextDevice pointer and I don’t expect that standard MS Class drivers are going to use this mechanism anyway.
>
> I can only assume that the drivers are not being launched correctly from the WDF Bus Driver. ?In the Bus Driver, the FDO->StackSize is 6 while in the Child Driver, the FDO->StackSize is 9. ?If I am counting correctly, there is 1 extra DeviceObject in the stack. ?The way I see it, there should be 1 for the ChildPDO and 1 for the ChildFDO. ?This should add up to 8, not 9. ?Where could the extra DeviceObject be coming from?
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
By itself, the IO requests are NOT forwarded from PDO to the FDO.
If your driver owns the PDOs, you need to make sure they know the FDO address and can forward the requests. If you don’t care about any upper filters over your FDO, you can use direct calls instead of duplicating the IRP and calling IoCallDriver. But by itself, the FDO is not getting the child device IRPs.
Tim,
When a WDM child driver calls IoAttachDeviceToDeviceStack,
that call returns the DO that the child driver needs to use for
sending requests down the stack.
Small point:
HID Drivers don’t call IoAttachDeviceToDeviceStack. They call
HidRegisterMinidriver. I believe you were referring to WDM
drivers in general where IoAttachDeviceToDeviceStack returns
the LowerDeviceObject.
Don,
You are forwarding requests to next device the
driver supports not the bus driver, so things are
seriously broken.
Could you elaborate? Don’t all the FDO’s and PDO’s
in the stack eventually point to the device but, in order
to get to the device, all requests are passed through
lower drivers including the Bus Driver? What I’m trying
to do is have the Bus Driver be the only driver that needs
to access the device for data. The Bus Driver, in my
design, will obtain and process the data when upper
stack drivers request it.
“xxxxx@gmx.com” wrote in message
news:xxxxx@ntdev:
> Don,
>
> > You are forwarding requests to next device the
> > driver supports not the bus driver, so things are
> > seriously broken.
>
> Could you elaborate? Don’t all the FDO’s and PDO’s
> in the stack eventually point to the device but, in order
> to get to the device, all requests are passed through
> lower drivers including the Bus Driver? What I’m trying
> to do is have the Bus Driver be the only driver that needs
> to access the device for data. The Bus Driver, in my
> design, will obtain and process the data when upper
> stack drivers request it.
No the NextDevice may not be in the same stack, if there is hardware at
the bottom it is likely you will point to the previous device that was
enumerated before the one you care about.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Aglets, this is a configuration issue in the PDOs you are enumerating. are you creating WDFQUEUEs to process the incoming io from the stacks created on top of this PDOs in the PDOs you create or the parent FDO? to forward IO sent down the PDO stack and process them in the FDO, you must do the following on each PDO
o call WdfPdoInitAllowForwardingRequestToParent
o create a parallel WDFQUEUE for the PDO
o in the io callback for the PDO, call WdfRequestForwardToParentDeviceIoQueue
BUT, you are confusing implementation with design here, ie confusing IO flow with IO processing logic. You don’t have to forward the requests from the PDO to the FDO to have a singular place to process them / store the data. The FDO’s device context is still where you keep all of your information and state, just that in the PDO’s io callback, access the FDO’s device context directly (call WdfPdoGetParent to get the FDO WDFDEVICE, then get the context)
d
> to forward IO sent down the PDO stack and process them in the FDO,
you must do the following on each PDO
o call WdfPdoInitAllowForwardingRequestToParent
o create a parallel WDFQUEUE for the PDO
o in the io callback for the PDO, call WdfRequestForwardToParentDeviceIoQueue
Doron,
Thanks for the reply. I’ve added a couple of Event Callback Functions (EvtIoDefault, EvtIoInternalDeviceControl, and EvtIoDeviceContol) in the Bus Driver for the Child PDOs but I haven’t seen any IRP_MJ_PNP or IRP_MJ_SYSTEM_CONTROL Irps passed down. Could you tell me which Event Callback Function will handle this?
Thanks
>seen any IRP_MJ_PNP or IRP_MJ_SYSTEM_CONTROL Irps passed down. Could you tell me
which Event Callback Function will handle this?
MJ_PNP is totally handled inside KMDF. The result of this handling is D0Entry/Exit, PrepareHardware and other calls.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim,
The Bus Driver is built with WDF (KMDF) while the Child Drivers are built using WDM.
The WDM Child Driver passes these IRPs down to it’s PDO. The status returned for all IRP_MJ_PNP requests is STATUS_NOT_SUPPORTED. It is my understanding that the WDF Bus Driver should be handling the Child Driver’s IRPs that it passes down to it’s PDO. Unfortunately, I am not seeing them. However, I do see the Irps that the Child Driver’s passed down to it’s PDO in my EvtIoDefault callback function such as IOCTL_INTERNAL_USB_SUBMIT_URB.
Are you saying that the Bus Driver should call the WdfDeviceInitSetPnpPowerEventCallbacks function for each of the Child Drivers it launches using the DeviceInit value associated with the new Child Device to be created?
I did this and I am now getting PNP callbacks such as Surprise Removal.
i have no idea why you think you need to register for preprocessing routines on WMI or PNP or Power irps. i don’t see a reason in your scenario where you need it. KMDF handles all of these IRPs properly for you. if you think you need to track pnp or power state this way, you are mistaken; kmdf will do it for you.
d
I’ve read that in the documentation but I don’t believe it yet. Most of the Child Driver’s forwarded IRP_MJ_PNP Irps get returned with STATUS_NOT_SUPPORTED. These Irps include IRP_MN_QUERY_DEVICE_RELATIONS, IRP_MN_QUERY_LEGACY_BUS_INFORMATION, and IRP_MN_FILTER_RESOURCE_REQUIREMENTS. If KMDF framework handles these Irps, why does the KMDF return STATUS_NOT_SUPPORTED to the Child Driver?