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/
Let's say I want to inspect every FILE_OBJECT for a specific path (file or folder), such as \Systemroot\Windows or \Device\HarddiskVolume3\Windows.
Is there any possible way to do this using windbg? Or printing every FILE_OBJECT (that is still active) on the machine?
I need to find if some certain files are causing a kernel mode reference leak or not, and if possible find the faulty driver.
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! | ||
Kernel Debugging | 16-20 October 2023 | Live, Online |
Developing Minifilters | 13-17 November 2023 | Live, Online |
Internals & Software Drivers | 4-8 Dec 2023 | Live, Online |
Writing WDF Drivers | 10-14 July 2023 | Live, Online |
Comments
What's the failure scenario?
You can find all File Objects with active handles by using "!handle 0 3 0 File". If there are no handles then you could try enabling object tracking and then dumping with "!object 0 File"
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/maintain-a-list-of-objects-for-each-type
But in either case you're just going to know that there is a File Object, but not necessarily who owns it or created it.
-scott
OSR
If I recall correctly, a FILE_OBJECT is created for every usermode (CreateFile) or kernelmode (ZwCreateFile, FltCreateFile) handle that is opened on the target file, Correct? So if there is no open handle on a particular file, I assume I can't find any FILE_OBJECT for that file right?
Objects have both handle and reference counts, so just because there are no handles doesn't mean that there are no objects. That's what the object tracking option is for.
-scott
OSR
So let's say I have a file or folder like
\Systemroot\Windows
, what is the proper command to use to find every FILE_OBJECT (if any) of this file? Do I have to look through the entire output of!handle 0 3 0 File
?Also another side question: In Linux kernel, there is a
inode
struct which represent each file (no matter the open handles), and then there's afile
structure that represents an open file descriptor (similar to FILE_OBJECT), Is there anything similar toinode
struct in Windows? Or if a file is not opened by anyone, then there's no structure that is representing it? (Not talking about the structure that the underlying filesystem driver is using, but the structure that kernel itself is using no matter the underlying filesystem)Well, inodes in Linux live on disk. A filesystem that doesn't have the concept has to simulate them. There is no such file-system-independent structure in Windows, because it does not have the same universal namespace concept. All you get is the FILE_OBJECT. If a file is not opened, then the kernel doesn't need to refer to it.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
I'm not sure this helps with your question but I just wanted to clarify something:
The Windows equivalent to an in memory inode is the File Control Block (FSRTL_ADVANCED_FCB_HEADER) and is stored in the FsContext field of the FILE_OBJECT. So, for example, two File Objects to the same file on disk will have the same FsContext value*. It is the job of the File System to maintain this field as it's the only one that really knows.
Note that this structure only exists in memory for as long as there is a File Object around that references it. When a file is memory mapped (or used for cached I/O) the Memory Manager will reference one of the File Objects used and keep it around long after the application closes the HANDLE. These references will only ever go away when there's sufficient memory pressure on the machine or you do something like delete the file.
*It gets more complicated for NTFS because there we support multiple streams per-file. So, NTFS creates its own structure called the Stream Control Block and puts that in FsContext. However, because of the way the OS works the Stream Control Block still starts with an FSRTL_ADVANCED_FCB_HEADER structure).
-scott
OSR