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

Home NTDEV
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/


Best way to deal with user handle after process die.

_Lost_bit__Lost_bit_ Member Posts: 18

Hi,

In our driver we need to inform user of certain events in the kernel driver, so the user creates a handle, proceed to send it to kernel via IOCTL, then in kernel mode we use ObReferenceObjectByHandle to get our kernel handle linked to the user one, then at the event we just signal the kernel one and user gets its own signaled too, this works.

How would be the best way to deal in the case that the user process die? how I can know if the handle is still valid? tracking the process id? we need to support multiple users so we don't like the idea of creating many handles, if some of the current handles is stale, we would like to we use it, but how can we know?

First option for me would be to use ObDereferenceObject and then ObReferenceObjectByHandle again, if the call fails, the handle is not longer valid and I can flag it as stale for reuse.

Second option, track the process Id from the IOCTL and check if the process is still alive, but doesn't feel good to track user pids.

I know there should be a clean and elegant way to deal with such cases.

Thanks in advance.

Comments

  • Pavel_APavel_A Member Posts: 2,739

    I know there should be a clean and elegant way to deal with such cases.

    Yep. One of "you", who designed this problematic interface should step out and explain why he/she hasn't just used the good old inverted calls.

    -- pa

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,525
    Pavel’s response is the right answer. Use an inverted call model and don’t mess with handles. WRT to your specific question, once you successfully call ObReferenceObjectByHandle the first time, the returned event pointer is valid until you ObDeref it. Your outstanding reference keeps the pointer valid beyond the lifetime of the sending process (again, until you drop the ref).
    d
  • _Lost_bit__Lost_bit_ Member Posts: 18

    Thanks for the replies. The concept of inverted calls is an IOCTL waiting for completion basically? Like user sending the IOCTL and Kernel holding the response until the desired event happens?

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,525

    Yes. The inverted call model provides your application the event to wait on AND it can provide and output buffer when the event is signaled in the completed IO request.

    d
  • _Lost_bit__Lost_bit_ Member Posts: 18

    This looks interesting, because we have already the IOCT (to send the user Handle address). Ok abusing of your kindness, just one more question.

    If Kernel is holding the IOCTL, what happens if the user wants to end the application? Or what if there is a segmentation fault in the application? The app cannot be done until Kernel releases the IOCTL right? Maybe I am misunderstanding something. Thanks once again.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,525

    Once it sends the IO request, the application has two choices: wait for it to complete or cancel it (usually the cancel comes after a timeout or another condition occurs). When the application exits, either normally or by crashing, the IO manager in the kernel will attempt to cancel all outstanding IO requests. This means you must support cancel in the driver. In WDF this is easy. For your pattern, when you receive the IOCTL you forward the request onto a manual WDFQUEUE. And when you want to complete the IOCTL later you remove it from the queue. While the request is parked in the manual WDFQUEUE it is cancelable and WDF handles all the cancelation logic. This has been covered by many articles and samples, start here.

    d
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,627

    If the application ends or crashes, the system will automatically flag a cancel request on all outstanding IRPs. Assuming the driver is well-written and/or uses KMDF, the driver will by notified of the cancellation request and will complete the IRPs. When the last IRP completes, the system can close the file handle.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • _Lost_bit__Lost_bit_ Member Posts: 18

    The driver is WDM actually, let me research how to handle that case in WDM drivers.

    Thank you both, very useful. I'll implement a POC of this and get back if I have more questions.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,525

    You should not implement cancel support from scratch in your driver. Best bet is to port to WDF. Next best alternative is to use an IoCSQ in a WDM driver, https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iocsqinitializeex

    d
  • _Lost_bit__Lost_bit_ Member Posts: 18

    @Doron_Holan said:
    You should not implement cancel support from scratch in your driver. Best bet is to port to WDF. Next best alternative is to use an IoCSQ in a WDM driver, https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iocsqinitializeex

    Unfortunately this is not an option, is a very large and very old driver, let me take a look at the IoCSQ, thank for the info once again.

  • MBond2MBond2 Member Posts: 196

    You should consider this carefully. the reason why migrating to KMDF is recommended is that rewiring and porting a whole driver over is less work that properly supporting cancel for most drivers

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!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE