Thanks Peter,
This is another excellent reply which I shall file away for future
reference, I still have a sneaky feeling that I am not doing something quite
right somewhere but it is all holding together today, so I am going to put
on my Peril Sensitive Sunglasses and carry on. If the bug bites I will come
back to what you have written here.
You have confirmed that I was dereferencing once too many at one point which
I have now fixed.
Thanks
Alasdair
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: 07 October 2004 15:35
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Page Fault
1 - you shouldn’t send an IRP_MJ_CLOSE yourself. Let the I/O manager do
that.
2 - ObDereferenceObject reduces the reference count on the object. if that
count goes to zero, the object manager will delete the object. When it does
this, it calls an I/O manager routine which first sends an IRP_MJ_CLOSE IRP
to the stack. The IRP_MJ_CLOSE request notifies the driver that the file
object is going to be deleted so the driver can clean up.
if C++ terms help, ObDereferenceObject is like the delete operator (except
for the reference counting) and the driver’s IRP_MJ_CLOSE is the destructor.
(this is a simplifcation … the Object Manager may queue the deletion of
the object and process it in a worker thread, but that doesn’t really affect
you much)
3 - If the reference count goes to zero then the object could be destroyed.
The only way you can ensure that doesn’t happen is to have a reference on
the object. So no, once you call ObDereferenceObject the pointer could
become invalid at any time.
4 - If both you and I take one reference on the object, and you dereference
it twice you’ll end up releasing my reference as well. The object will be
deleted and my pointer to it will become invalid even though i took a
refernece on it. Don’t do this.
5 - Since IRP_MJ_CLOSE requests have a pointer to the file object being
closed, and since that object is invalid once the I/O manager has sent its
close request, you won’t be able to send a valid one yourself (it will have
an invalid file pointer). The same with sending it more than once.
In the code snippit you sent above, once you call ObDereferenceObject on the
file object you can no longer use that pointer.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Thursday, October 07, 2004 12:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Page Fault
Thanks to Inaki and Mats for these two suggestions.
It seems that the problem may be caused by an unnecessary dereferencing of a
file pointer but I am not too sure about this yet. I still get a bg check
but now it doesn’t happen all the time!
This is a serial port upper filter driver and I attach it to the stack like
this:
(PortName is a the Unicode name of a serial port like “??\COM4”)
(fdo is my Device Object)
PFILE_OBJECT FileObject;
PDEVICE_OBJECT DeviceObject;
IoGetDeviceObjectPointer(PortName,FILE_READ_DATA,&FileObject,&DeviceObject);
IoAttachDeviceToDeviceStack(fdo,DeviceObject);
ObDereferenceObject(FileObject);
I understand that the IoGetDeviceObjectPointer function increments the
reference count for the File Object which means that the serial port is then
open and inaccessible to other appliactions and I need to dereference the
fileobject to close the port again.
This leads me to some questions:
-
If IoGetDeviceObjectPointer internally performs an “open” on the port, in
order to close the port again could I send down an IRP_MJ_CLOSE to perform
the same action as ObDereferenceObject?
-
What is the difference between ObDereferenceObject and IRP_MJ_CLOSE?
-
When the FileObject has been dereferenced is it still a valid pointer to
the file object?
-
What happens if I dereference a file object too many times?
-
What happens if I send down IRP_MJ_CLOSE when the port is already closed?
Or send it down more than once?
Thank you for your help everyone, I have the weight of management bearing
down on me!
Alasdair
-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com
mailto:xxxxx ]
> Sent: 06 October 2004 15:04
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Page Fault
>
>
> This is certainly one of those cases where you want to do
> “!analyze -v” to get the stacktrace of what’s going on.
>
> I haven’t got a clue about what could be your particular bug,
> but I would hazard a couple of guesses: 1. The application is
> passing some data to the driver, whcih disappear when your
> application is exiting, and your driver tries to access it.
> 2. Something is sent to your driver that tells it to free
> something (Close, Finish, Exit or some such), and it’s
> freeing up some data structure, which is later on being
> accessed by your driver.
>
> Of course, these are only wild guesses, and it could be lots
> of other things.
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 10/06/2004 02:49:12 PM:
>
> > Hi,
> >
> > I am getting a bug check (0xcc) when I exit my application (not the
> > driver, the application). This application has previously
> loaded and
> > unloaded my driver by means of the Service Control Manager. It has
> > also sent two private ioctls to the driver. As far as I am aware
> > everything has been tidied up in the driver on exit, and my
> > application does not touch it when unloading, so why might my
> > application cause this bug check? It seems to happen after the
> > application has exited so I have not a lot left to trace into.
> >
> > Thanks
> >
> > Alasdair
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www http:
.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument:
> ‘’
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
>
> > NOTICE AND DISCLAIMER:
> > This email (including attachments) is confidential. If you have
> > received this email in error please notify the sender
> immediately and
> > delete this email from your system without copying or
> disseminating it
> > or placing any reliance upon its contents. We cannot accept
> liability
> > for any breaches of confidence arising through use of email. Any
> > opinions expressed in this email (including attachments)
> are those of
> > the author and do not necessarily reflect our opinions. We will not
> > accept responsibility for any commitments made by our employees
> > outside the scope of our business. We do not warrant the
> accuracy or
> > completeness of such
> information.
> >
> > ForwardSourceID:NT00004AFA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
http:
>
> You are currently subscribed to ntdev as:
> xxxxx@t-mobile.co.uk To unsubscribe send a blank
> email to xxxxx@lists.osr.com
>
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.</http:></http:></mailto:xxxxx>