Does the kernel ever reuse an existing process id for different images?

I’m not sure what I’m seeing. It looks like a given process id sometimes reports different image file names at different times, without getting a “process termination” notification for that process id.

I’ve written an IRP logger that tracks activity on my dev machine so I can better determine how our driver is functioning, and how it handles different situations. In logging an IRP, we record the requestor process id, along with other information, and queue it for the logger. The logger then uses PsLookupProcessByProcessId() to get a PEPROCESS, then ObOpenObjectByPointer() to get a handle, finally ZwQueryInformationProcess(ProcessImageFileName) to get the image name.

This logger also hooks process creation/termination notifications (PsSetCreateProcessNotifyRoutineEx()) and logs those.

Most of the time the IRP logger reports a consistent process image name from IRP to IRP, and the process creation and termination events agree with what is occurring. Some process ids, however, tend to give different process image names at different times, without intervening process termination and creation notifications. Usually, if not exclusively, the processes doing this are OS utilities such as backgroundTaskHost.exe changing to Windows Defender or vice versa.

Any ideas?

Probably not but…

  • Might KeStackAttachProcess be implicated
  • Might you be being called inside the context of a ProcessNotify callback?

@rod_widdowson said:
Probably not but…

  • Might KeStackAttachProcess be implicated
    That shouldn’t change the image file associated with the pid, though, should it?
  • Might you be being called inside the context of a ProcessNotify callback?
    That should show up in the logs. I’ll look a little closer and see if I can find anything.

Is ZwQueryInformationProcess(ProcessImageFileName) reliable?

Back to first principles:

In logging an IRP, we record the requestor process id

As determined by what exactly? Where are you in the device tree?

Peter

@“Peter_Viscarola_(OSR)” said:
Back to first principles:

In logging an IRP, we record the requestor process id

As determined by what exactly? Where are you in the device tree?
Content Screening altitude minifilter, FltGetRequestorProcessId(Data)

Where I get the process id from isn’t really a concern, though, is it? I’m wondering about the info returned from ZwQueryInformationProcess()

I’ll do some more research as soon as I get a chance and see if I can get a physical example

Where I get the process id from isn’t really a concern, though, is it

Well, it was to me. If it wasn’t, I probably wouldn’t have asked the question, right?

If you were at some random location in the device tree, like down below the Disk Class Driver for example, how you get what you think is the PID associated with the creator of an IRP would matter. Your issue was “a given process id sometimes reports different image file names at different times” – And I was merely questioning whether what you had was a legit PID.

Given that you’re a mini-filter… and retrieving the PID using Filter Manager… never mind.

I know that NtQueryProcessInformation for ProcessImageFileName eventually winds-up getting the name from Se… and that should be pretty bullet-proof. PIDs can definitely be reused… they’re just “handles” after all… but I’m not convinced that something more subtle isn’t at play here.

Peter

Thanks Peter. I haven’t had a chance to debug it more closely yet. Once I know more, I’ll comment again

I finally tracked this down today. It was a bug in our code causing the erroneous process name mismatch reports.

Thank you for circling back to let us know the root cause.
Peter