Hi All,
I have a dumb question. How are the target device objects for an IRP
determined? I was under the impression that after asking the Object Manager
to parse the name in IoCreateFile, the IO Manager would know the target
device object for the CREATE_IRP. Any further requests i.e.
read,write,cleanup,close etc. on this file object should then be sent to the
same device object. Isn’t this correct? Does the IO manager determine the
target device object on every IRP? How?
If I open a file using the OSR shadow device approach or by using
IoCreateFileSpecifyDeviceObjectHint, can’t I use Zw* calls on the handle
returned by such functions? Won’t all the IRP’s generated by Zw calls on
this handle go to the shadow device? The documents are confusing and the
comment on OSR sample code says you cannot use Zw* calls on such file
handles as they will be sent to the top of the stack. Why? Is this also true
for file handles retrieved through IoCreateFileSpecifyDeviceObjectHint?
Thanks in advance.
The I/O Manager re-evaluates the stack each time it builds an IRP. You
can do the same thing by calling IoGetRelatedDeviceObject. The basic
algorithm it follows is to either follow FileObject->Vpb->DeviceObject
or FileObject->DeviceObject (if there’s no Vpb). In either case, it
then walks up the “AttachedDevice” chain to find the “top” device of the
stack.
Other components may not perform this re-evaluation each time they
construct an IRP and that will lead to differences in behavior depending
upon the access path.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of faras namus
Sent: Thursday, February 16, 2006 11:30 AM
To: ntfsd redirect
Subject: [ntfsd] target device object, shadow device
IoCreateFileSpecifyDeviceObjectHint
Hi All,
I have a dumb question. How are the target device objects for an IRP
determined? I was under the impression that after asking the Object
Manager to parse the name in IoCreateFile, the IO Manager would know the
target device object for the CREATE_IRP. Any further requests i.e.
read,write,cleanup,close etc. on this file object should then be sent to
the same device object. Isn’t this correct? Does the IO manager
determine the target device object on every IRP? How?
If I open a file using the OSR shadow device approach or by using
IoCreateFileSpecifyDeviceObjectHint, can’t I use Zw* calls on the handle
returned by such functions? Won’t all the IRP’s generated by Zw calls on
this handle go to the shadow device? The documents are confusing and the
comment on OSR sample code says you cannot use Zw* calls on such file
handles as they will be sent to the top of the stack. Why? Is this also
true for file handles retrieved through
IoCreateFileSpecifyDeviceObjectHint?
Thanks in advance.
— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com
I think Tony post should have made behaviour with shadow device method
clear. The behaviour with IoCreateFileSpecifyDeviceObjectHint seems to be
well enough described in the IFS KIT and WDK documentation.
“faras namus” wrote in message news:xxxxx@ntfsd…
Hi All,
I have a dumb question. How are the target device objects for an IRP
determined? I was under the impression that after asking the Object Manager
to parse the name in IoCreateFile, the IO Manager would know the target
device object for the CREATE_IRP. Any further requests i.e.
read,write,cleanup,close etc. on this file object should then be sent to the
same device object. Isn’t this correct? Does the IO manager determine the
target device object on every IRP? How?
If I open a file using the OSR shadow device approach or by using
IoCreateFileSpecifyDeviceObjectHint, can’t I use Zw* calls on the handle
returned by such functions? Won’t all the IRP’s generated by Zw calls on
this handle go to the shadow device? The documents are confusing and the
comment on OSR sample code says you cannot use Zw* calls on such file
handles as they will be sent to the top of the stack. Why? Is this also true
for file handles retrieved through IoCreateFileSpecifyDeviceObjectHint?
Thanks in advance.
In general I agree. IoManager does IoGetRelatedFileObject which re-evaluates
the device stack, so if some filters attached to the filesystem in the
meanwhile, the request will go to the top of the IO stack.
Now I have a few questions regarding the OsrFilterForwardCreateIrp. The note
on top says that all Zw* calls on this handle will go to the top of the
device stack
instead of the device below you. Why is ZwClose a special case? In this
case also the IO Manager should do what it does for other IO requests.
I have another question. The shadow device object doesn’t have a VPB
associated with it. So if Io Manager sends the create to the shadow device
object which is then relayed to the lower device object, when is the VPB in
the file object populated? Is it when the filesytsem completes the CREATE?
In that case it would make sense that the file object now also has a VPB and
all further requests would go to the top of the stack.
Similarly, do all IO requests generated on a fileobject via
IoCreateFIleSpecifyDeviceObjectHint, go directly to the device object below
you? The IFS kit says create, cleanup and close. I am assume all other IO
requests also go to the device object below you. How? Does it change the VPB
to NULL and have the device object set to the one below you?
If someone could explain it in slight detail, that would really help.
Thanks
On 2/16/06, Tony Mason wrote:
>
> The I/O Manager re-evaluates the stack each time it builds an IRP. You
> can do the same thing by calling IoGetRelatedDeviceObject. The basic
> algorithm it follows is to either follow FileObject->Vpb->DeviceObject or
> FileObject->DeviceObject (if there’s no Vpb). In either case, it then walks
> up the “AttachedDevice” chain to find the “top” device of the stack.
>
>
>
> Other components may not perform this re-evaluation each time they
> construct an IRP and that will lead to differences in behavior depending
> upon the access path.
>
>
>
> Regards,
>
>
>
> Tony
>
>
>
> Tony Mason
>
> Consulting Partner
>
> OSR Open Systems Resources, Inc.
>
> http://www.osr.com
>
>
>
> Looking forward to seeing you at the next OSR File Systems class in Boston,
> MA April 18-21, 2006 (note new date - MS scheduled plugfest the same week
> again.)
> ------------------------------
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of faras namus
> Sent: Thursday, February 16, 2006 11:30 AM
> To: ntfsd redirect
> Subject: [ntfsd] target device object, shadow device
> IoCreateFileSpecifyDeviceObjectHint
>
>
>
> Hi All,
>
>
> I have a dumb question. How are the target device objects for an IRP
> determined? I was under the impression that after asking the Object Manager
> to parse the name in IoCreateFile, the IO Manager would know the target
> device object for the CREATE_IRP. Any further requests i.e.
> read,write,cleanup,close etc. on this file object should then be sent to the
> same device object. Isn’t this correct? Does the IO manager determine the
> target device object on every IRP? How?
>
>
>
> If I open a file using the OSR shadow device approach or by using
> IoCreateFileSpecifyDeviceObjectHint, can’t I use Zw calls on the handle
> returned by such functions? Won’t all the IRP’s generated by Zw calls on
> this handle go to the shadow device? The documents are confusing and the
> comment on OSR sample code says you cannot use Zw calls on such file
> handles as they will be sent to the top of the stack. Why? Is this also true
> for file handles retrieved through IoCreateFileSpecifyDeviceObjectHint?
>
>
>
> Thanks in advance.
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently subscribed
> to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank
> email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
>
> To unsubscribe send a blank email to xxxxx@lists.osr.com
I digged on this further. It seems the fileobjects created using
IoCreateFileSpecifyDeviceObjectHint() have the flag
FO_FILE_OBJECT_HAS_EXTENSION set. This causes IoGetRelatedDeviceObject() to
behave differently (look into the extension area) and return the device
object of the device below you. This would mean all IRP’s generated via
Zw* calls on such a fileobject will go to the device below you.
So I have only one pending question. Why does the OSR sample code say that
all IRP’s generated via Zw* close will go to the top of the device except
for ZwClose. I would assume that ZwClose on a fileobject retrieved via the
shadow device technique will also go to the top of the stack.
The other summary is that when the fileobject is sent to the shadow device
its VPB is NULL and when it is redirected to the device below you and
finally completed by the filesystem, the VPB is populated. All further
requests via Zw* call IoGetRelatedDeviceObject() which returns the topmost
device on the filesystem stack.
Thanks
On 2/17/06, faras namus wrote:
>
> In general I agree. IoManager does IoGetRelatedFileObject which
> re-evaluates the device stack, so if some filters attached to the filesystem
> in the meanwhile, the request will go to the top of the IO stack.
>
> Now I have a few questions regarding the OsrFilterForwardCreateIrp. The
> note on top says that all Zw* calls on this handle will go to the top of the
> device stack
> instead of the device below you. Why is ZwClose a special case? In this
> case also the IO Manager should do what it does for other IO requests.
>
> I have another question. The shadow device object doesn’t have a VPB
> associated with it. So if Io Manager sends the create to the shadow device
> object which is then relayed to the lower device object, when is the VPB in
> the file object populated? Is it when the filesytsem completes the CREATE?
> In that case it would make sense that the file object now also has a VPB and
> all further requests would go to the top of the stack.
>
>
> Similarly, do all IO requests generated on a fileobject via
> IoCreateFIleSpecifyDeviceObjectHint, go directly to the device object below
> you? The IFS kit says create, cleanup and close. I am assume all other IO
> requests also go to the device object below you. How? Does it change the VPB
> to NULL and have the device object set to the one below you?
>
> If someone could explain it in slight detail, that would really help.
>
> Thanks
>
> On 2/16/06, Tony Mason wrote:
> >
> > The I/O Manager re-evaluates the stack each time it builds an IRP. You
> > can do the same thing by calling IoGetRelatedDeviceObject. The basic
> > algorithm it follows is to either follow FileObject->Vpb->DeviceObject or
> > FileObject->DeviceObject (if there’s no Vpb). In either case, it then walks
> > up the “AttachedDevice” chain to find the “top” device of the stack.
> >
> >
> >
> > Other components may not perform this re-evaluation each time they
> > construct an IRP and that will lead to differences in behavior depending
> > upon the access path.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Tony
> >
> >
> >
> > Tony Mason
> >
> > Consulting Partner
> >
> > OSR Open Systems Resources, Inc.
> >
> > http://www.osr.com
> >
> >
> >
> > Looking forward to seeing you at the next OSR File Systems class in
> > Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
> > same week again.)
> > ------------------------------
> >
> > From: xxxxx@lists.osr.com [mailto:
> > xxxxx@lists.osr.com] On Behalf Of faras namus
> > Sent: Thursday, February 16, 2006 11:30 AM
> > To: ntfsd redirect
> > Subject: [ntfsd] target device object, shadow device
> > IoCreateFileSpecifyDeviceObjectHint
> >
> >
> >
> > Hi All,
> >
> >
> > I have a dumb question. How are the target device objects for an IRP
> > determined? I was under the impression that after asking the Object Manager
> > to parse the name in IoCreateFile, the IO Manager would know the target
> > device object for the CREATE_IRP. Any further requests i.e.
> > read,write,cleanup,close etc. on this file object should then be sent to the
> > same device object. Isn’t this correct? Does the IO manager determine the
> > target device object on every IRP? How?
> >
> >
> >
> > If I open a file using the OSR shadow device approach or by using
> > IoCreateFileSpecifyDeviceObjectHint, can’t I use Zw calls on the handle
> > returned by such functions? Won’t all the IRP’s generated by Zw calls on
> > this handle go to the shadow device? The documents are confusing and the
> > comment on OSR sample code says you cannot use Zw calls on such file
> > handles as they will be sent to the top of the stack. Why? Is this also true
> > for file handles retrieved through IoCreateFileSpecifyDeviceObjectHint?
> >
> >
> >
> > Thanks in advance.
> >
> > — Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17 You are currently subscribed
> > to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank
> > email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
The DDK states:
“File system filter drivers call *IoCreateFileSpecifyDeviceObjectHint*
to send a *create* request only to a specified device object, the
filters attached below it, and the file system. Filters attached above
the specified device object in the driver stack do not receive the
*create* request. The same is true for any *cleanup* or *close* requests
on the file object that is created by
*IoCreateFileSpecifyDeviceObjectHint*.”
Where in the documentation are you seeing that it sends Reads and Writes
and other IRPs directly below? OSR’s sample says Creates, Cleanups, and
Closes are sent down and not to the top of the stack. The DDK states the
same.
This is my take on it, however, I’m no expert. Just my interpretation of
what I see in the ddk…
Matt
faras namus wrote:
I digged on this further. It seems the fileobjects created using
IoCreateFileSpecifyDeviceObjectHint() have the flag
FO_FILE_OBJECT_HAS_EXTENSION set. This causes
IoGetRelatedDeviceObject() to behave differently (look into the
extension area) and return the device object of the device below you.
This would mean all IRP’s generated via Zw* calls on such a fileobject
will go to the device below you.
So I have only one pending question. Why does the OSR sample code say
that all IRP’s generated via Zw* close will go to the top of the
device except for ZwClose. I would assume that ZwClose on a fileobject
retrieved via the shadow device technique will also go to the top of
the stack.
The other summary is that when the fileobject is sent to the shadow
device its VPB is NULL and when it is redirected to the device below
you and finally completed by the filesystem, the VPB is populated. All
further requests via Zw* call IoGetRelatedDeviceObject() which returns
the topmost device on the filesystem stack.
Thanks
On 2/17/06, *faras namus* > mailto:xxxxx> wrote:
>
> In general I agree. IoManager does IoGetRelatedFileObject which
> re-evaluates the device stack, so if some filters attached to the
> filesystem in the meanwhile, the request will go to the top of the
> IO stack.
>
> Now I have a few questions regarding the
> OsrFilterForwardCreateIrp. The note on top says that all Zw* calls
> on this handle will go to the top of the device stack
> instead of the device below you. Why is ZwClose a special case?
> In this case also the IO Manager should do what it does for other
> IO requests.
>
> I have another question. The shadow device object doesn’t have a
> VPB associated with it. So if Io Manager sends the create to the
> shadow device object which is then relayed to the lower device
> object, when is the VPB in the file object populated? Is it when
> the filesytsem completes the CREATE? In that case it would make
> sense that the file object now also has a VPB and all further
> requests would go to the top of the stack.
>
>
> Similarly, do all IO requests generated on a fileobject via
> IoCreateFIleSpecifyDeviceObjectHint, go directly to the device
> object below you? The IFS kit says create, cleanup and close. I
> am assume all other IO requests also go to the device object below
> you. How? Does it change the VPB to NULL and have the device
> object set to the one below you?
>
> If someone could explain it in slight detail, that would really help.
>
> Thanks
>
> On 2/16/06, Tony Mason >
> wrote:
>
> The I/O Manager re-evaluates the stack each time it builds an
> IRP. You can do the same thing by calling
> IoGetRelatedDeviceObject. The basic algorithm it follows is
> to either follow FileObject->Vpb->DeviceObject or
> FileObject->DeviceObject (if there’s no Vpb). In either case,
> it then walks up the “AttachedDevice” chain to find the “top”
> device of the stack.
>
>
>
> Other components may not perform this re-evaluation each time
> they construct an IRP and that will lead to differences in
> behavior depending upon the access path.
>
>
>
> Regards,
>
>
>
> Tony
>
>
>
> Tony Mason
>
> Consulting Partner
>
> OSR Open Systems Resources, Inc.
>
> http://www.osr.com http:</http:>
>
>
>
> Looking forward to seeing you at the next OSR File Systems
> class in Boston, MA April 18-21, 2006 (note new date - MS
> scheduled plugfest the same week again.)
>
> ------------------------------------------------------------------------
>
> From: xxxxx@lists.osr.com
> mailto:xxxxx
> [mailto:xxxxx@lists.osr.com
> mailto:xxxxx] On Behalf Of faras namus
> Sent: Thursday, February 16, 2006 11:30 AM
> To: ntfsd redirect
> Subject: [ntfsd] target device object, shadow device
> IoCreateFileSpecifyDeviceObjectHint
>
>
>
> Hi All,
>
>
> I have a dumb question. How are the target device objects for
> an IRP determined? I was under the impression that after
> asking the Object Manager to parse the name in IoCreateFile,
> the IO Manager would know the target device object for the
> CREATE_IRP. Any further requests i.e. read,write,cleanup,close
> etc. on this file object should then be sent to the same
> device object. Isn’t this correct? Does the IO manager
> determine the target device object on every IRP? How?
>
>
>
> If I open a file using the OSR shadow device approach or by
> using IoCreateFileSpecifyDeviceObjectHint, can’t I use Zw
> calls on the handle returned by such functions? Won’t all the
> IRP’s generated by Zw calls on this handle go to the shadow
> device? The documents are confusing and the comment on OSR
> sample code says you cannot use Zw calls on such file handles
> as they will be sent to the top of the stack. Why? Is this
> also true for file handles retrieved through
> IoCreateFileSpecifyDeviceObjectHint?
>
>
>
> Thanks in advance.
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently
> subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To
> unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
>
>
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently
> subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To
> unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
On 2/17/06, MM wrote:
> The DDK states:
>
> “File system filter drivers call IoCreateFileSpecifyDeviceObjectHint
> to send a create request only to a specified device object, the
> filters attached below it, and the file system. Filters attached above
> the specified device object in the driver stack do not receive the
> create request. The same is true for any cleanup or close requests
> on the file object that is created by
> IoCreateFileSpecifyDeviceObjectHint.”
>
> Where in the documentation are you seeing that it sends Reads and Writes
> and other IRPs directly below?
It is not in the documentation but that is what is happening in
practise. IRP’s generated via Zw* calls on a fileobject created via
IoCreateFileSpecifyDeviceObjectHint will always be sent to the device
below you. I don’t know why DDK makes a special mention of create,
close and cleanup.
> OSR’s sample says Creates, Cleanups, and
> Closes are sent down and not to the top of the stack. The DDK states the
> same.
This is the comment from OSR sample code on the internet.
>>>
Note: Be aware that you can not use any Zw routines (except for
ZwClose) utilizing the handle returned from this routine. Because if
you do, the call will go
back to the top of the device stack.
Therefore you must call ObReferenceObjectByHandle to get the associated File
Object and then build your own IRPs for subsequent requests that you want to
make regarding this file.
>>>
This seems to imply that the IRP’s generated via ZwClose
(IRP_MJ_CLEANUP and potentially IRP_MJ_CLOSE) will not be sent to the
top of the device stack, unlike others. This is incorrect for
fileobjects retrieved via the shadow device approach.
Thanks
“IRP’s generated via Zw* calls on a fileobject created via
IoCreateFileSpecifyDeviceObjectHint will always be sent to the device
below you.”
And you expect them to be sent where?
faras namus wrote:
On 2/17/06, MM wrote:
>
>
>>The DDK states:
>>
>>“File system filter drivers call IoCreateFileSpecifyDeviceObjectHint
>>to send a create request only to a specified device object, the
>>filters attached below it, and the file system. Filters attached above
>>the specified device object in the driver stack do not receive the
>>create request. The same is true for any cleanup or close requests
>>on the file object that is created by
>>IoCreateFileSpecifyDeviceObjectHint.”
>>
>>Where in the documentation are you seeing that it sends Reads and Writes
>>and other IRPs directly below?
>>
>>
>
>It is not in the documentation but that is what is happening in
>practise. IRP’s generated via Zw* calls on a fileobject created via
>IoCreateFileSpecifyDeviceObjectHint will always be sent to the device
>below you. I don’t know why DDK makes a special mention of create,
>close and cleanup.
>
>
>
>>OSR’s sample says Creates, Cleanups, and
>>Closes are sent down and not to the top of the stack. The DDK states the
>>same.
>>
>>
>
>This is the comment from OSR sample code on the internet.
>
>
>
>Note: Be aware that you can not use any Zw routines (except for
>ZwClose) utilizing the handle returned from this routine. Because if
>you do, the call will go
>back to the top of the device stack.
>
>Therefore you must call ObReferenceObjectByHandle to get the associated File
>Object and then build your own IRPs for subsequent requests that you want to
>make regarding this file.
>
>
>
>This seems to imply that the IRP’s generated via ZwClose
>(IRP_MJ_CLEANUP and potentially IRP_MJ_CLOSE) will not be sent to the
>top of the device stack, unlike others. This is incorrect for
>fileobjects retrieved via the shadow device approach.
>
>Thanks
>
>
>—
>Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
Have you understood what I am asking? If not, please let the other
knowledgable people answer.
On 2/17/06, MM wrote:
> “IRP’s generated via Zw* calls on a fileobject created via
> IoCreateFileSpecifyDeviceObjectHint will always be sent to the device
> below you.”
>
> And you expect them to be sent where?
>
>
>
> faras namus wrote:
>
> >On 2/17/06, MM wrote:
> >
> >
> >>The DDK states:
> >>
> >>“File system filter drivers call IoCreateFileSpecifyDeviceObjectHint
> >>to send a create request only to a specified device object, the
> >>filters attached below it, and the file system. Filters attached above
> >>the specified device object in the driver stack do not receive the
> >>create request. The same is true for any cleanup or close requests
> >>on the file object that is created by
> >>IoCreateFileSpecifyDeviceObjectHint.”
> >>
> >>Where in the documentation are you seeing that it sends Reads and Writes
> >>and other IRPs directly below?
> >>
> >>
> >
> >It is not in the documentation but that is what is happening in
> >practise. IRP’s generated via Zw* calls on a fileobject created via
> >IoCreateFileSpecifyDeviceObjectHint will always be sent to the device
> >below you. I don’t know why DDK makes a special mention of create,
> >close and cleanup.
> >
> >
> >
> >>OSR’s sample says Creates, Cleanups, and
> >>Closes are sent down and not to the top of the stack. The DDK states the
> >>same.
> >>
> >>
> >
> >This is the comment from OSR sample code on the internet.
> >
> >
> >
> >Note: Be aware that you can not use any Zw routines (except for
> >ZwClose) utilizing the handle returned from this routine. Because if
> >you do, the call will go
> >back to the top of the device stack.
> >
> >Therefore you must call ObReferenceObjectByHandle to get the associated File
> >Object and then build your own IRPs for subsequent requests that you want to
> >make regarding this file.
> >
> >
> >
> >This seems to imply that the IRP’s generated via ZwClose
> >(IRP_MJ_CLEANUP and potentially IRP_MJ_CLOSE) will not be sent to the
> >top of the device stack, unlike others. This is incorrect for
> >fileobjects retrieved via the shadow device approach.
> >
> >Thanks
> >
> >
> >—
> >Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
> >
> >You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>same device object. Isn’t this correct? Does the IO manager determine the
target device object on every IRP? How?
IoGetRelatedDeviceObject is used for this. It returns the top of attachment
stack, and also does the VPB traversing for FS volumes.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com