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.
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.
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 ??
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.