Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


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

rstruempfrstruempf Member Posts: 103

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?

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,120

    Probably not but...

    • Might KeStackAttachProcess be implicated
    • Might you be being called inside the context of a ProcessNotify callback?
  • rstruempfrstruempf Member Posts: 103

    @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?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,802

    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
    @OSRDrivers

  • rstruempfrstruempf Member Posts: 103
    edited April 2019

    @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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,802

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • rstruempfrstruempf Member Posts: 103

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

  • rstruempfrstruempf Member Posts: 103

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,802

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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA