IRP requestor vs. PsGetCurrentThread()

NTDEV
1

Currently I’m using PsGetCurrentThread() to determine the thread that
originates a IRP. I understand that this requires that the driver be at
the top of the driver stack.

Is there a way to determine the originator from the IRP directly? I
found IoGetRequestorProcessId(), but ideally I’d want to keep track of
individual threads.

Is pIrp->Tail.Overlay.Thread the way to go?

Thanks in advance,
Joerg

2

I would use IoGetRequestiorProcessId() and compare it with
PsGetCurrentProcessId, if they are the same there is a close to 100%
likelyhood that PsGetCurrentThread is correct. If they are not you are
stuck, you won’t be able to know more than the issuing process.

pIrp->Tail.Overlay.Thread is for threaded IRP’s and not all requests are
threaded, so don’t use it.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of J?rg Faschingbauer
Sent: Tuesday, May 06, 2014 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP requestor vs. PsGetCurrentThread()

Currently I’m using PsGetCurrentThread() to determine the thread that
originates a IRP. I understand that this requires that the driver be at the
top of the driver stack.

Is there a way to determine the originator from the IRP directly? I found
IoGetRequestorProcessId(), but ideally I’d want to keep track of individual
threads.

Is pIrp->Tail.Overlay.Thread the way to go?

Thanks in advance,
Joerg

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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

3

On 05/06/2014 02:46 PM, Don Burn wrote:

I would use IoGetRequestiorProcessId() and compare it with
PsGetCurrentProcessId, if they are the same there is a close to 100%
likelyhood that PsGetCurrentThread is correct. If they are not you are
stuck, you won’t be able to know more than the issuing process.

Ok, so this is going to be the check for those requests that I require
to come directly from userspace.

pIrp->Tail.Overlay.Thread is for threaded IRP’s and not all requests are
threaded, so don’t use it.

Archiving http://blogs.msdn.com/b/doronh/archive/2006/07/27/681179.aspx
for further reading :slight_smile:

Thanks,
Joerg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jörg Faschingbauer
Sent: Tuesday, May 06, 2014 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP requestor vs. PsGetCurrentThread()

Currently I’m using PsGetCurrentThread() to determine the thread that
originates a IRP. I understand that this requires that the driver be at the
top of the driver stack.

Is there a way to determine the originator from the IRP directly? I found
IoGetRequestorProcessId(), but ideally I’d want to keep track of individual
threads.

Is pIrp->Tail.Overlay.Thread the way to go?

Thanks in advance,
Joerg

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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

4

PsGetCurrentProcess[Id] is *never* the correct way to determine the requesting process associated with an IRP. The purpose of this function is to return the ID of the currently executing process, and this may or may not have anything to do with the currently executing thread. Right: You’ll BE in the context of that thread unless you’re the first driver entered after user-mode and there are no filters and if there are filters that aren’t broken those filters haven’t changed context. Sure. But why ask for the current process (or thread) when the information on the IRP’s originator is available to you.

The DDI that’s provided to determine the PROCESS that originated an IRP is IoGetRequestorProcess[Id]. Getting the correct process is a bit more complicated than you might imagine, and this function handles all those subtleties.

However, what the OP *wants* is the originating THREAD. The originating thread will always be in pIrp->Tail.Overlay.Thread if the IRP came from user-mode. If the IRP originated in kernel-mode, pIrp->Tail.Overlay.Thread could be NULL… but then you know its some sort of a kernel-mode IRP and the originating thread doesn’t matter (if it DID matter, the IRP would have been created threaded).

Couldn’t be simpler really.

Peter
OSR
@OSRDrivers

5

> Is there a way to determine the originator from the IRP directly? I

->Tail.Overlay.Thread

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

6

Mr. Shatshkih, just a quick question: Do you *ever* bother to read to the end of a thread before you answer? Or does it not matter, because you’re really just trying to increase your post count?

I’m not saying your answers aren’t sometimes helpful, because they certainly are.

However, you answer a LOT of questions that have already been answered later in the thread… sometimes after the thread has moved on to another topic.

You can even thread emails by subject these days, you know, making reading to the end of a thread relatively straight-forward.

Peter
OSR
@OSRDrivers