IoGetDeviceObjectPointer & dereferencing

NTDEV
1

We have a driver that appeared to be corrupting NTs device object data structures,
when just opening and closing objects, yielding BSODs, or what
amounts to a “object not found” error on later opens
(IoGetDeviceObjectPointer() call).

This driver had used the “Baker” method from (The Windows NT Device
Driver Book):
IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS, &pFileObject, &pDeviceObject );

ObReferenceObjectByPointer( &pDeviceObject, FILE_ALL_ACCESS, NULL, KernelMode );
ObDereferenceObject( pFileObject );

when finally done,
ObDereferenceObject(pDeviceObject)

When we changed it to use the more standard DDK version:
IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS, &pFileObject, &pDeviceObject );

when finally done:
ObDereferenceObject( pFileObject );

and the problem appeared to go away. So the question is whether there is something wrong with
the “Baker” method, or whether we have just moved the footprint of the bug around.

-DH

Dave Harvey, System Software Solutions, Inc.
617-964-7039, FAX 208-361-9395, xxxxx@syssoftsol.com, http://www.syssoftsol.com
Specialists in fault tolerance, SMP, clusters, and Windows/NT.

2

Yeah the problem would be the statement:

ObReferenceObjectByPointer( &pDeviceObject, FILE_ALL_ACCESS, NULL,
KernelMode );

as you have passed in the address of a pointer rather than its value.

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dave Harvey
Sent: Monday, August 28, 2000 10:51 PM
To: NT Developers Interest List
Subject: [ntdev] IoGetDeviceObjectPointer & dereferencing

We have a driver that appeared to be corrupting NTs device object
data structures,
when just opening and closing objects, yielding BSODs, or what
amounts to a “object not found” error on later opens
(IoGetDeviceObjectPointer() call).

This driver had used the “Baker” method from (The Windows NT Device
Driver Book):
IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS,
&pFileObject, &pDeviceObject );

ObReferenceObjectByPointer( &pDeviceObject, FILE_ALL_ACCESS,
NULL, KernelMode );
ObDereferenceObject( pFileObject );

when finally done,
ObDereferenceObject(pDeviceObject)

When we changed it to use the more standard DDK version:
IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS,
&pFileObject, &pDeviceObject );

when finally done:
ObDereferenceObject( pFileObject );

and the problem appeared to go away. So the question is whether
there is something wrong with
the “Baker” method, or whether we have just moved the footprint
of the bug around.

-DH

Dave Harvey, System Software Solutions, Inc.
617-964-7039, FAX 208-361-9395, xxxxx@syssoftsol.com,
http://www.syssoftsol.com
Specialists in fault tolerance, SMP, clusters, and Windows/NT.

You are currently subscribed to ntdev as: xxxxx@wattanuck.mv.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

3

Note that every DeviceObject has the reference count in the
ObjectManagers’s opaque part (in the DEVICE_OBJECT
structure itself). So no ObjectManager’s referencing could
increment this value - and this is mandatory for Io Manager.
But for every opened FileObject there is one reference in
FileObject->DeviceObject->ReferenceCount.
When the FileObject is finally dereferenced, the IopDeleteFile
(Io Manager’s OB_DELETE_METHOD for File object type)
will decrement the FileObject->DeviceObject->ReferenceCount.
So the DDK method is correct while the “Baker” one is invalid.

Paul

-----P?vodn? zpr?va-----
Od: Mark Roddy [SMTP:xxxxx@hollistech.com]
Odesl?no: Tuesday, August 29, 2000 1:51 PM
Komu: NT Developers Interest List
P?edm?t: [ntdev] RE: IoGetDeviceObjectPointer & dereferencing

Yeah the problem would be the statement:

ObReferenceObjectByPointer( &pDeviceObject, FILE_ALL_ACCESS, NULL,
KernelMode );

