Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
Already found out what was wrong - Don't have an open reference to any instance when you want the filter to unload ... makes sense
Hello everyone!
I'm programming a real-time File Mirror infilter and the automatic cleanup of file contexts is giving me a Headache.
This is my Situation right Now:
PCOPY_MANAGER_THREAD_OBJECT CopyThread; PFLT_INSTANCE MirrorInstance; PFILE_OBJECT MirrorFileObject; HANDLE MirrorFileHandle; USHORT ReferenceCount;
The File_Objects and Handles all are Open and ready to be used.
void FileMirrorFileContextCleanup( PFILEMIRROR_FILE_CONTEXT Context, FLT_CONTEXT_TYPE ContextType ) { ConsolePrint( "Cleaning Context from File" ); UNREFERENCED_PARAMETER( ContextType ); if(Context->MirrorFileObject != NULL) { ObfDereferenceObject( Context->MirrorFileObject ); } if(Context->MirrorFileHandle != NULL) { FltClose( Context->MirrorFileHandle ); } if(Context->MirrorInstance != NULL) { FltObjectDereference( Context->MirrorInstance ); } }
Now - Microsoft Docs state:
"the filter manager deletes contexts automatically [...] when the minifilter driver is unloaded."
https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/deleting-contexts
But when I unload my Filter the Context Cleanup wont get called.
I guess it's because the Filter still has the Handles inside the Context open and wont go to the next step before they are closed?
For Reference, here is the output of !fltkd.filters xx 8 1
The References are as planned:
Object usage/reference information: References to FLT_CONTEXT : 0 Allocations of FLT_CALLBACK_DATA : 0 Allocations of FLT_DEFERRED_IO_WORKITEM : 0 Allocations of FLT_GENERIC_WORKITEM : 0 References to FLT_FILE_NAME_INFORMATION : 0 Open files : 1 References to FLT_OBJECT : 0 List of objects used/referenced:: FLT_VERIFIER_OBJECT: ffff9a86f7b1e6f0 Object: ffff9a86f92af650 Type: FILE_OBJECT RefCount: 00000001
The FILE_OBJECT is the referenced File from the file context
Does anyone have any Input on this topic? Maybe I'm thinking wrong? Maybe there is a way to force Cleanup the contexts?
For now I'm just planning on building a list with all open contexts so I can delete them Manually - Is there maybe a way how I could get this from the Filter manager?
(Quick side question -
I'm getting frequent timeouts in the "Gathering kernel debugger settings" task for remote debugging.
I'm using Network debugging on a local VM. Anyone got a clue how to counter that? maybe set the timeout a bit higher? seems to be like 2 secs or so.)
Best Regards,
Aaron K
Aaron Kelbsch
Techit GmbH @ Germany
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 | 12 September 2022 | Live, Online |
Internals & Software Drivers | 23 October 2022 | Live, Online |
Kernel Debugging | 14 November 2022 | Live, Online |
Developing Minifilters | 5 December 2022 | Live, Online |
Comments
SOLUTION
Ok! So I Actually found out my Problem.
Forget everything I wrote.
I kept an open reference to the Filter Instance of the FileObject I used.
This seemed to be what caused the Cleanup to never trigger.
I changed it before I posted, but...
the console I used didn't show that it successfully unloaded my driver until I happened to press enter again.
So, Yay, problem which cost me around 3 days is solved.
Aaron Kelbsch
Techit GmbH @ Germany