{"id":246,"date":"2008-01-09T20:50:58","date_gmt":"2008-01-09T20:50:58","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2008\/01\/09\/cleanup-and-close\/"},"modified":"2026-07-27T20:44:45","modified_gmt":"2026-07-27T20:44:45","slug":"cleanup-and-close","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2008\/01\/09\/cleanup-and-close\/","title":{"rendered":"CLEANUP and CLOSE"},"content":{"rendered":"
\"\"<\/a><\/div>\n

I have written a post<\/a> that describes the steps of how to create a simple driver. This driver simply keeps a list of strings it receives via writing IRPs and returns them via reading IRPs. Well, if you do not know what an IRP is, another post<\/a> tries to explain what they are and even describes the needed steps to use the IRP Tracker<\/a> to observe the IRPs coming and going. If we do a little test using the IRP Tracker<\/strong> on the sample driver that I have just commented, we will have an output similar to the figure below.<\/p>\n

\"\"
<\/div>\n

We can see all the IRPs that our device has received from IRP_MJ_CREATE<\/a> to IRP_MJ_CLOSE<\/a>. Among these IRPs, we can notice that some of them were not completed successfully. Because no routine has been designed to treat IRP_MJ_CLEANUP<\/a>, these IRPs are completed with STATUS_INVALID_DEVICE_REQUEST. In this post I’m going to talk a little about this IRP and how your device interacts with the processes which have obtained a handle for it.<\/p>\n

To see the IRP details, double-click on the IRP line of the IRP Tracker<\/strong> so that the window below can appear. In this window you can see, among the other details, the FileObject<\/a> used in the IRP. This is helping us in this post during the tests.<\/p>\n

\"\"<\/div>\n

When does an IRP_MJ_CLEANUP take place?<\/h3>\n

The Object Manager<\/a> sends an CLEANUP <\/em>IRP in order to notify the driver that the last handle for a given FileObject<\/em> has been closed. As some of you may know, when an application uses CreateFile()<\/a> to get a handle to our device, this results in a FileObject<\/strong> creation. The subsequent operations using this handle will be linked to this FileObject<\/em>. More details about this are going to be found in this post<\/a>.<\/p>\n

A FileObject<\/em> does not have a direct relation with a handle. A handle might be duplicated or even inherited from the parent process on creating a new process. The result of these actions is having multiple handles to be translated into the same FileObject<\/em>. Thus, not always when an application calls the CloseHandle<\/a> function, a CLEANUP<\/em> or CLOSE <\/em>IRP is sent to the driver.<\/p>\n

To follow the steps below, the sample program source code will be available for downloading at the end of this post. This program uses the example driver that have been built in another post<\/a>; the driver source code can be downloaded from here<\/a>. From the sources, you can compile and install the test driver. If you do not know how to do this, this post<\/a> can help you. After installing the test driver, it would be interesting to execute the calls below with the help of a debugger, and thus, be able to observe the results on the IRP Tracker<\/strong> for ever executed line.<\/p>\n

It’s important to read the source comments below. I got lazy to duplicate this information here in the post.<\/p>\n

\n
\/****<\/span><\/pre>\n
***     main<\/span><\/pre>\n
**<\/span><\/pre>\n
**      I hope that everyone know this is the<\/span><\/pre>\n
**      application entrypoint. Otherwise,<\/span><\/pre>\n
**      you might be precipitaded on reading a<\/span><\/pre>\n
**      Windows driver blog.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
int<\/span> main(int<\/span> argc, char<\/span>* argv[])<\/pre>\n
{<\/pre>\n
    HANDLE  h1, h2, h3;<\/pre>\n
    CHAR    szBuffer[100<\/span>];<\/pre>\n
    DWORD   dwBytes;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we are opening the first handle<\/span><\/pre>\n
    \/\/      to our device. That is the step 1<\/span><\/pre>\n
    \/\/      on the IRP Tracker. Check out the FileObject<\/span><\/pre>\n
    \/\/      value so that you can compare it in<\/span><\/pre>\n
    \/\/      future requests.<\/span><\/pre>\n
    h1 = CreateFile(\"\\\\\\\\.\\\\EchoDevice\"<\/span>,<\/pre>\n
                    GENERIC_ALL,<\/pre>\n
                    0<\/span>,<\/pre>\n
                    NULL,<\/pre>\n
                    OPEN_EXISTING,<\/pre>\n
                    0<\/span>,<\/pre>\n
                    NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we are opening the second handle<\/span><\/pre>\n
    \/\/      to our device. That is the step 2<\/span><\/pre>\n
    \/\/      on the IRP Tracker. Check out the FileObject<\/span><\/pre>\n
    \/\/      value so that you can compare it in<\/span><\/pre>\n
    \/\/      future requests.<\/span><\/pre>\n
    h2 = CreateFile(\"\\\\\\\\.\\\\EchoDevice\"<\/span>,<\/pre>\n
                    GENERIC_ALL,<\/pre>\n
                    0<\/span>,<\/pre>\n
                    NULL,<\/pre>\n
                    OPEN_EXISTING,<\/pre>\n
                    0<\/span>,<\/pre>\n
                    NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we are throwing an IRP_MJ_READ for the<\/span><\/pre>\n
    \/\/      first FileObject we have gotten. Step 3 on<\/span><\/pre>\n
    \/\/      IRP Tracker. Notice that the first FileObject<\/span><\/pre>\n
    \/\/      is going to be used in this IRP.<\/span><\/pre>\n
    ReadFile(h1,<\/pre>\n
             szBuffer,<\/pre>\n
             sizeof<\/span>(szBuffer),<\/pre>\n
             &dwBytes,<\/pre>\n
             NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we are throwing an IRP_MJ_READ for the<\/span><\/pre>\n
    \/\/      second FileObject we have gotten. Step 4 on<\/span><\/pre>\n
    \/\/      IRP Tracker. Notice that the second FileObject<\/span><\/pre>\n
    \/\/      is going to be used in this IRP.<\/span><\/pre>\n
    ReadFile(h2,<\/pre>\n
             szBuffer,<\/pre>\n
             sizeof<\/span>(szBuffer),<\/pre>\n
             &dwBytes,<\/pre>\n
             NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> The handle duplication is not notified<\/span><\/pre>\n
    \/\/      to the driver. Only Object Manager \"has known\"<\/span><\/pre>\n
    \/\/      about that. There isn't any corresponding<\/span><\/pre>\n
    \/\/      step on IRP Tracker.<\/span><\/pre>\n
    DuplicateHandle(GetCurrentProcess(),<\/pre>\n
                    h1,<\/pre>\n
                    GetCurrentProcess(),<\/pre>\n
                    &h3,<\/pre>\n
                    0<\/span>,<\/pre>\n
                    FALSE,<\/pre>\n
                    DUPLICATE_SAME_ACCESS);<\/pre>\n
 <\/pre>\n
    \/\/-f--> As the third handle was goten from the<\/span><\/pre>\n
    \/\/      first handle duplication, the corresponding<\/span><\/pre>\n
    \/\/      FileObject is the same as the first handle.<\/span><\/pre>\n
    \/\/      Step 5 on IRP Tracker. Notice that the first<\/span><\/pre>\n
    \/\/      FileObject is going to be used on this IRP.<\/span><\/pre>\n
    ReadFile(h3,<\/pre>\n
             szBuffer,<\/pre>\n
             sizeof<\/span>(szBuffer),<\/pre>\n
             &dwBytes,<\/pre>\n
             NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Because we have two handles for the first FileObject,<\/span><\/pre>\n
    \/\/      closing one of them will not gererate any notification<\/span><\/pre>\n
    \/\/      to our device. There isn't any corresponding step<\/span><\/pre>\n
    \/\/      on IRP Tracker.<\/span><\/pre>\n
    CloseHandle(h1);<\/pre>\n
 <\/pre>\n
    \/\/-f--> That handle has not been duplicated, thus, when it is closed,<\/span><\/pre>\n
    \/\/      an IRP_MJ_CLEANUP followed by an IRP_MJ_CLOSE are going to be<\/span><\/pre>\n
    \/\/      sent to the driver. Step 6 on IRP Tracker.<\/span><\/pre>\n
    CloseHandle(h2);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Closing that handle, we will have the same behavior<\/span><\/pre>\n
    \/\/      seen during the h2 closing. From the driver<\/span><\/pre>\n
    \/\/      viewpoint, the first FileObject will be destroyed<\/span><\/pre>\n
    \/\/      now. Step 7 on IRP Tracker.<\/span><\/pre>\n
    CloseHandle(h3);<\/pre>\n
 <\/pre>\n
    \/\/-f--> And they have all lived happy ever after.<\/span><\/pre>\n
    return<\/span> 0<\/span>;<\/pre>\n
}<\/pre>\n<\/div>\n
Getting a handle to an object assures us that this object will be valid until we close this handle. An object can only be destroyed by the system after all handles to it are closed. For this, the Object Manager<\/em> maintains two counters, ProcessHandleCount<\/strong> and SystemHandleCount<\/strong>. The first one keeps the amount of open handles to an object in a given process. The other one maintains the sum of all ProcessHandleCount<\/em> for the object in the system. These counters are decremented as these handles are closed. When they reach zero, a IRP_MJ_CLEANUP is generated.<\/p>\n
Usually an IRP_MJ_CLEANUP serves us as an event to cancel any asynchronous operation on the FileObject<\/em> which is being finalized. These IRPs are linked to the threads that have launched them and any asynchronous IRP should be cancelled at this time.<\/p>\n
But what is IRP_MJ_CLOSE used for?<\/h3>\n
Besides the reference counters above mentioned, there is also the ObjectReferenceCount<\/strong> which, besides being incremented when a new handle is obtained, it is also incremented when a reference is made using kernel functions like ObReferenceObject()<\/a>, for example. These calls increment the ObjectReferenceCount<\/em> without a new handle being generated. For those who have known COM<\/a>, this call has the similar behavior to AddRef()<\/a>. This allows the object to remain valid itself for the kernel, even after all handles to it have been destroyed. Anyway, when this counter reaches zero, then the IRP_MJ_CLOSE is sent.<\/p>\n
A driver can associate data structures for a given FileObject<\/em> using the FsContext and FsContext2 pointers according to what I had  discussed in another post<\/a>. These structures can only be deallocated when the driver receives the IRP_MJ_CLOSE.<\/p>\n
Operations after IRP_MJ_CLEANUP<\/h3>\n
When the driver receives an IRP_MJ_CLEANUP, it does not mean that the end is near. Other kernel components can still launch new IRPs for reading or writing, even after this event. Not to mention the IRP_MJ_INTERNAL_DEVICE_CONTROL<\/a> that can be exchanged among drivers.<\/p>\n
A very common scenario at the File Systems development is precisely about a reference to a FileObject<\/em> that is maintained by the Cache Manager<\/strong>. Even when all handles are closed by the applications, the system still retains this refrence anticipating that some application may want to open the same file again. The Cache Manager<\/em> has some system threads<\/em> that perform the so-called “delayed writing”<\/em>. This feature retains many writes to a file in a single operation aftermost in order to reduce the number of disk accesses, thus gaining performance. It is too often such writings taking place, once the file had all of its handles closed for applications, and then, these data being written after IRP_MJ_CLEANUP.<\/p>\n
In the end of it all, I hope to once again have helped more than hindered. Issues regarding the Cache Manager<\/em>, Memory Manager<\/em> and File Systems<\/em> are not very trivial, but they are interesting enough to be read about and understand what the system has done before saying that everything is crap.<\/p>\n
Until next time!<\/p>\n
TestCleanup.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
I have written a post that describes the steps of how to create a simple driver. This driver simply keeps a list of strings it receives via writing IRPs and returns them via reading IRPs. Well, if you do not know what an IRP is, another post tries to explain what they are and even […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-246","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/246","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=246"}],"version-history":[{"count":2,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/246\/revisions"}],"predecessor-version":[{"id":298,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/246\/revisions\/298"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=246"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=246"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=246"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}