Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
My File is being kept alive, but I don't know why
bastien_thonnat
Member Posts: 26
Hello,
Context :
Windows 8.1
Minifilter
NTFS volume
On my post IRP_MJ_CREATE callback, I create another handle by FltCreateFileEx2 with FILE_READ_ATTRIBUTES | SYNCHRONIZE, no share and OBJECT_ATTRIBUTES has OBJ_KERNEL_HANDLE.
If I close it just after the FltCreateFileEx2 everything turn well.
If i close it in the pre IRP_MJ_CLOSE callback of the original File, the system keep the file opened, and when I unload my minifilter, the file is released.
when I try !object on the FILE_OBJECT I have HandleCount: 0 PointerCount: 0
| 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 |
Comments
One assumes that the original file is cached, pinning the original FileObject, thus pinned MJ_CLOSE will never be called
I understand that someone keep one of my file, but I receive the MJ_CLOSE callback and the ref count is 0 after that, on my original FileObject and my second FileObject.
How can someone kept one file opened without reference on this file ?
This is it,
CcIsFileCached return true on my FILE_OBJECTs when the file is being kept alive by the system,
CcUnmapFileOffsetFromSystemCache can solve my issue or it's some misconception of my project ?
Opening my second HANDLE with FILE_NO_INTERMEDIATE_BUFFERING do the job.
Thank you for this hint.
rod_widdowson I think I missunderstand something,
I read this from the documentation that IRP_CLOSE thread context is arbitrary and IRP_CLEANUP is non-arbitrary,
When I close my second handle from the IRP_CLOSE of the original handle, my file is kept open,
but when I close it in the IRP_CLEANUP of the original handle, my file is closed.
The documentation of FltClose say that it should not be used to close arbitrary handle.
The term arbitrary in arbitrary handle is the same as arbitrary in arbitrary thread context ?
Can't I close handle with FltClose in arbitrary context ?
Good point. I had assumed (because its hard not to) that this is a kernel handle you are opening. (
OBJ_KERNELflags toInitializeObjectAtttributes) That has to happen.Beyond that I still don't completely understand whether it is the
MJ_CLOSE(of the first file) that is not happening (which could be because of caching) or the fact that if you theFltCloseyou issue doesn't work (which could be the handle type)Yes I create my second with OBJ_KERNEL in InitializeObjectAtttributes,
In fact I see the two MJ_CLOSE.
When the file is not cached (CcIsFileCached return false), after the MJ_CLOSE, my file is closed.
When the file is cached, after the MJ_CLOSE, my file is opened, but not by me.
If I understand the FileSystem correctly, when the MJ_CLEANUP occur the CacheManager Flush the unwritten cache on the disk.
It is possible that if I close my OBJ_KERNEL handle in MJ_CLOSE with arbitrary context, this context is used in the MJ_CLEANUP (which need non arbitrary context) and the CacheManager hang on the Flush ?
I think the problem occur in the CacheManager, because my minifilter don't leak anything, don't hang on DriverUnload and when it's unloaded, the FileObject I don't own is released.
Oups sorry, I don't see the MJ_CLOSE for the kernel handle, my bad...
My ref count == 0, but the FileObject is not released correctly
WHICH reference count? You know that there's an object pointer reference count and a count of open handles -- and they are separate, right?
Peter
Peter Viscarola
OSR
@OSRDrivers
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
@Peter_Viscarola_(OSR) Both.
@Peter_Scott Why ? Is there specific behavior in closing the shadow file in MJ_CLOSE of the upper file ? I see there is a difference, but I don't understand why.
If I think correctly,
It's not impossible to see the MJ_CLOSE after a long time if the CacheManager keep the Section in cache for future use (pointer reference != 0),
but when I close the HANDLE, the MJ_CLEANUP is triggered immediately (handle count == 0).
But in my case the pointer ref == 0 and handle count == 0.
So I expect to see MJ_CLEANUP and MJ_CLOSE.
I see both when I release my Shadow file in the MJ_CLEANUP of the upper file.
I don't see MJ_CLOSE of my Shadow file when I release it in the MJ_CLOSE of the upper file.
Again, I have implemented many layered file systems where this rule does not apply, it depends on your design.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Okay I understand that now, I will try this way in my project
Thank you for all guys