Query about requester process id in disk filter driver

Hello,

I am working on disk filter driver. After doing some research i understood that, for disk read/write operations its not possible to get actual requester process id every time in disk filter driver.

But my question is, is it possible to get actual requester process id for operations like add partition, remove partition? Does these operations always happens in the context of calling process itself?

Kindly help me to understand this better.

Thanks,
Gaurav

Nope. You cannot rely on knowing the process at the disk level. They’ve
been decoupled by Windows for obvious reasons of design, and simplicity. If
you need to deal with processes, you’ll need to be filtering at the file
system level.

On Mon, Nov 6, 2017 at 11:23 AM xxxxx@gmail.com <
xxxxx@lists.osr.com> wrote:

Hello,

I am working on disk filter driver. After doing some research i understood
that, for disk read/write operations its not possible to get actual
requester process id every time in disk filter driver.

But my question is, is it possible to get actual requester process id for
operations like add partition, remove partition? Does these operations
always happens in the context of calling process itself?

Kindly help me to understand this better.

Thanks,
Gaurav


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:>

I assume you are talking about a normal mode of operation, i.e. a user mode application partitions a drive. This is a direct disk IO in the context of a calling thread through a RAW file system which is a pass through driver. The process context is valid at the RAW FSD level and at the top of a disk driver stack. The process context validity depends on the filter’s position in the stack. If a filter is at the top of the stack it receives direct IO requests from a RAW FSD in the caller’s context.

Alternatively, you can extend the design with a file system minifilter that is attached atop of a RAW FSD object.

There might be a degenerate case when a third party minifilter redirects direct IO requests to a kernel thread. In that case you have to attach your minifilter above this one.

Thank you Jamey and Slava for the response.

Basically i want to monitor MBR modification, Partition modification operations and for that i want to classify those operations based on which process is doing that operation. If i straight away block those operations, then i am afraid that legitimate process will unable to do there work.