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