SRV2 flavored IRP's

NTFSD
1

I have a full FSD (not filter driver) which works well and passes multiple test suites when used directly as a disk or network file system. I am now testing file sharing scenarios and I am experiencing issues with IRP’s sent by (or related to) SRV2.

The most important issue I have seen is that normal IRP completion processing (done in IopCompleteRequest) seems to be circumvented: for example, if one sets up a SystemBuffer with the proper IRP flags (IRP_BUFFERED_IO | IRP_INPUT_OPERATION | IRP_DEALLOCATE_BUFFER), the SystemBuffer will not be copied into the UserBuffer and freed as expected. [I have traced into srv2!SrvPostOnCompletionAndClearCancel and have confirmed that it eventually returns STATUS_MORE_PROCESSING_REQUIRED thus circumventing normal IRP completion.]

While I have fixed some of these issues in my FSD, they have undermined my confidence that I correctly understand how FSD’s are supposed to handle SRV2 flavored IRP’s. Are there any other gotchas with such IRP’s? Is there any foolproof way to identify these IRP’s as coming from SRV2?

A pointer to authoritative information would be fantastic, but anecdotal information will do as well.

Thank you.

2

Any existing FSD knows nothing about SRV2 or something like that. Make sure
you process IRP correctly, like pending flag propagating and so on.

28 окт. 2016 г. 10:49 AM пользователь
написал:

I have a full FSD (not filter driver) which works well and passes multiple
test suites when used directly as a disk or network file system. I am now
testing file sharing scenarios and I am experiencing issues with IRP’s sent
by (or related to) SRV2.

The most important issue I have seen is that normal IRP completion
processing (done in IopCompleteRequest) seems to be circumvented: for
example, if one sets up a SystemBuffer with the proper IRP flags
(IRP_BUFFERED_IO | IRP_INPUT_OPERATION | IRP_DEALLOCATE_BUFFER), the
SystemBuffer will not be copied into the UserBuffer and freed as expected.
[I have traced into srv2!SrvPostOnCompletionAndClearCancel and have<br>confirmed that it eventually returns STATUS_MORE_PROCESSING_REQUIRED thus<br>circumventing normal IRP completion.]

While I have fixed some of these issues in my FSD, they have undermined my
confidence that I correctly understand how FSD’s are supposed to handle
SRV2 flavored IRP’s. Are there any other gotchas with such IRP’s? Is there
any foolproof way to identify these IRP’s as coming from SRV2?

A pointer to authoritative information would be fantastic, but anecdotal
information will do as well.

Thank you.

—
NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at <
http://www.osronline.com/page.cfm?name=ListServer&gt;</http:>

3

What behavior are you experiencing that led you down the path of looking at
the I/O completion processing?

Are you handling IRP_MJ_READ/WRITE IRP_MN_MDL requests?

-scott
OSR
@OSRDrivers

“Anatoly Mikhailov” wrote in message
news:xxxxx@ntfsd…

Any existing FSD knows nothing about SRV2 or something like that. Make sure
you process IRP correctly, like pending flag propagating and so on.

28 окт. 2016 г. 10:49 AM пользователь
написал:
I have a full FSD (not filter driver) which works well and passes multiple
test suites when used directly as a disk or network file system. I am now
testing file sharing scenarios and I am experiencing issues with IRP’s sent
by (or related to) SRV2.

The most important issue I have seen is that normal IRP completion
processing (done in IopCompleteRequest) seems to be circumvented: for
example, if one sets up a SystemBuffer with the proper IRP flags
(IRP_BUFFERED_IO | IRP_INPUT_OPERATION | IRP_DEALLOCATE_BUFFER), the
SystemBuffer will not be copied into the UserBuffer and freed as expected.
[I have traced into srv2!SrvPostOnCompletionAndClearCancel and have <br>confirmed that it eventually returns STATUS_MORE_PROCESSING_REQUIRED thus <br>circumventing normal IRP completion.]

While I have fixed some of these issues in my FSD, they have undermined my
confidence that I correctly understand how FSD’s are supposed to handle SRV2
flavored IRP’s. Are there any other gotchas with such IRP’s? Is there any
foolproof way to identify these IRP’s as coming from SRV2?

A pointer to authoritative information would be fantastic, but anecdotal
information will do as well.

Thank you.

—
NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:>

4

In my practice I have never saw MDL read/write was used by network agents
despite of this interface was introduced specially for them. But the
question is a good one.

28 окт. 2016 г. 4:49 PM пользователь “Scott Noone” написал:

