Hi,
I’m stuck trying to figure out why my shadow file object is not released, causing issues when accessing the file again.
In my minifilter driver I open the SFO on PreCreate operation, swap pointers on all requests.
On cleanup I close the file handle and, on IRP_MJ_CLOSE, I dereference the FILE_OBJECT, FLT_VOLUME and FLT_INSTANCE objects I store in my custom FCB.
Also I call CcInitializeCacheMap and CcUninitializeCacheMap for the main FILE_OBJECT (not the shadow one)
The minifilter “sees” the cleanup and close events and WinDbg does not show any useful information using !fltkb.filter XXX except for some “unknown” objects.
Regards,
Mauro.
How do you know it is the Cache Manager holding the reference? It might be the memory manager (for example), in which case you’d have to purge or force the section closed to make the file object go away.
What are the “issues” that you see?
Tony
OSR
Hi Tony. Yes may be the memory manager too.
What I see is:
a) If I try to open the file again, I get a STATUS_SHARING_VIOLATION or STATUS_DELETE_PENDING (if I tried to delete the file) in the FltCreateFileEx call.
b) Doing a !fltkd.filter, this is the output
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 : 2
List of objects used/referenced::
FLT_VERIFIER_OBJECT: fffffa80261a75d0
Object: fffffa80264b9010 Type: (null) RefCount: 00000001
FLT_VERIFIER_OBJECT: fffffa80261a0540
Object: fffffa80264e0010 Type: (null) RefCount: 00000001
FLT_VERIFIER_OBJECT: fffffa8027bbf2f0
Object: fffffa802780bf20 Type: FILE_OBJECT RefCount: 00000001
dt nt!_FILE_OBJECT fffffa8027bbf2f0
+0x000 Type : 0n-3344
+0x002 Size : 0n10171
+0x008 DeviceObject : 0xfffffa80261a0540 _DEVICE_OBJECT +0x010 Vpb : (null) +0x018 FsContext : 0xfffffa80261d0fc0 Void
+0x020 FsContext2 : 0xfffffa802780bf20 Void +0x028 SectionObjectPointer : (null) +0x030 PrivateCacheMap : 0xfffffa8000010000 Void
+0x038 FinalStatus : 0n5
+0x040 RelatedFileObject : 0xfffffa802780bf20 _FILE_OBJECT +0x048 LockOperation : 0x1 '' +0x049 DeletePending : 0 '' +0x04a ReadAccess : 0 '' +0x04b WriteAccess : 0 '' +0x04c DeleteAccess : 0 '' +0x04d SharedRead : 0 '' +0x04e SharedWrite : 0 '' +0x04f SharedDelete : 0 '' +0x050 Flags : 0x2170006 +0x058 FileName : _UNICODE_STRING "--- memory read error at address 0x0000018000000400 —"
+0x068 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x070 Waiters : 0
+0x074 Busy : 0
+0x078 LastLock : (null)
+0x080 Lock : _KEVENT
+0x098 Event : _KEVENT
+0x0b0 CompletionContext : 0x0000000000000002 _IO_COMPLETION_CONTEXT +0x0b8 IrpListLock : 1 +0x0c0 IrpList : _LIST_ENTRY [0x0000000000000000 - 0x00000000400d001c] +0x0d0 FileObjectExtension : 0xfffffa80274136c0 Void
I print the addresses of the main FILE_OBJECT and the shadow one in each operation but those entries doesn’t belong to me.
I removed all “Cc” calls I did (just in case but they target only the original requested file_object) without success.
Thanks Tony.
There are two paths where you can get STATUS_SHARING_VIOLATION here:
* If the lower file object has not been cleaned up (sharing only applies as long as the file itself has outstanding handles. Look at FastFAT and you can see how it removes the sharing information in the IRP_MJ_CLEANUP handler.
* If the file is still mapped, either as a data file (with writeable sections) or execution and the caller is trying to open the file with incompatible access (again, you can see this in FastFat).
OK, now to your actual data:
This file indicates that caching has been enabled on it. However, the shared cache map field is NULL. This is odd. When you call CcUnitializeCacheMap do you wait for it to complete? Uninitialize should not be returning with the private cache map field still set.
Since the cache is enabled, it sure looks like this file is still open. But it has no SOP, which is odd. Bottom line: something is wrong here. I can’t tell you from what you’re showing here, but I can tell you that this isn’t a reasonable state for the file object. Review your uninit code.
Tony
OSR
Hi Tony,
I don’t understand the following: I open the shadow file and save file handle and object pointer. On cleanup I close the handle, on close, dereference the object pointer.
I did this test: Loaded the driver, changed to my redirected folder (CD in a CMD window) and executed a DEL file.txt
Added more debug output to see the leak. The result is:
a) The parent folder is opened (well the file is opened with SL_OPEN_TARGET_DIRECTORY flag)
b) The file itself is opened three times, processed, on last open, it is marked for deletion, then cleanup and close are called.
c) The parent folder receives a query for FileStandardLinkInformation and then never receives the IRP_MJ_CLEANUP nor IRP_MJ_CLOSE.
Should I do some special handling in the original FILE_OBJECT with SL_OPEN_TARGET_DIRECTORY? I handle the FltGetFileNameInformation and then I do the FltCreateFileEx
Two things I don’t understand:
a) Why the parent folder is not closed?
b) Why, if the parent folder is opened, the fail comes when accessing the file.txt directly (i.e. open with notepad)
Kind regards and thanks for all the help you are giving me,
Mauro.
> a) Why the parent folder is not closed?
Is it a current directory for some process?
In Windows, the notion of the current directory is user-mode only, implemented by joint effort of kernel32.dll and ntdll.dll.
The process always has a string path to its current directory, and holds an open handle for it. kernel32.dll uses this handle as RelatedFileObject for relative pathnames.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi Maxim,
No, it isn’t. Altough I doubt why I see the open/cleanup/close for the file.txt file but still listed when I exec a DIR command and get the STATUS_DELETE_PENDING error if I try to access the file.
Regards,
Mauro.
Hi again,
A review of the issues:
a) CMD -> del file.txt. Create/QueryInfo/SetInfo/Cleanup/Close occurs in the same way like any other file but when accessing again I get the STATUS_DELETE_PENDING error.
b) Create a non-existing file with notepad. File is created but later not accessible.
Trying to minimize the scope of the issues I’m having. I found the files are closed. The handle and the FILE_OBJECT has a reference count of one and they are dereferenced properly.
Seems another kernel module opened the file by some reason but I’m unable to track them. To be honest I don’t know how to continue because the _FSRTL_ADVANCED_FCB_HEADER structure pointed by FsContext does not gives me some shared information I can lookup.
Any hint on how to continue?
Thanks.