Who's Asking: The Problem With IoGetRequestorProcess()
Last time I discussed how IoGetRequestorProcess() can get you where you want to go in some cases, if where you want to go involves finding out "who" originated an I/O request. See previous articles in this series if you're new to the discussion.
IoGetRequestorProcess works by examining the thread information encoded in the IRP. This information is typically set by the IO manager to reflect the thread in which the IRP was created. The problem, of course, is that not all IRPs will have the right info here:
- No Process - It's entirely possible for IRPs to be created without any process information at all. Anyone who constructs his own IRPs from scratch will have the option of not setting thread context information on the IRP. I'm not sure if this is legal, but it's certainly possible.
- System Process - Many IRPs created by the driver will be in the context of the system process. This is usually the case when a request is posted to a worker thread or a system thread. As I mentioned before, this is not an uncommon case in the presence of filter drivers, or really from within any device stack at all.
- Wrong/Arbitrary Process - The most insidious case, of course, is when you find yourself with valid-looking but wrong data. This will clearly be the case if a driver above yours in the stack is called back in an arbitrary process context and decides to create an IRP. This can happen during the rundown of a DPC routine, for example.
So you see, we still seem to be high and dry here. Whatever is a driver to do?
I love cliff-hangers :-)