Irp->Tail.Overlay.Thread == NULL?

In my legacy FSFD when I filter IRP_MJ_READ, I call this to get the PID of
the requestor:

IoGetRequestorProcessId(pIrp)

In some rare occasions it is coming up as zero. Further exploration shows
that it because a higher level driver is leaving pIrp->Tail.Overlay.Thread
== NULL.

Is that valid, or does that signify a bug in the higher level driver? Is
there an alternate way of getting the requestor PID?

Thanks.

Yup. Entirely valid and to be expected.

In this case, the I/O will not have originated from user mode, and the IRP will not be “threaded” (accounted for on a Thread’s IRP list).

Peter
OSR

BTW - in my experience, submitting the request with this field being junk (not NULL, just not filled) to the ATA disk stack can sometimes (under heavy load, hardly reproducible) cause the stack to hang, the IRP is stuck in atapi.sys forever.

I don’t know whether everybody else have ever met this.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Yup. Entirely valid and to be expected.
>
> In this case, the I/O will not have originated from user mode, and the IRP will not be “threaded” (accounted for on a Thread’s IRP list).
>
> Peter
> OSR
>
>

?õ?
?? 2011-10-25 ???12:04??“Neil Weicher” д???

> In my legacy FSFD when I filter IRP_MJ_READ, I call this to get the PID of
> the requestor:
>
> IoGetRequestorProcessId(pIrp)
>
> In some rare occasions it is coming up as zero. Further exploration shows
> that it because a higher level driver is leaving pIrp->Tail.Overlay.Thread
> == NULL.
>
> Is that valid, or does that signify a bug in the higher level driver? Is
> there an alternate way of getting the requestor PID?
>
> Thanks.
>
>
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> 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
>