List,
I was looking at the documentation for FltQueryInformationFile and noticed it sais to call this function only as PASSIVE_LEVEL. This seemed odd so I had a quick look at the implementation. FltAllocateCallbackData, FltPerformSynchronousIo(IRP_MJ_QUERY_INFORMATION), FltFreeCallbackData… all of which are available to callers running at APC_LEVEL.
I then thought it may be because the synchronous IRP is delivered at PASSIVE_LEVEL. But in that case, why is FltQueryDirectoryFile not available to callers at APC_LEVEL, since the IRP is delivered at APC_LEVEL?
Any ideas?
Best regards,
Otto
AFAIK APC_LEVEL disables all APCs, including special kernel APCs. I/O
completion is a special kernel APC so I’m guessing that’s why you see this
requirement of PASSIVE_LEVEL and APCs enabled. Incidentally,
ZwQueryInformationFile has the same restriction.
FltPerformSynchronousIo is callable at APC_LEVEL because it supports some
IRP function that is callable with SKAPCs disabled, but it doesn’t mean that
it will work for all possible IRP functions at APC_LEVEL.
Thanks,
Alex.
Hi Alex!
Thanks for the info, and sorry about the timezones.
> FltPerformSynchronousIo is callable at APC_LEVEL because it supports some IRP function that is callable with SKAPCs disabled…
Where can I get a list of those IRPs?
Many thanks,
Otto
> Where can I get a list of those IRPs?
You probably need to ask the authors of every file system that you will be
filtering. They will probably say “well this is liable to change but right
now such and such” (I know that I would).
Hi Rod,
So in the general case, I should never call FltPerformSynchronousIo above PASSIVE_LEVEL.
Are there any specific cases, exceptions, that are widely known and relied upon in the community?