So indirectly you have educated me to the fact that the start is not
complete at the time that self-managed I/O is initialized and had I should
have realized that since if I fail EvtSelfManagedIoInit() the devnode does
not ?start?. Duh.
(b) is an effective solution. Thanks.
Some follow-up questions if I may:
My original intention was to use IoCreateFileSpecifyDeviceObjectHint() with
the ?hint? being the next lower DO because really I don?t want or need to
have the create pass down the entire stack but just to the stack beneath my
FiDO.
At the time EvtSelfManagedIoInit() is called, has the ?lower? stack
effectively started?
If so, can I use IoCreateFileSpecify?.() and then take the result of that
operation and ?open? an IoTarget using
WDF_IO_TARGET_OPEN_PARAMS_INIT_EXISTING_DEVICE()?
Thanks,
-dave
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, May 11, 2009 2:04 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF: Opening own stack as remote I/O target in
EvtSelfManagedIoInit
A stack cannot have handles created against it until the entire stack has
successfully completed the start irp. Think about it if it were not this
way. Let?s say the fdo enables a device interface and someone is notified
and sends a create down the stack. While this is happening the filter above
the fdo has not yet even processed the start irp and will now receive a
create and file based io in an uninitialized state. you basically have to
either
a) Queue a work item, but that is not race free
b) Register for device interface notifications on your stack?s
devinterface (or your own). When you get notified, open the stack and query
the handle?s PDO. If it is your PDO, you are golden
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Sunday, May 10, 2009 7:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF: Opening own stack as remote I/O target in
EvtSelfManagedIoInit
Perhaps this is a bad idea and/or I have just gone about it incorrectly
and/or I can?t see the forest through the trees…
I desire to open a remote I/O target on my own device stack from a filter
driver so that my filter driver can in effect have a FILE_OBJECT created on
its own stack. I endeavored to accomplish this by creating a WDFIOTARGET
and calling WdfIoTargetOpen() during EvtSelfManagedIoInit() in my filter
driver. I retrieved the name of the PDO for use as the TargetDeviceName
in the WDF_IO_TARGET_OPEN_PARAMS_INIT_CREATE_BY_NAME() and setup the
remaining WDF_IO_TARGET_OPEN_PARAMS in (what I believe to be) a reasonable
way.
However, WdfIoTargetOpen() returns 0xC000000e or STATUS_NO_SUCH_DEVICE.
So I am a bit stumped. The device (stack) clearly exists. The PDO name is
\Device\00000038
!object \Device\00000038 shows a perfectly lovely entry pointing at the PDO
of my devstack.
!devobj shows a perfectly lovely PDO in DOE_START_PENDING
!devstack shows my devstack just fine with my FiDO sitting atop my
FDO sitting on a root enumerated PDO.
So why the ObjMgr kicks back a STATUS_NO_SUCH_DEVICE I cannot see.
Any ideas would be much appreciated.
TIA,
-Dave
—
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
—
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