Re[2]: How to get process information that originally create Irps in a disk filter driver

To expand on what Jamey said, you will need to implement a FS filter
driver and collect heuristics to be able to determine the information
you are after. There are going to be windows of opportunity that will
break your design, such as when 2 users have the file open, one for
memory mapped access and one for regular cached access. In this scenario
you cannot tell who made the changes to the file which resulted in the
paging flushes to disk. That said, the set of scenarios which will break
your design are limited but if it is something you are trying to
understand in your volume filter driver, it will be guess work at best.

Pete


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

------ Original Message ------
From: “Jamey Kirby”
To: “Windows File Systems Devs Interest List”
Sent: 10/17/2015 6:35:43 PM
Subject: Re: [ntfsd] How to get process information that originally
create Irps in a disk filter driver

>There really is no safe way to do this. The disk stack is completely
>decoupled from process context. You cannot make any assumptions on
>process context. A file system filter is the last chance you get to
>satisfy process context tracking down the stack.
>ᐧ
>
>On Sat, Oct 17, 2015 at 7:52 PM, wrote:
>>I need to allow only certain process to perform flushes on disk
>>(Windows update
>>in occurrence). I know that calling PsGetCurrentProcessId ibelow the
>>file system (In my disk filter driver) will only get me some system
>>threads performing flushes on disk thus obtaining the System PID in
>>place of the PID of the process that actually initiated the IRP.
>>I know that the IoManager gives us the IRPs in the process context
>>that made the
>>request.
>>Following that assumption, How do I retrieve the process information
>>that created the Irp?
>>I was trying to use pIrp->Tail.Overlay.Thread, to get a pointer to the
>>ETHREAD structure, then get the process that ows it with
>>IoThreadToProcess API and finally make something
>>usable with ZwQueryInformationProcess but doesnt seem to be working?
>>
>>Any hint will be much appreciated.
>>Thank you
>>
>>—
>>NTFSD is sponsored by OSR
>>
>>OSR is hiring!! Info at http://www.osr.com/careers
>>
>>For our schedule of debugging and file system seminars visit:
>>http://www.osr.com/seminars
>>
>>To unsubscribe, visit the List Server section of OSR Online at
>>http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>–
>Jamey Kirby
>Disrupting the establishment since 1964
>
>This is a personal email account and as such, emails are not subject to
>archiving. Nothing else really matters.
>— NTFSD is sponsored by OSR OSR is hiring!! Info at
>http://www.osr.com/careers For our schedule of debugging and file
>system seminars visit: http://www.osr.com/seminars To unsubscribe,
>visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer

Thanks for your reply Jamey. Looking at the structure of an Irp Tail.Overlay.Thread is a pointer to the caller’s thread control block, Microsoft even says (For requests that originate in user-mode, the I/O manager always sets this field to point to the TCB of the thread that issued the request), following that assumption all request coming through a Read Write dispatch routine originate in user mode. So lets suppose I get that field in a volume or disk filter driver, is relying on it to retrieve the process that originated the thread in user mode a wrong practice?

Thank you.

Cheers Peter, I’ll explore that.

Think about the scenario here. A user, or several users, access and
modify a file via either memory mapped and/or regular cached access.
Memory manager determines that there are some dirty pages and flushes
them to disk. Which originating thread does it set this field to since
the original IO has long been completed, in most cases.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@yahoo.fr
To: “Windows File Systems Devs Interest List”
Sent: 10/18/2015 6:31:12 PM
Subject: RE:[ntfsd] How to get process information that originally
create Irps in a disk filter driver

>Thanks for your reply Jamey. Looking at the structure of an Irp
>Tail.Overlay.Thread is a pointer to the caller’s thread control block,
>Microsoft even says (For requests that originate in user-mode, the I/O
>manager always sets this field to point to the TCB of the thread that
>issued the request), following that assumption all request coming
>through a Read Write dispatch routine originate in user mode. So lets
>suppose I get that field in a volume or disk filter driver, is relying
>on it to retrieve the process that originated the thread in user mode a
>wrong practice?
>
>Thank you.
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer

Right. Thank you Peter or making me see it that way. Thought i was done but looks like I’ll need more time.

Thank you all.

Most IO that you will see is going to come from the cache manager, except
on those rare occasions where the file is opened with no buffering by some
specialize application. For most IO, you are going to have issues getting
it right. I think you need to backup a little and re-evaluate some parts of
your design. I suspect you can get there another way. Do you mind me asking
what is the end goal of the design?

On Sun, Oct 18, 2015 at 8:49 PM, wrote:

> Right. Thank you Peter or making me see it that way. Thought i was done
> but looks like I’ll need more time.
>
> Thank you all.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.

Thanks Jamey, initially my goal was just to have a driver that will revert change made to partition(s) or the complete disk(s) mounted, so that on reboot I could keep the same baseline just like no change was really made.
And then few changes now require me to allow windows update pass through the filter driver. That is my final goal.

Than you.

In good old days of ~2006 and WinXP, I once had a bug of not filling Tail.Overlay.Thread for a disk stack IRP created by me using IoAllocateIrp.

This causes the IRP to sometimes get stuck in the ATA driver stack, thus hanging the machine.

But! Besides this (Tail.Overlay.Thread must be a valid thread in disk stack IRPs) I do not think you can rely on the thread identity in the disk stack.

Lots of filter drivers defer the disk stack IRPs till some later event. The event occurs with a completion routine call (which can be in any context), with the IRPs submitted down.

Also, flushing to disk is usually a job of System process.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Thanks for your reply Jamey. Looking at the structure of an Irp Tail.Overlay.Thread is a pointer to the caller’s thread control block, Microsoft even says (For requests that originate in user-mode, the I/O manager always sets this field to point to the TCB of the thread that issued the request), following that assumption all request coming through a Read Write dispatch routine originate in user mode. So lets suppose I get that field in a volume or disk filter driver, is relying on it to retrieve the process that originated the thread in user mode a wrong practice?
>
> Thank you.
>

Thank you for your additional information, Maxim.
It seems like I will have to move from a disk filter driver to a file system filter driver.

Thank you.