How can prevent unexpected FastIo operation.

NTFSD
1

Hi,
I have a FS minifilter driver that monitor CreateFile, WriteFile, ReadFile and SetInformation. I was not any problem in operation over office files. But in Acrobat DC, I want to export pdf file on the exist docx file (really replace). Target file will be corrupted.

Checking procmon log and Debugging minifilter driver displays there is a WriteFile that never reaches to minifilter driver (procmon log is as follows):

FASTIO_ACQUIRE_FOR_CC_FLUSH
IRP_MJ_WRITE (Details: Non-cached, Paging I/O, Synchronous Paging I/O)
FASTIO_RELEASE_FOR_CC_FLUSH

  • It’s a FastIo operation?

I want to get this WriteFile in minifilter driver or prevent it.

Trying to disable FastIo over a fileobject in PreCreateFile operation failed because FsContext of fileobject is null (as follows):

fcb = (PFSRTL_COMMON_FCB_HEADER)fileObject->FsContext;
if (fcb)
fcb->IsFastIoPossible = FastIoIsNotPossible;

  • How can detect FASTIO_ACQUIRE_FOR_CC_FLUSH in minifilter? I have added FastIo dispatch routines to my minifilter driver and assign it to DriverObject->FastIoDispatch. In debugging there isn’t any call of them, but in procmon logs there is FastIO operations that i want to disallow them.

I am confued about FastIo and more study makes it more.

2

TL;DR You are trying to glue wings on a pig[1]. What is your filter trying
to do?

Many of your questions indicate that you don’t completely understand how the
File Systems interact with the cache. I’d urge you to research that.

In more detail

  • It’s a FastIo operation?

No. the hint is here

IRP_MJ_WRITE (Details: Non-cached, Paging I/O, Synchronous Paging
I/O)
^^^^^^^^^
I want to get this WriteFile in minifilter driver

Fair enough, then register[2] for it. It’s a paging IO and if you aren’t
seeing it then it indicates that your registration for the MJ_WRITE
has FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO set.

or prevent it.
You mustn’t. You will hang your system that way. This is the write back
from a cached operation (probably)

  • How can detect FASTIO_ACQUIRE_FOR_CC_FLUSH in minifilter?

Register for it. IRP_MJ_ACQUIRE_FOR_CC_FLUSH. But you don’t need to

I have added FastIo dispatch routines to my minifilter driver and assign
it to DriverObject->FastIoDispatch

Don’t do either of these things. The way to register for operations is via
the FltRegisterFile. Those locations are for people writing a file system.
And there aren’t a lot of them out there. Indeed there are some of these
requests that you *CANNOT* refuse.

I am confued about FastIo and more study makes it more.

The name doesn’t help. Nor does the history. Going back to when NT had to
boot in 64Mb of memory and cycles really counted there was a desire to avoid
creating IRPs (another structure you - mostly- don’t need to care about)
when all the file system was going to do was copy the write into the cache.
This made (at the time) a measureable difference. Fast forward to qual of
(I think) Windows NT 3.7 and deadlocks kept on happening and there was an
urgent need for a direct call into the file system to tell it to pre-empt
the hang. The function array was there so it was abused. So most of these
calls are neither Fast, nor to do with IO.

Filter Manager abstracts all this away for you and you just see requests you
register for Under some cases (prior tio posting) the “IRPness” matters and
you have a way to deal with it.

But mostly you don’t care about the fast IO operations. 4 of them say “I am
about to flush” or “I have just done a flush”. Two are for “I am about to
create a section” and “I have just created a section” and so on.

In practice I’d say (SWAG) that 90% of minifilters filters don’t care about
(do something other than notice) them and of the remaining 10%, 9% only care
about the section thing.

If I may suggest:

  1. Learn about cached IO and non Cached IO. Fire up procmon and watch a
    file which you manipulate in FileTests - you’ll see that that stanza you
    quite (Acquire/PagingWrite/Release) happens *ALL THE TIME*. So you have to
    be able to deal with it and to do that you have to understand what’s
    happening.

  2. Tell us what you are trying to do

HTH

/Rod
[1]http://www.osronline.com/downloads/pp_asking.pdf
[2]https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/fltkernel/nf-fltkernel-fltregisterfilter
[3]https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/fltkernel/ns-fltkernel-_flt_parameters

3

> What is your filter trying to do?

It’s an encryption file system minifilter driver that detects sensitive files and encrypt theme.

Fair enough, then register[2] for it. It’s a paging IO …

I was registered WriteFile IRP. How can detect WriteFile “paging Io” in minifilter driver. All of the method that I was see are “paging File” detection method(such as FsRtlIsPagingFile or alloc_text).

4

registration for the MJ_WRITE has not FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO Flag.
It is “0”.

5

It?s a bit in the I/O Parameter Block. See the docs

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/fltkernel/ns-fltkernel-_flt_io_parameter_block

-scott
OSR

6

Thanks Scott, I was tested it.

I want to get IRP of this mentioned write. Setting Paging-IO flags in Iopb of PFLT_CALLBACK_DATA or setting 0 in second parameter of FLT_OPERATION_REGISTRATION structure, there was not any result. This Write changes EndOfFile that corrupts my encrypted file.

7

> IRP_MJ_WRITE (Details: Non-cached, Paging I/O, Synchronous Paging

This Write changes EndOfFile that corrupts my encrypted file.

I think that there is something else going on here. Paging writes never,
ever, change the end of file. Its part of the contract.