> What behavior are you experiencing that led you down the path of looking
> at the I/O completion processing?
>
> Are you handling IRP_MJ_READ/WRITE IRP_MN_MDL requests?
>
> -scott
> OSR
> @OSRDrivers
>
> “Anatoly Mikhailov” wrote in message
> news:xxxxx@ntfsd…
>
> Any existing FSD knows nothing about SRV2 or something like that. Make
> sure you process IRP correctly, like pending flag propagating and so on.
>
>
> 28 окт. 2016 г. 10:49 AM пользователь
> написал:
> I have a full FSD (not filter driver) which works well and passes multiple
> test suites when used directly as a disk or network file system. I am now
> testing file sharing scenarios and I am experiencing issues with IRP’s sent
> by (or related to) SRV2.
>
> The most important issue I have seen is that normal IRP completion
> processing (done in IopCompleteRequest) seems to be circumvented: for
> example, if one sets up a SystemBuffer with the proper IRP flags
> (IRP_BUFFERED_IO | IRP_INPUT_OPERATION | IRP_DEALLOCATE_BUFFER), the
> SystemBuffer will not be copied into the UserBuffer and freed as expected.
> [I have traced into srv2!SrvPostOnCompletionAndClearCancel and have<br>&gt; confirmed that it eventually returns STATUS_MORE_PROCESSING_REQUIRED thus<br>&gt; circumventing normal IRP completion.]
>
> While I have fixed some of these issues in my FSD, they have undermined my
> confidence that I correctly understand how FSD’s are supposed to handle
> SRV2 flavored IRP’s. Are there any other gotchas with such IRP’s? Is there
> any foolproof way to identify these IRP’s as coming from SRV2?
>
> A pointer to authoritative information would be fantastic, but anecdotal
> information will do as well.
>
> Thank you.
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

5

Scott Noone wrote:

What behavior are you experiencing that led you down the path of looking at
the I/O completion processing?
Are you handling IRP_MJ_READ/WRITE IRP_MN_MDL requests?

Yes, I am handling IRP_MN_MDL requests. The specific issue that I described above was with IRP_MN_QUERY_DIRECTORY.

My QueryDirectory tests would work fine when using the file system directly, but would fail mysteriously when running under SRV2. Running them under WinDbg I would see that my FSD would return STATUS_SUCCESS, but my tests would still fail. Running them under FileSpy, showed that while my FSD would return STATUS_SUCCESS, SRV2 would convert that response to STATUS_INVALID_NETWORK_RESPONSE.

After double and triple checking that my response buffer was correctly formed and that the Irp->IoStatus.Information was properly set to the response length, I started suspecting other issues. Then I noticed that SRV2 QueryDirectory IRP’s are “different”, they always seem to have a non-NULL Irp->MdlAddress and they always seem to have a completion routine of SrvPostOnCompletionAndClearCancel.

Now for reasons that I will not go into here, my QueryDirectory handler (sometimes) uses the SystemBuffer and sets the IRP up with IRP_BUFFERED_IO | IRP_INPUT_OPERATION | IRP_DEALLOCATE_BUFFER, because it expects normal IRP completion processing to happen. It turns out that SRV2 circumvents normal IRP completion processing by returning STATUS_MORE_PROCESSING_REQUIRED. Thus my nicely formed response in the SystemBuffer was never copied back into the UserBuffer and the SystemBuffer was never freed. Upon IRP completion SRV2 saw garbage in the UserBuffer and responded with STATUS_INVALID_NETWORK_RESPONSE.

A similar issue with the same symptoms was reported to this list a few years ago without resolution: http://www.osronline.com/ShowThread.cfm?link=180361

[ASIDE:

FastFat does not get into this trap for QueryDirectory, because it uses the Irp->MdlAddress when it needs to postpone IRP handling (because it cannot acquire locks, etc.) This works in the SRV2 case, because SRV2 has “helpfully” set the Irp->MdlAddress for it.

I expect that I will hear people saying: “just do what FastFat does”. That is not always possible; my FSD is not FastFat and has very different functionality (the primary difference regarding IRP handling is that I have to potentially pend pretty much every IRP that I receive).
]

While I have fixed this particular issue, I am looking to better understand SRV2 “flavored” IRP’s and how to correctly identify and handle them. I often have to do the SystemBuffer trick, because I often have to pend IRP’s. For example, I also do it in IRP_MJ_QUERY_SECURITY (although my tests pass there – I intend to investigate nevertheless).

Thank you for your attention.

Bill

6

Anatoly, I have seen IRP_MN_MDL READ IRPs, but not as IRP_MN_MDL WRITE IRPs as of yet. In fact I am looking for ways to trigger them to have this path of my FSD tested.

