Exchange and filter drivers

NTFSD
1

It’s taken a long time and talking to a number of engineers, but I finally
found someone that knew about Exchange and filter driver interactions:

http://support.microsoft.com/kb/2009604

http://support.microsoft.com/?id=967479

I pass this on in case any of your customers might run into this like mine
have.

My question: How can a filter “force all file I/O operations to be performed
asynchronously”?

The only thing I can think of that might possibly be at all related would be
to deny fast I/O, return FLT_PREOP_SYNCHRONIZE or call
FltDoCompletionProcessingWhenSafe. But that’s a stretch, and even then, it
seems mighty hard to believe it would affect something in user space.

Doug

2

Hi Doug,

I’m not sure if this is the problem you are seeing, but I’ve seen such
problems before when a filter returns pending and the caller is not prepared
to handle it. Filter manager has some logic to detect whether it might need
to pend an operation on behalf of a minifilter and it pends the IRP just in
case (the reason is that it can’t know in advance what the minifilter will
do and there are cases where if it waits until the minifilter returns it
will be too late to pend the operation then). The result is that even if the
minifilter doesn’t actually pend anything, the operation will still be
pended.

The fault in these cases lies with the application. This is not specific to
filter manager, any legacy file system filter or even a change in the IO
manager or the file system might expose the application flaw.

One way you can verify this is by removing the callbacks you’ve registered
one by one and see which one it is (since fltmgr will make the decision for
each operation and if there are no callbacks it won’t do anything). Or you
could try the same with the passthrough minifilter in the WDK since it
registers for all operations and see if it exposes the same behavior.

Thanks,

Alex.

3

In addition to Alex’s suggestions, I would also note that there is a verifier option that will return STATUS_PENDING to essentially all I/O operations.

I have found that applications sometimes ask for asynchronous I/O and don’t respond well when they get it, which it sounds like be the issue in this case. NTFS, for example, might just process that request synchronously while my file system posts it much more aggressively (both are legitimate and correct, by the way.) Such applications are broken.

An application that does NOT ask for asynchronous I/O (e.g., it sets the FILE_SYNCHRONOUS_IO_NONALERT or FILE_SYNCHRONOUS_IO_ALERT option) will not experience an issue here because the I/O Manager will make the I/O synchronous in any case.

Thus, to get into this situation, you’d need an application that opens a file for “overlapped I/O” (Win32 speak) and then chokes when it GETS overlapped I/O. That’s an application bug. If that’s the issue in Exchange, they should fix it, except (of course) they might say “this doesn’t happen on NTFS.” That’s where the verifier option could be useful because you could say “well, actually it DOES happen on NTFS when I’m running it under Verifier.”

In the past when we’ve run into this, we’ve suggested to customers how they can build special work-arounds for this scenario (e.g., you build a heuristic for detecting this case and change behavior to make Exchange happy.) Even if it isn’t a bug in your code, that can often be difficult to explain to a customer.

Tony
OSR

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doug
Sent: Saturday, October 16, 2010 7:36 AM
To: ntfsd redirect
Subject: [ntfsd] Exchange and filter drivers

It’s taken a long time and talking to a number of engineers, but I finally found someone that knew about Exchange and filter driver interactions:
http://support.microsoft.com/kb/2009604

http://support.microsoft.com/?id=967479

I pass this on in case any of your customers might run into this like mine have.

My question: How can a filter “force all file I/O operations to be performed asynchronously”?

The only thing I can think of that might possibly be at all related would be to deny fast I/O, return FLT_PREOP_SYNCHRONIZE or call FltDoCompletionProcessingWhenSafe. But that’s a stretch, and even then, it seems mighty hard to believe it would affect something in user space.

Doug

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

4

>Exchange, they should fix it, except (of course) they might say “this doesn’t happen on NTFS.” That’s

where the verifier option could be useful because you could say “well, actually it DOES happen on
NTFS when I’m running it under Verifier.”

I remember doing this testing in year 2006 (Ex 2003+LoadSim+Verifier) and all was fine, even with my driver there :slight_smile:

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com