fltReadFile fails only on windows 10 with status_invalid_device_request

If you are never going to be involved on that volume my suggestion would be to use Zw…

As for your proposed method, do not use a random instance, rather use the top instance (there is a call to give you that)… There are several classes of filters which will cause a crash in the FSD if you skip them…

This is safe. You can place the read anywhere you want in the stack.
You might break some encryption or AV filters, perhaps :slight_smile:

But they must be able to handle such cases! No read is guaranteed to
be never from the top of a minifilter stack (as opposed to a top of
the whole FS filter stack), nor are they guaranteed to pass through
their filters.

This is not a suggestion, as in “do that”. It was only a comment that
it is possible to do that.\

This is safe. You can place the read anywhere you want in the stack.
With the greatest respect, you cannot. This is not safe.

You might break some encryption or AV filters, perhaps :slight_smile:
No, you run a real risk of causing on a crash if the filter is making use of shadow file objects (see NT Insiders passim). The Microsoft Windows FSD’s react with great hostility to file objects they did not create.

I am also aware of at least one Microsoft sourced filter which might also cause issues because it demands to be in the way if it has seen the create.

If you issue a create at a certain level then you HAVE to respect that ordering. Sending a create with an Instance NULL means you send the create at the top of the stack which means that you need to send reads and writes to the top of the stack.

This is not breaking some filter. This is causing a crash because you have broken the architectural constraints.

Filters will NOT see all file objects’ create, e.g. Stream file objects.
The shadow FOs still have issues with MUP.

It should not be so, but FILTERS must be ready for FOs they did not see.
Several large scale deployed AVs do this sometimes.

What must NOT be done is the opposite: create at a position, but read at a
higher position. Create on top and read elsewhere is not an issue that you
describe - the filter WILL have seen an open request in this case.