irp_mj_set_information_file and requestor process

NTFSD
1

Hello,

In our company we have a minifilter driver that works quiet fine.
Recently when we were looking at logs we saw there was a bug in which by mistake was used PsGetCurrentProcess() instead of FltGetRequestorProcess(). Reason why we have found it was fact that in logs we observed System process, not ‘normal’ one.
And here is a question to you. Why on preSetInformationFile there is ‘System’involved’ ?
Shouldn’t it be legal reuqestor process same as PsGetCurrentProcess() on pre events?

If not can you give me any ‘theory’ on this?
Thank you

2

There are two possibilities:

  1. The request was actually sent from the System process (e.g. a driver
    could send the request from a worker thread)

  2. Another filter in the system posted the operation to a worker thread
    before sending it down

Down at the file system level, the file systems are written to properly
handle user requests coming in from the System process (they will often post
user requests to the System worker queue and process them there instead of
in user context).

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Hello,

In our company we have a minifilter driver that works quiet fine.
Recently when we were looking at logs we saw there was a bug in which by
mistake was used PsGetCurrentProcess() instead of FltGetRequestorProcess().
Reason why we have found it was fact that in logs we observed System
process, not ‘normal’ one.
And here is a question to you. Why on preSetInformationFile there is
‘System’involved’ ?
Shouldn’t it be legal reuqestor process same as PsGetCurrentProcess() on pre
events?

If not can you give me any ‘theory’ on this?
Thank you

3

Scott!
Thank you for fast response.
Regarding 1 and 2 - this is what I’ve expected.
Will FltGetRequestorProcess really give me answer who is original requestor then?
What this API actually do?

Thanks!

4

FltGetRequestorProcess just calls IoGetRequestorProcess on the underlying
IRP (if any). This returns the requesting process information by decoding
fields of the IRP structure. If the fields in the IRP aren’t populated, the
API just returns the current process.

Thus, FltGetRequestorProcess depends on the underlying IRP being built
“properly” to indicate the requesting process. IRPs generated by the I/O
Manager for user mode requests are built to contain this information.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Scott!
Thank you for fast response.
Regarding 1 and 2 - this is what I’ve expected.
Will FltGetRequestorProcess really give me answer who is original requestor
then?
What this API actually do?

Thanks!

5

Thank you again.

Can we clarify one more thing please?
You wrote:
“If the fields in the IRP aren’t populated, the API just returns the current process.”

and doc says following (https://msdn.microsoft.com/en-us/library/windows/hardware/ff543115(v=vs.85).aspx):
" If the operation is not associated with any thread, FltGetRequestorProcess returns NULL. "

Is it different case?

6

Sorry, mistyped: the docs are correct, the API will return NULL if the
fields aren’t populated.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Thank you again.

Can we clarify one more thing please?
You wrote:
“If the fields in the IRP aren’t populated, the API just returns the current
process.”

and doc says following
(https://msdn.microsoft.com/en-us/library/windows/hardware/ff543115(v=vs.85).aspx):
" If the operation is not associated with any thread, FltGetRequestorProcess
returns NULL. "

Is it different case?

7

Thank you for all information.