Hello,
we’ve developed an WDM device driver for an USB 2.0 highspeed device.
To allow our DLL / application communicate with this driver we use
self created device objects (additionally to the FDO created in add
device).
During WHQL testing these self created device objects are sent by
DevPathExer to e.g. our pnp IRP dispatching routine. Are there any
general principles how to handle this?
One idea (not yet tested …) is to complete the corresponding IRP
with error; what is the correct ntstatus error value in this case?
STATUS_UNSUCCESSFUL, STATUS_ACCESS_DENIED?
Any comments / hints are appreciated!
Kind regards
Olav
Why not use only 1 PnP FDO, but assign additional names to it?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Olav” wrote in message news:xxxxx@ntdev…
> Hello,
>
> we’ve developed an WDM device driver for an USB 2.0 highspeed device.
> To allow our DLL / application communicate with this driver we use
> self created device objects (additionally to the FDO created in add
> device).
> During WHQL testing these self created device objects are sent by
> DevPathExer to e.g. our pnp IRP dispatching routine. Are there any
> general principles how to handle this?
> One idea (not yet tested …) is to complete the corresponding IRP
> with error; what is the correct ntstatus error value in this case?
> STATUS_UNSUCCESSFUL, STATUS_ACCESS_DENIED?
>
> Any comments / hints are appreciated!
>
> Kind regards
> Olav
>
>
>
You complete the unsupported pnp irp with the status that it arrives with
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Olav
Sent: Tuesday, January 27, 2009 6:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WHQL error: how to handle self created device objects sent to pnp dispatch routine?
Hello,
we’ve developed an WDM device driver for an USB 2.0 highspeed device.
To allow our DLL / application communicate with this driver we use
self created device objects (additionally to the FDO created in add
device).
During WHQL testing these self created device objects are sent by
DevPathExer to e.g. our pnp IRP dispatching routine. Are there any
general principles how to handle this?
One idea (not yet tested …) is to complete the corresponding IRP
with error; what is the correct ntstatus error value in this case?
STATUS_UNSUCCESSFUL, STATUS_ACCESS_DENIED?
Any comments / hints are appreciated!
Kind regards
Olav
—
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
If you still decide to keep those dev objects for communication (which is not necessary), you’ll need to handle IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS/TargetRelations. In response, you’ll need to return your stack PDO reference. Your application will need to call RegisterDeviceNotification for your device handle. When the device is unplugged, the application will get a notification and then it should close the handle. That allows the driver to unload.
All other PNP IRPs should be completed without changing their status. Return whatever you find in there.
No, for a non pnp devobj you do not return a valid result for qdr/target device relations. Let’s say you have 2 pnp stacks, which pdo do you return? You cannot register for file handle notifications on a legacy devobj, answering the qdr may make this work, but that is not the intended scenario. It is more for non pnp storage drivers (like an fs) to fwd the target info on its handle down to the underlying pnp stack that supports it
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@broadcom.com
Sent: Tuesday, January 27, 2009 7:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WHQL error: how to handle self created device objects sent to pnp dispatch routine?
If you still decide to keep those dev objects for communication (which is not necessary), you’ll need to handle IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS/TargetRelations. In response, you’ll need to return your stack PDO reference. Your application will need to call RegisterDeviceNotification for your device handle. When the device is unplugged, the application will get a notification and then it should close the handle. That allows the driver to unload.
All other PNP IRPs should be completed without changing their status. Return whatever you find in there.
—
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
Doron, handling TargetRelations in a side device object is exactly what DDK documentation recommends for enabling clean unload. This IS an intended senario for non-PNP devobjects. Quote: “The TargetDeviceRelation query enables the PnP manager to query a non-PnP device stack for the PDO in the PnP device stack that controls the hardware.”
And 2 PNP stacks is a pathological case.
Perhaps it is pathological in the root enumerated case, but for any other bus it is far from pathological, it is most likely the norm. Again, i am a bit skeptical about the value of the control devobj. Yes there are legacy apps and other pathological cases, but for the most part you can make it work entirely within the pnp stack without the control devobj
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@broadcom.com
Sent: Tuesday, January 27, 2009 9:08 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WHQL error: how to handle self created device objects sent to pnp dispatch routine?
Doron, handling TargetRelations in a side device object is exactly what DDK documentation recommends for enabling clean unload. This IS an intended senario for non-PNP devobjects. Quote: “The TargetDeviceRelation query enables the PnP manager to query a non-PnP device stack for the PDO in the PnP device stack that controls the hardware.”
And 2 PNP stacks is a pathological case.
—
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