We, as file system and file system filter driver developers, are aware of the perils of issuing IO on the file system stack at APC level or with special kernel APCs disabled. Such IOs trigger unwanted side effects in the system that cause noticeable end user frustrations like hung IO completions and subtle memory corruptions that are difficult to track down.  The following MSDN document correctly summarizes the IRQL requirements for dispatch routines for file systems and file system filter drivers:

Dispatch Routine IRQL and Thread Context

http://msdn.microsoft.com/en-us/library/ms790762.aspx

None of the IO operations where the Caller’s IRQL is listed as PASSIVE_LEVEL in the document above, can be issued at APC or with Special Kernel APCs disabled.

A file system filter driver should not issue IO at an IRQL that causes the IRQL requirements mentioned in the table to be violated for the file system or the file system filters below it.

We have found that some drivers/filters continue to do this in certain cases ( e.g. non cached IO ) as they have found that this appears to work in certain situations. This is of serious concern to us. In an effort to improve system stability, we are looking at ways we can use driver verifier to detect drivers that issue IO in this way and flag them so that they can be fixed. Given that such IO can cause subtle corruptions that are hard to track down after the fact, we are also considering detecting IO’s that are incorrectly issued at APC or with special kernel APCs disabled and failing them in the file system as well.  

This announcement does not introduce any new rule and is not a replacement for any other existing rules for when it is safe to issue IO from a file system filter. This e-mail simply brings to your attention that we are considering enforcing the existing restrictions discussed in the MSDN document above in the upcoming release of the operating system.

At the next IFS Plugfest, we plan to make available an OS build which includes these changes so that participants can test their driver against it. However, we felt that it would better to give as much lead time as possible to the filter community to enable them to adapt their filters to this change (if required) .

Please send email to fsfcomm@microsoft.com or to people on the cc line  if you have any questions or concerns around this. A detailed description of why you think this will be a problem for your product will help us engage you and use your feedback.

Thanks for your co-operation,