Hi,
On Windows 10 14393, I’ve observed a non-paging IRP_MJ_WRITE request in my minifilter with Data->Thread == NULL. This request comes in with FltGetRequestorProcess(Data) == PsInitialSystemProcess and RequestorMode == KernelMode. The request is on a .slp file, which appears to be related to the Hyper-V dynamic memory feature:
0: kd> !fileobj ffffb608a7e46140
\VirtualMachine<snipped>\Virtual Machines\3CBC729A-14A6-42F8-A79B-70EDD5ABD3A5\3CBC729A-14A6-42F8-A79B-70EDD5ABD3A5.0000000000000000.slp
Are IRPs with a NULL ETHREAD technically legal or is this a bug in how Hyper-V builds its requests? Can anyone point out any other situation in which an IRP would have a NULL Thread field?
If FltGetReuqetorProcess returns a pointer to the system process then it
means the thread pointer is there in the IRP.
Use !fltkd.cbd and check more details.
Cheers,
Gabriel.
www.kasardia.com
On Thu, Apr 20, 2017 at 8:04 AM, wrote:
> Hi,
>
> On Windows 10 14393, I’ve observed a non-paging IRP_MJ_WRITE request in my
> minifilter with Data->Thread == NULL. This request comes in with
> FltGetRequestorProcess(Data) == PsInitialSystemProcess and RequestorMode ==
> KernelMode. The request is on a .slp file, which appears to be related to
> the Hyper-V dynamic memory feature:
>
> 0: kd> !fileobj ffffb608a7e46140
>
> \VirtualMachine<snipped>\Virtual Machines\3CBC729A-14A6-42F8-
> A79B-70EDD5ABD3A5\3CBC729A-14A6-42F8-A79B-70EDD5ABD3A5.
> 0000000000000000.slp
>
> Are IRPs with a NULL ETHREAD technically legal or is this a bug in how
> Hyper-V builds its requests? Can anyone point out any other situation in
> which an IRP would have a NULL Thread field?
>
>
> —
> 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>
>
–
Bercea. G.</http:>
When IRP completion doesn’t require access to a process specific address space ( user space or hyper space ) and is not attached to a thread. In that case there is no need for a valid thread pointer.
For example a completion routine returns STATUS_MORE_PROCESSING_REQUIRED. IRP and all related resources are freed either in the completion routine or somewhere else without a call to IoCompleteRequest.
Gabriel, FltGetRequestorProcess indeed returns the system process but the thread pointer in the case of this request (a write to Hyper-V’s second level paging file) is NULL. I know normal kernel mode requests from system process context have a non-NULL Thread (specifying the thread in the system process that originated the request, e.g., one of SRV’s threads). But this one does not. I am asking whether anyone has observed other similarly “weird” requests.
Slava, the IRP’s Thread pointer is set by the requestor when building it, so I don’t see what a particular driver in the stack returning STATUS_MORE_PROCESSING_REQUIRED from its completion routine has to do with it. A driver doing that would not zero the Thread field previously set by the requestor (e.g., perhaps a driver higher in the stack requires that information) and whether or not the drivers in the stack do not need the requesting thread is opaque to the requestor so I don’t see how a requestor could safely not set the Thread field when building an IRP.
The “requestor” sets the completion routine that returns STATUS_MORE_PROCESSING_REQUIRED or use some other technique that says to IoCompleteRequest to not schedule a completion APC. The “requestor” is the IRP owner and has a control over its completion.
IRP is not required to be associated with a thread. The only reason for IRP to be associated with a thread is to copy data and/or return status to a user mode address space or hyperspace by scheduling an APC. If there is no need to do this there is no requirement to associate IRP with a user thread.