How to identify the user process that initiates an IRP_PAGING_IO within a minifilter driver.

Hello people.

I am developing a minifilter driver that monitors the IRP_MJ_WRITE requests (PreOperationCallback).
Then, we consider all the IO coming from the UserMode threads (Data->RequestorMode).
We are also interested by the KernelMode threads only if the IRP_PAGING_IO bit is set (Data->Iopb->IrpFlags).
The aim of our minifilter is to block malicious activities (malware).

The question is:

I would like to know which userland process “initiated” the paging IO ? (I guess KernelMode thread can also initiated paging IO)
The purpose is to block the malicious thread that stands in userland and not the system thread that manages the virtual memory.

I have not found so far any interested fields in the FLT_CALLBACK_DATA and FLT_RELATED_OBJECTS variables.
I tried the LIST_ENTRY IrpList field in FILE_OBJECT, but it seems to be always empty in this case.

Best regards.

You can’t always associate a paging request to a specific user thread.
The various MM and CM threads performing flushes of data from the cache
may not be triggered by the direct action of a user mode thread and
therefore it is impossible, in some situations, to accurately know which
caused the paging activity. You can collect heuristics of course. For
example, only 1 process has the file open then you can be certain the
paging activity is due to that user. But if 2 processes have it open
then the MM MPW thread could be flushing pages dirtied by both users, or
just one of them, who knows.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: “KyBu7w”
To: “Windows File Systems Devs Interest List”
Sent: 9/7/2017 6:55:05 AM
Subject: [ntfsd] How to identify the user process that initiates an
IRP_PAGING_IO within a minifilter driver.

>Hello people.
>
>I am developing a minifilter driver that monitors the IRP_MJ_WRITE
>requests (PreOperationCallback).
>Then, we consider all the IO coming from the UserMode threads
>(Data->RequestorMode).
>We are also interested by the KernelMode threads only if the
>IRP_PAGING_IO bit is set (Data->Iopb->IrpFlags).
>The aim of our minifilter is to block malicious activities (malware).
>
>The question is:
>
>I would like to know which userland process “initiated” the paging IO ?
>(I guess KernelMode thread can also initiated paging IO)
>The purpose is to block the malicious thread that stands in userland
>and not the system thread that manages the virtual memory.
>
>I have not found so far any interested fields in the FLT_CALLBACK_DATA
>and FLT_RELATED_OBJECTS variables.
>I tried the LIST_ENTRY IrpList field in FILE_OBJECT, but it seems to be
>always empty in this case.
>
>Best regards.
>
>
>
>— NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
>WDF, Windows internals and software drivers! Details at To unsubscribe,
>visit the List Server section of OSR Online at

Thanks very much for your response.

I wanted to have expert opinions.

>only 1 process has the file open then you can be certain the paging
activity is due to that user

I think it may be true that if only one process has ever had the file open
then you can attribute the I/O to that process. One can imagine a process
opening the file, mapping a section, closing the file, dirtying the
section, and then terminating before the writeback of the dirty page. If
another process still has the section mapped at the time of writeback, it
should not be blamed for the writeback.

Of course, that does not take away from your correct point that it is
generally not possible to attribute paging I/O to a particular process.

On Thu, Sep 7, 2017 at 8:49 AM, xxxxx@protonmail.ch
wrote:

> Thanks very much for your response.
>
> I wanted to have expert opinions.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Don’t waste your time going down this path. The layers are designed to
decouple process from disk IO.

On Sat, Sep 9, 2017, 11:38 AM Mike Boucher <
xxxxx@lists.osr.com> wrote:

> >only 1 process has the file open then you can be certain the paging
> activity is due to that user
>
> I think it may be true that if only one process has ever had the file open
> then you can attribute the I/O to that process. One can imagine a process
> opening the file, mapping a section, closing the file, dirtying the
> section, and then terminating before the writeback of the dirty page. If
> another process still has the section mapped at the time of writeback, it
> should not be blamed for the writeback.
>
> Of course, that does not take away from your correct point that it is
> generally not possible to attribute paging I/O to a particular process.
>
> On Thu, Sep 7, 2017 at 8:49 AM, xxxxx@protonmail.ch
> wrote:
>
>> Thanks very much for your response.
>>
>> I wanted to have expert opinions.
>>
>> —
>> NTFSD is sponsored by OSR
>>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>
>
> — NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
> WDF, Windows internals and software drivers! Details at To unsubscribe,
> visit the List Server section of OSR Online at</http:>