Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info: https://www.osr.com/fesf

Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 5  
07 Sep 17 08:57
John Smith
xxxxxx@protonmail.ch
Join Date: 07 Sep 2017
Posts To This List: 2
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.
  Message 2 of 5  
07 Sep 17 09:33
Peter Scott
xxxxxx@kerneldrivers.com
Join Date: 17 Feb 2012
Posts To This List: 666
How to identify the user process that initiates an IRP_PAGING_IO within a minifilter driver.

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" <xxxxx@protonmail.ch> To: "Windows File Systems Devs Interest List" <xxxxx@lists.osr.com> 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). > <...excess quoted lines suppressed...> --
  Message 3 of 5  
07 Sep 17 10:51
John Smith
xxxxxx@protonmail.ch
Join Date: 07 Sep 2017
Posts To This List: 2
How to identify the user process that initiates an IRP_PAGING_IO within a minifilter driver.

Thanks very much for your response. I wanted to have expert opinions.
  Message 4 of 5  
09 Sep 17 11:39
Mike Boucher
xxxxxx@gmail.com
Join Date: 11 Oct 2015
Posts To This List: 7
How to identify the user process that initiates an IRP_PAGING_IO within a minifilter driver.

>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 <xxxxx@lists.osr.com> 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! <...excess quoted lines suppressed...> --
  Message 5 of 5  
10 Sep 17 09:14
Jamey Kirby
xxxxxx@gmail.com
Join Date: 31 Dec 2014
Posts To This List: 45
How to identify the user process that initiates an IRP_PAGING_IO within a minifilter driver.

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@gmail.com> < 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. > <...excess quoted lines suppressed...> --
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 13:36.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license