Hello list!
I'm currently looking into the way in which _FILE_OBJECTS are created and handled by
Windows 7, and I'm a little bit confused over something I've observed.
When using notepad.exe to open a file, a file handle to the opened file never seems to get
added to the object table within the _EPROCESS structure (monitored using
SystemInternal's ProcExplorer). I believe this is because notepad does not leave the
handle open, it simply opens the file, reads in the data, and then closes the file,
without adding the file object to the handle table.
However, after opening the file, if I dump the memory of the system (this is being
performed on a VM), and use Volaility's filescan to scan for all _FILE_OBJECTS, I see
that there is indeed still a _FILE_OBJECT associated with the file I opened. However
it's handle count is zero.
This makes sense, as with a handle count of zero, it shouldn't be listed in any of the
handle tables for any processes. However, it's pointer, or reference count is still
valid, often having 16 pointers.
My question is this, if the handle count is zero, but the pointer/reference count is still
valid, where is this _FILE_OBJECT actually being stored? Is there some kind of
kernel-based list/table that holds these open references? Or is this _FILE_OBJECT just
floating around in some kind of cache, waiting to be destroyed?
Any input or advice would be greatly appreciated.
Thanks