Bill

7

Why your handler uses SystemBuffer? Your volume device object has
DO_BUFFERED_IO flag set?

28 окт. 2016 г. 8:13 PM пользователь
написал:

> Scott Noone wrote:
> > What behavior are you experiencing that led you down the path of looking
> at
> > the I/O completion processing?
> > Are you handling IRP_MJ_READ/WRITE IRP_MN_MDL requests?
>
> Yes, I am handling IRP_MN_MDL requests. The specific issue that I
> described above was with IRP_MN_QUERY_DIRECTORY.
>
> My QueryDirectory tests would work fine when using the file system
> directly, but would fail mysteriously when running under SRV2. Running them
> under WinDbg I would see that my FSD would return STATUS_SUCCESS, but my
> tests would still fail. Running them under FileSpy, showed that while my
> FSD would return STATUS_SUCCESS, SRV2 would convert that response to
> STATUS_INVALID_NETWORK_RESPONSE.
>
> After double and triple checking that my response buffer was correctly
> formed and that the Irp->IoStatus.Information was properly set to the
> response length, I started suspecting other issues. Then I noticed that
> SRV2 QueryDirectory IRP’s are “different”, they always seem to have a
> non-NULL Irp->MdlAddress and they always seem to have a completion routine
> of SrvPostOnCompletionAndClearCancel.
>
> Now for reasons that I will not go into here, my QueryDirectory handler
> (sometimes) uses the SystemBuffer and sets the IRP up with IRP_BUFFERED_IO
> | IRP_INPUT_OPERATION | IRP_DEALLOCATE_BUFFER, because it expects normal
> IRP completion processing to happen. It turns out that SRV2 circumvents
> normal IRP completion processing by returning STATUS_MORE_PROCESSING_REQUIRED.
> Thus my nicely formed response in the SystemBuffer was never copied back
> into the UserBuffer and the SystemBuffer was never freed. Upon IRP
> completion SRV2 saw garbage in the UserBuffer and responded with
> STATUS_INVALID_NETWORK_RESPONSE.
>
> A similar issue with the same symptoms was reported to this list a few
> years ago without resolution: http://www.osronline.com/
> ShowThread.cfm?link=180361
>
> [ASIDE:
>
> FastFat does not get into this trap for QueryDirectory, because it uses
> the Irp->MdlAddress when it needs to postpone IRP handling (because it
> cannot acquire locks, etc.) This works in the SRV2 case, because SRV2 has
> “helpfully” set the Irp->MdlAddress for it.
>
> I expect that I will hear people saying: “just do what FastFat does”. That
> is not always possible; my FSD is not FastFat and has very different
> functionality (the primary difference regarding IRP handling is that I have
> to potentially pend pretty much every IRP that I receive).
>]
>
> While I have fixed this particular issue, I am looking to better
> understand SRV2 “flavored” IRP’s and how to correctly identify and handle
> them. I often have to do the SystemBuffer trick, because I often have to
> pend IRP’s. For example, I also do it in IRP_MJ_QUERY_SECURITY (although my
> tests pass there – I intend to investigate nevertheless).
>
> Thank you for your attention.
>
> Bill
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

8

Possibly SRV2 doesn’t expect that volume devices can have DO_BUFFERED_IO
flag set

9

Anatoly Mikhailov wrote:

Why your handler uses SystemBuffer? Your volume device object has
DO_BUFFERED_IO flag set?

No, it does not have the DO_BUFFERED_IO set. It uses the SystemBuffer, because it needs to pend the IRP and complete it in a context other than the one when the IRP was received. It cannot use the Irp->MdlAddress for this purpose (in this instance), for reasons that are specific to my FSD.

Bill

10

You can’t map MdlAddress into kernel space?

28 окт. 2016 г. 8:33 PM пользователь
написал:

> Anatoly Mikhailov wrote:
> > Why your handler uses SystemBuffer? Your volume device object has
> DO_BUFFERED_IO flag set?
>
> No, it does not have the DO_BUFFERED_IO set. It uses the SystemBuffer,
> because it needs to pend the IRP and complete it in a context other than
> the one when the IRP was received. It cannot use the Irp->MdlAddress for
> this purpose (in this instance), for reasons that are specific to my FSD.
>
> Bill
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

11

About SystemBuffer I know that SRV2 doesn’t process IRP completion like I/O
manager does. I think that was the problem.

12

Then the problem is that the I/O Manager is tolerating your violation of the I/O contract and SRV2 is not.