as you have passed in the address of a pointer rather than its value.

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Dave Harvey
> Sent: Monday, August 28, 2000 10:51 PM
> To: NT Developers Interest List
> Subject: [ntdev] IoGetDeviceObjectPointer & dereferencing
>
>
>
> We have a driver that appeared to be corrupting NTs device object
> data structures,
> when just opening and closing objects, yielding BSODs, or what
> amounts to a “object not found” error on later opens
> (IoGetDeviceObjectPointer() call).
>
>
> This driver had used the “Baker” method from (The Windows NT Device
> Driver Book):
> IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS,
> &pFileObject, &pDeviceObject );
>
> ObReferenceObjectByPointer( &pDeviceObject, FILE_ALL_ACCESS,
> NULL, KernelMode );
> ObDereferenceObject( pFileObject );
>
> when finally done,
> ObDereferenceObject(pDeviceObject)
>
> When we changed it to use the more standard DDK version:
> IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS,
> &pFileObject, &pDeviceObject );
>
> when finally done:
> ObDereferenceObject( pFileObject );
>
> and the problem appeared to go away. So the question is whether
> there is something wrong with
> the “Baker” method, or whether we have just moved the footprint
> of the bug around.
>
> -DH
>
>
> ------------------------------------------------------------------
> ----------------------------------------
> Dave Harvey, System Software Solutions, Inc.
> 617-964-7039, FAX 208-361-9395, xxxxx@syssoftsol.com,
http://www.syssoftsol.com
Specialists in fault tolerance, SMP, clusters, and Windows/NT.

You are currently subscribed to ntdev as: xxxxx@wattanuck.mv.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

You are currently subscribed to ntdev as: xxxxx@sodatsw.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

4

Since Mark’s observation was correct
( perhaps I should have read it more carefullymyself),
and since they had already done it a different way (we
stopped getting BSODs and explained why)
they didn’t retest with the one change, so we never looked
at the validity of Paul’s assertion.

-DH

----- Original Message -----
From: “Pavel Hrdina”
To: “NT Developers Interest List”
Sent: Tuesday, August 29, 2000 8:31 AM
Subject: [ntdev] RE: IoGetDeviceObjectPointer & dereferencing

Note that every DeviceObject has the reference count in the
ObjectManagers’s opaque part (in the DEVICE_OBJECT
structure itself). So no ObjectManager’s referencing could
increment this value - and this is mandatory for Io Manager.
But for every opened FileObject there is one reference in
FileObject->DeviceObject->ReferenceCount.
When the FileObject is finally dereferenced, the IopDeleteFile
(Io Manager’s OB_DELETE_METHOD for File object type)
will decrement the FileObject->DeviceObject->ReferenceCount.
So the DDK method is correct while the “Baker” one is invalid.

Paul

> -----P?vodn? zpr?va-----
> Od: Mark Roddy [SMTP:xxxxx@hollistech.com]
> Odesl?no: Tuesday, August 29, 2000 1:51 PM
> Komu: NT Developers Interest List
> P?edm?t: [ntdev] RE: IoGetDeviceObjectPointer & dereferencing
>
> Yeah the problem would be the statement:
>
> ObReferenceObjectByPointer( &pDeviceObject, FILE_ALL_ACCESS, NULL,
> KernelMode );
>
> as you have passed in the address of a pointer rather than its value.
>
>
>
> Mark Roddy
> Windows 2000/NT Consultant
> Hollis Technology Solutions
> www.hollistech.com
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Dave Harvey
> > Sent: Monday, August 28, 2000 10:51 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] IoGetDeviceObjectPointer & dereferencing
> >
> >
> >
> > We have a driver that appeared to be corrupting NTs device object
> > data structures,
> > when just opening and closing objects, yielding BSODs, or what
> > amounts to a “object not found” error on later opens
> > (IoGetDeviceObjectPointer() call).
> >
> >
> > This driver had used the “Baker” method from (The Windows NT Device
> > Driver Book):
> > IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS,
> > &pFileObject, &pDeviceObject );
> >
> > ObReferenceObjectByPointer( &pDeviceObject, FILE_ALL_ACCESS,
> > NULL, KernelMode );
> > ObDereferenceObject( pFileObject );
> >
> > when finally done,
> > ObDereferenceObject(pDeviceObject)
> >
> > When we changed it to use the more standard DDK version:
> > IoGetDeviceObjectPointer( &UnicodeName, FILE_ALL_ACCESS,
> > &pFileObject, &pDeviceObject );
> >
> > when finally done:
> > ObDereferenceObject( pFileObject );
> >
> > and the problem appeared to go away. So the question is whether
> > there is something wrong with
> > the “Baker” method, or whether we have just moved the footprint
> > of the bug around.
> >
> > -DH
> >
> >
> > ------------------------------------------------------------------
> > ----------------------------------------
> > Dave Harvey, System Software Solutions, Inc.
> > 617-964-7039, FAX 208-361-9395, xxxxx@syssoftsol.com,
> http://www.syssoftsol.com
> Specialists in fault tolerance, SMP, clusters, and Windows/NT.
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@wattanuck.mv.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@sodatsw.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)

—
You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)