activesync integration woes

Mark_Cook

Hello all
we're experiencing problems with our a file system minifilter driver installed on an Exchange 2003 box. While the filter is running, active sync fails to synchronise but resumes as soon as our driver is unloaded. To try and eliminate the obvious we have developed a basic minifilter driver that does very little beyond retrieving the file name information and printing it to the deubg console but this also exhibits the same problem.

We can also reproduce the problem simply by running the Sysinternals process monitor tool on the Exchange server. Same thing happens - a number of .tmp files are queued up in the temp directory and stay there until we close the tool at which point synchronisation restarts and the .tmp files are dequeued.

Has anybody else experienced this problem ??

Regards

Mark

Doug_N

Hi Mark --

I've experienced exactly what you describe. Microsoft has a known issue
involving ActiveSync and filter drivers, which you are exposing.

http://www.osronline.com/showThread.cfm?link=192515

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

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

Doug


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, November 02, 2011 4:31 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] activesync integration woes

Hello all
we're experiencing problems with our a file system minifilter driver
installed on an Exchange 2003 box. While the filter is running, active sync
fails to synchronise but resumes as soon as our driver is unloaded. To try
and eliminate the obvious we have developed a basic minifilter driver that
does very little beyond retrieving the file name information and printing it
to the deubg console but this also exhibits the same problem.

We can also reproduce the problem simply by running the Sysinternals process
monitor tool on the Exchange server. Same thing happens - a number of .tmp
files are queued up in the temp directory and stay there until we close the
tool at which point synchronisation restarts and the .tmp files are
dequeued.

Has anybody else experienced this problem ??

Regards

Mark



---
NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6596 (20111102) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Mark_Cook

Hi Doug
huge thanks for that. I've tried returning FLT_PREOP_SYNCHRONIZE from the preop to verify that this is the same issue and it works a treat.

Just need to come up with a production quality solution now. I'm thinking along the lines of detecting the specific set of circumstances that lead to this problem (a file opened for asynchronous IO with a synchronous call to a subsequent operation) and returning FLT_PREOP_SYNCHRONIZE only when these criteria are met. Does this sound like a reasonable approach or can anybody suggest anything better ??

Thanks again. I really appreciate this.

Mark

Alex_Carp

Hi Mark,

In my opinion the the best way would be to spend the time and find out which operation it is that is broken.

However, your plan to only synchronize operations that aren't already synchronous doesn't really buy you much. If the operation is already synchronous then FLT_PREOP_SYNCHRONIZE doesn't add much overhead so it doesn't matter. So you could simply always return FLT_PREOP_SYNCHRONIZE instead of FLT_PREOP_SUCCESS_WITH_CALLBACK anyway for the operations that you want to synchronize, regardless of whether it was synchronous or not.

Thanks,
Alex.