If you don’t say DO_BUFFERED_IO then the caller doesn’t have any reason to expect you will return a buffer that needs to be freed. Does this really work with verifier enabled?

If you want to use buffered I/O, set the flags in your DeviceObject. If SRV2 still misbehaves then you can raise a bug in SRV2, but the behavior you describe makes sense.

Tony
OSR

13

Tony:

Then the problem is that the I/O Manager is tolerating your violation of the I/O contract and SRV2 is not.

It would be helpful if you pointed me to documentation that shows where I am violating the I/O contract. If anything I would argue that SRV2 is violating the IRP completion contract.

I note that FastFat itself has a FatBufferUserBuffer routine that does what I am describing: sets up a SystemBuffer and then sets the IRP flags to IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER. This is where I got the idea of (sometimes) doing this style of processing when I need to pend IRP’s in the first place. [I extended this method to also do IRP_INPUT_OPERATION processing.]

Bill

14

“Setting up a device object Flags field with DO_DIRECT_IO or DO_BUFFERED_IO determines how the I/O manager passes access to user buffers in all data transfer requests subsequently sent to the driver.”

https://msdn.microsoft.com/en-us/library/windows/hardware/ff547807(v=vs.85).aspx

Interesting. Well that helps support your theory that this is a bug then. Like many things in this area, sometimes things “work” even if they were beyond the scope of what was intended.

Even if you create a bug report with Microsoft, it won’t fix your current problem. Thus, you may need to find another way to track these buffers. For example, you could keep a list of such buffers associated with the file and when you see cleanup free those buffers. It’s not a perfect solution, but it’s pragmatic - it works around this issue.

Tony
OSR

15

There is no any violation. I/O manager doesn’t check on IRP completion for
this fact, it just uses IRP_BUFFERED_IO and IRP_DEALLOCATE_BUFFER flags to
decide what to do with system buffer.
The matter is the SRV2 doesn’t use IoCompleteRequest to complete IRP and do
all cleanup by itself.

2016-10-28 21:02 GMT+03:00 Tony Mason :

>


>
> “Setting up a device object Flags field with DO_DIRECT_IO or
> DO_BUFFERED_IO determines how the I/O manager passes access to user buffers
> in all data transfer requests subsequently sent to the driver.”
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/
> ff547807%28v=vs.85%29.aspx
>
>


>
> Interesting. Well that helps support your theory that this is a bug
> then. Like many things in this area, sometimes things “work” even if they
> were beyond the scope of what was intended.
>
> Even if you create a bug report with Microsoft, it won’t fix your current
> problem. Thus, you may need to find another way to track these buffers.
> For example, you could keep a list of such buffers associated with the file
> and when you see cleanup free those buffers. It’s not a perfect solution,
> but it’s pragmatic - it works around this issue.
>
> Tony
> OSR
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

16

These flags are used by I/O manager to decide what to do with user buffer,
lock it or copy into separate buffer, on IRP creating time.

2016-10-28 21:07 GMT+03:00 Anatoly Mikhailov :

>


>
> There is no any violation. I/O manager doesn’t check on IRP completion for
> this fact, it just uses IRP_BUFFERED_IO and IRP_DEALLOCATE_BUFFER flags
> to decide what to do with system buffer.
> The matter is the SRV2 doesn’t use IoCompleteRequest to complete IRP and
> do all cleanup by itself.
>
> 2016-10-28 21:02 GMT+03:00 Tony Mason :
>
>>


>>
>> “Setting up a device object Flags field with DO_DIRECT_IO or
>> DO_BUFFERED_IO determines how the I/O manager passes access to user buffers
>> in all data transfer requests subsequently sent to the driver.”
>>
>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff
>> 547807%28v=vs.85%29.aspx
>>
>>


>>
>> Interesting. Well that helps support your theory that this is a bug
>> then. Like many things in this area, sometimes things “work” even if they
>> were beyond the scope of what was intended.
>>
>> Even if you create a bug report with Microsoft, it won’t fix your current
>> problem. Thus, you may need to find another way to track these buffers.
>> For example, you could keep a list of such buffers associated with the file
>> and when you see cleanup free those buffers. It’s not a perfect solution,
>> but it’s pragmatic - it works around this issue.
>>
>> Tony
>> OSR
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>
>
></http:>

17

FastFat does that only for SetEa request.

2016-10-28 21:11 GMT+03:00 Anatoly Mikhailov :

>


>
> These flags are used by I/O manager to decide what to do with user buffer,
> lock it or copy into separate buffer, on IRP creating time.
>
> 2016-10-28 21:07 GMT+03:00 Anatoly Mikhailov :
>
>>


