From: SMTP%"Scott.Johnson@seagatesoftware.com" 22-SEP-1997 16:55:31.49 To: "'ntfsd@atria.com'" CC: Subj: RE: Creating files in Kernel Mode Return-Path: owner-ntfsd@atria.com Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Mon, 22 Sep 1997 16:53:51 -0400 Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by bort.mv.net (8.8.5/mem-951016) with SMTP id NAA23338 for ; Mon, 22 Sep 1997 13:55:12 -0400 (EDT) Received: by gw.atria.com id Mon, 22 Sep 1997 09:51:06 -0400 Received: from lmoxch03.smg.seagatesoftware.com by gw.atria.com id Mon, 22 Sep 1997 09:51:02 -0400 Received: by lmoxch03.smg.seagatesoftware.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCC73C.E7030030@lmoxch03.smg.seagatesoftware.com>; Mon, 22 Sep 1997 09:50:04 -0400 Message-ID: From: Scott Johnson To: "'ntfsd@atria.com'" Subject: RE: Creating files in Kernel Mode Date: Mon, 22 Sep 1997 09:53:57 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ntfsd@atria.com Precedence: bulk Dave wrote and I responded (see below), but I just wanted to add something that I found over the weekend. My filter "hooks" file opens and in some cases will "close" a file in an Io completion routine established by my Create handler. I "close" files by issuing a CLEANUP irp followed by a CLOSE irp and then returning (and setting in Iosb) an appropriate file open failure code. From the caller's perspective their file open attempt fails ... they don't know my completion routine failed the open. I noticed that if I just issue CLEANUP and CLOSE irps and return appropriate failure status, everything appears to work ok; however, if I ObDereferenceObject() the file object in addition to CLEANUP and CLOSE the system crashes. By the way, I know I can issue a CLOSE irp because I can ensure that nobody else has the file open at the time (not directly ... I can ensure this simply by the nature of the program so to speak - long story). My question is this: Who cleans up/destroys the file object if I don't call ObDereferenceObject() on the file object? Does the I/O manager normally destroy/release the file object if the original create irp was failed? Is there a way to determine an object's reference count (there is probably an obvious and documented function for this purpose...)? >---------- >From: Scott Johnson >Sent: Saturday, September 20, 1997 10:45 AM >To: 'ntfsd@atria.com' >Subject: RE: Creating files in Kernel Mode > >Dave, > >Disclaimer: I am by no means very experienced in this area of I/O >processing. But I thought I'd pass along what little I know (or think >I know). > > >First, what happens to the handle created by ZwCreateFile()? You call >ObReferenceObjectByHandle() which bumps the object's reference count and >then call ObDereferenceObject() which decrements the object's reference >count; thereby, leaving the reference count whatever it was before >ObReferenceObjectByHandle() was called (presumably one, due to the >ZwCreateFile() call). > >After calling ObDereferenceObject(), you apparently still have a valid >handle associated with some thread (thread1) and a File Object with a >reference count of at least one. If I follow your message correctly, >you then issue CLEANUP and CLOSE irps. However, I don't think you can >issue the CLOSE when there are outstanding file handles open. The CLOSE >results in "final" deletion of state info associated with the file >object (CLEANUP cleans up state - FSD releases cache maps, locks, etc. >... CLOSE deletes state info - deletes related context info, FCB, etc.. >No, I do not know all of the differences or details). When thread1 >terminates, I think the I/O manager will send another CLEANUP because >the ZwCreateFile() handle is still "open". (This CLEANUP would probably >be followed by a CLOSE irp, under normal circumstances.) Since you have >already issued the CLOSE, state info has been deleted and the subsequent >CLEANUP results in the FSD trying to cleanup state using "deleted state >info"... that might be why crash occurs. > >Regarding #2 (using ObOpenObjectByPointer): >This tactic apparently generates a second file handle - the one >generated by ZwCreateFile() being the first handle. Closing the second >handle will not close the first handle, hence, the file remains open. > >>---------- >>From: Dave Burdette[SMTP:burddc@ibm.net] >>Sent: Friday, September 19, 1997 4:30 PM >>To: ntfsd@atria.com >>Subject: Creating files in Kernel Mode >> >>I've seen quite a bit of traffic on using ZwCreateFile from a Kernel mode >>driver, but I haven't seen anything that addresses closing the files. >> >>I have a FS filter driver that needs to create files and close them in >>different threads. I've tried a few methods, none that works correctly. >> >>The file is opened with ZwCreateFile. I then call ObReferenceObjectByHandle >>to get a FILE_OBJECT which is used to read & write to the file via IRPs. I >>also call ObDereferenceObject to restore the reference count. >> >>To close the file : >> >>1) Sending IRP_MJ_CLEANUP & IRP_MJ_CLOSE. This results in a crash as the >>dirty page writer tries to flush the cache after the file is closed ( I >>think that's the cause. ) >> >>2) ObOpenObjectByPointer to get a HANDLE from the FILE_OBJECT, then >>ZwClose. This seems to work ( no crash ), but the file is left open. >> >>Does anybody have any ideas on how this should be done ?? The key is that >>I can't just use the HANDLE from ZwCreateFile due to thread switches. >> >> >>Thanks, >>Dave Burdette >> >> >