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/


Stream context lifetime

yuval0x92yuval0x92 Member Posts: 2

Hi all,

I'm building a minifilter driver for windows 10 which uses stream contexts.
I noticed that most of my stream contexts are not freed until driver unload, or only after a few very long hours.

I'm releasing all of my references to the context, and everything seems to work fine in my end.
The IRP_MJ_CLEANUP callback is called, but the IRP_MJ_CLOSE is not called for every file object. I usually have 1/2 file objects not getting to IRP_MJ_CLOSE at a reasonable time.

I've read some posts here and I understand the reason for this is unreleased references to the stream by the cache manager or the memory manager.
I tried to purge the cache in cleanup (CcFlushCache, MmFlushImageSection, CcPurgeCacheSection), and it works most of the time, but I'm looking for a better solution, maybe one that does not involve messing with the CC/MM??

My stream context is pretty big in size (few KBs), and at some point it turns into a pretty big chunk of memory...

So...
The question is: Is there a way to rush the freeing of stream contexts?
I don't want to wait hours for it to be released by the OS.

Best Regards,

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,352

    You cannot force the Cc or Mm to release the reference to the File Object. The only component that can do that is the file system. If you are calling Cc/Mm APIs in your filter driver then that's a serious bug as you don't own any of the necessary locks (unless you're an Isolation filter, which is another story).

    Use paged pool and try to minimize the size of the structure. What are you storing in there that's so large?

    -scott
    OSR

  • Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 264

    @Scott_Noone_(OSR) said:
    You cannot force the Cc or Mm to release the reference to the File Object. The only component that can do that is the file system.

    Fs does that in general or in some special cases ? Mm is a special client, but still a client. Is it ok to force it to yield it’s reference ?
    I never wrote fs or isolation filter, so probably just misunderstanding something

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,352
    edited October 8

    @Sergey_Pisarev said:

    @Scott_Noone_(OSR) said:
    You cannot force the Cc or Mm to release the reference to the File Object. The only component that can do that is the file system.

    Fs does that in general or in some special cases ? Mm is a special client, but still a client. Is it ok to force it to yield it’s reference ?
    I never wrote fs or isolation filter, so probably just misunderstanding something

    Mostly* in special cases. For example, when you try to delete a file the FS calls Mm to try and purge the Section. From FASTFAT:

        if (Buffer->DeleteFile) {
    
            //
            //  Check if the file is marked read only
            //
    
            if (FlagOn(Fcb->DirentFatFlags, FAT_DIRENT_ATTR_READ_ONLY)) {
    
                DebugTrace(-1, Dbg, "Cannot delete readonly file\n", 0);
    
                return STATUS_CANNOT_DELETE;
            }
    
            //
            //  Make sure there is no process mapping this file as an image.
            //
    
            if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
                                      MmFlushForDelete )) {
    
                DebugTrace(-1, Dbg, "Cannot delete user mapped image\n", 0);
    
                return STATUS_CANNOT_DELETE;
            }
    

    Even then it is simply the FS asking Mm to try and get rid of its reference. For example, the request could fail if the Section is in use.

    *In later versions of Windows NTFS allows a kernel mode caller to request a purge attempt (IRP_MJ_FLUSH_BUFFERS/IRP_MN_FLUSH_AND_PURGE). FltMgr even conveniently exposes it via FltFlushBuffers2. Again it's not a guarantee though and you'll kill the user experience if you're purging it all the time (caching is a good thing)

    -scott
    OSR

  • Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 264

    Thank you very much Scott !
    Always love your explanations.

    I really hope I can get osr mini filter seminar one day. Because of idiotic bureaucracy 2022 is earliest this can happen :(

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