>>
>> There is no any violation. I/O manager doesn’t check on IRP completion
>> for this fact, it just uses IRP_BUFFERED_IO and IRP_DEALLOCATE_BUFFER
>> flags to decide what to do with system buffer.
>> The matter is the SRV2 doesn’t use IoCompleteRequest to complete IRP and
>> do all cleanup by itself.
>>
>> 2016-10-28 21:02 GMT+03:00 Tony Mason :
>>
>>>


>>>
>>> “Setting up a device object Flags field with DO_DIRECT_IO or
>>> DO_BUFFERED_IO determines how the I/O manager passes access to user buffers
>>> in all data transfer requests subsequently sent to the driver.”
>>>
>>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff
>>> 547807%28v=vs.85%29.aspx
>>>
>>>


>>>
>>> Interesting. Well that helps support your theory that this is a bug
>>> then. Like many things in this area, sometimes things “work” even if they
>>> were beyond the scope of what was intended.
>>>
>>> Even if you create a bug report with Microsoft, it won’t fix your
>>> current problem. Thus, you may need to find another way to track these
>>> buffers. For example, you could keep a list of such buffers associated
>>> with the file and when you see cleanup free those buffers. It’s not a
>>> perfect solution, but it’s pragmatic - it works around this issue.
>>>
>>> Tony
>>> OSR
>>>
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>>
>>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>>> software drivers!
>>> Details at http:
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at <
>>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>>
>>
>>
></http:>

18

This documentation is what someone implementing this on their own would rely upon. If there were some formal description of how this should behave, it would make life easier. This is the closest thing that I could find to support this view of the world.

The pragmatic answer is: SRV2 is part of Windows and thus gets to define correct behavior. If it does not work on a third party driver, the third party driver writer should fix the problem. It *is* possible to get Microsoft to change behavior, but you must be able to make a clear argument on why it is their bug.

Tony
OSR

19

Tony Mason wrote:
<<
“Setting up a device object Flags field with DO_DIRECT_IO or DO_BUFFERED_IO=
determines how the I/O manager passes access to user buffers in all data t=
ransfer requests subsequently sent to the driver.”

>

I see this, but cannot readily translate it into “you cannot allocate and use your own SystemBuffer”.

<<

Interesting. Well that helps support your theory that this is a bug then. =
Like many things in this area, sometimes things “work” even if they were b=
eyond the scope of what was intended.

Even if you create a bug report with Microsoft, it won’t fix your current p=
roblem…

>

I agree. One has to be pragmatic in these cases. I only use my version of FatBufferUserBuffer in IRP_MJ_QUERY_SECURITY and IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY. It may be worth eliminating these usages to be on the safe side, despite the short term pain this will cause me.

I am now also thinking that my IRP_MN_QUERY_DIRECTORY processing may be hostile to filters which, following the FastFat example, do not expect to see anything in the SystemBuffer.

Bill

20

Windows kernel reversing and Windows Research Kernel let me understand that
this behaves such way not ambiguous. This is not such kind of things that
could change in future.

For my experience it’s senseless. Even this would be considered as a bug
you’ll have to support existing versions of SRV2 any way.

Besides FatBufferUserBuffer routine, FsRtlNotifyCompleteIrp kernel routine
does the same. It’s not a bug, windows kernel developers designed things
such way.

2016-10-28 21:32 GMT+03:00 :

> Tony Mason wrote:
> <<
> “Setting up a device object Flags field with DO_DIRECT_IO or
> DO_BUFFERED_IO=
> determines how the I/O manager passes access to user buffers in all data
> t=
> ransfer requests subsequently sent to the driver.”
> >>
>
> I see this, but cannot readily translate it into “you cannot allocate and
> use your own SystemBuffer”.
>
> <<
>


>
> Interesting. Well that helps support your theory that this is a bug then.
> =
> Like many things in this area, sometimes things “work” even if they were
> b=
> eyond the scope of what was intended.
>
> Even if you create a bug report with Microsoft, it won’t fix your current
> p=
> roblem…
> >>
>
> I agree. One has to be pragmatic in these cases. I only use my version of
> FatBufferUserBuffer in IRP_MJ_QUERY_SECURITY and
> IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY. It may be worth
> eliminating these usages to be on the safe side, despite the short term
> pain this will cause me.
>
> I am now also thinking that my IRP_MN_QUERY_DIRECTORY processing may be
> hostile to filters which, following the FastFat example, do not expect to
> see anything in the SystemBuffer.
>
> Bill
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>