IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

[Lyndon_J_Clarke-2]

Gentlefolk

I have a question about when IRP_MJ_CLOSE is sent for some FILE_OBJECT and
how this relates to the ReferenceCount of the FILE_OBJECT.

I had the impression that IRP_MJ_CLOSE is sent when the ReferenceCount
becomes zero and is not sent if the ReferenceCount is non zero. So, if in a
filter driver I do ObReferenceObject(FileObject) at some point (not during
IRP_MJ_CLOSE!) and at some later point in time I do
ObDereferenceObject(FileObject), then I should not receive IRP_MJ_CLOSE for
FileObject in between these two points in time.

It seems to be that on Windows 2003 is some circumstances I *do* see
IRP_MJ_CLOSE between such points in time; in contrast I have never seen this
on Windows 2000.

So the question is, quite simple, have I had the wrong impression, and if
so, what are the rules (if any) regarding IRP_MJ_CLOSE for a FILE_OBJECT and
the ReferenceCount as described?

Thanks in advance
Lyndon

[OSR_Community_User]

> I have a question about when IRP_MJ_CLOSE is sent for some FILE_OBJECT

Just before its total death.

I had the impression that IRP_MJ_CLOSE is sent when the ReferenceCount
becomes zero and is not sent if the ReferenceCount is non zero.

Yes.

It seems to be that on Windows 2003 is some circumstances I *do* see
IRP_MJ_CLOSE between such points in time; in contrast I have never seen this
on Windows 2000.

Maybe some bugs?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[Lyndon_J_Clarke-2]

>> It seems to be that on Windows 2003 is some circumstances I *do* see

> IRP_MJ_CLOSE between such points in time; in contrast I have never seen
> this
> on Windows 2000.

Maybe some bugs?

Okay well I believe I have established as a fact that this does happen on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver dispatch
routine, and the at the same time the non paged pool seems to be near to
exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

[OSR_Community_User]

If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
reference count, there is certainly a bug - and at that in the OS. If
you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
did not dereference, that’s a bug, but it means some driver or OS
component is decrementing the reference count when it should not be
doing so. The most likely culprit will be on the stack at the time you
see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
evidence of guilt.

Reference counting problems, particularly in global objects, are a
nightmare to track down. You might wish to start by debugging the
reference count in your driver just to make sure you aren’t releasing it
incorrectly in some other location. Beyond that, I suspect that
debugging this issue is going to require some rather ugly effort.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 8:02 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

> It seems to be that on Windows 2003 is some circumstances I *do* see
> IRP_MJ_CLOSE between such points in time; in contrast I have never
seen
> this
> on Windows 2000.

Maybe some bugs?

Okay well I believe I have established as a fact that this does happen
on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process
IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver
dispatch
routine, and the at the same time the non paged pool seems to be near to

exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

---

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Hi Tony

Thanks for some wise words. I have been going over the ObRef/ObDeRef calls
with a fine tooth comb these past couple of hours! I cant see how to obtain
the object reference count on W2K3; is there some debug level trick I can
use here?

Thanks again
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
reference count, there is certainly a bug - and at that in the OS. If
you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
did not dereference, that’s a bug, but it means some driver or OS
component is decrementing the reference count when it should not be
doing so. The most likely culprit will be on the stack at the time you
see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
evidence of guilt.

Reference counting problems, particularly in global objects, are a
nightmare to track down. You might wish to start by debugging the
reference count in your driver just to make sure you aren’t releasing it
incorrectly in some other location. Beyond that, I suspect that
debugging this issue is going to require some rather ugly effort.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 8:02 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

>> It seems to be that on Windows 2003 is some circumstances I do see
>> IRP_MJ_CLOSE between such points in time; in contrast I have never
seen
>> this
>> on Windows 2000.
>
> Maybe some bugs?

Okay well I believe I have established as a fact that this does happen
on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process
IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver
dispatch
routine, and the at the same time the non paged pool seems to be near to

exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Sorry, on the follow up question, !object was a bit obvious.

Cheers
Lyndon

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Hi Tony
>
> Thanks for some wise words. I have been going over the ObRef/ObDeRef calls
> with a fine tooth comb these past couple of hours! I cant see how to
> obtain the object reference count on W2K3; is there some debug level trick
> I can use here?
>
> Thanks again
> Lyndon
>
> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
> reference count, there is certainly a bug - and at that in the OS. If
> you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
> did not dereference, that’s a bug, but it means some driver or OS
> component is decrementing the reference count when it should not be
> doing so. The most likely culprit will be on the stack at the time you
> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
> evidence of guilt.
>
> Reference counting problems, particularly in global objects, are a
> nightmare to track down. You might wish to start by debugging the
> reference count in your driver just to make sure you aren’t releasing it
> incorrectly in some other location. Beyond that, I suspect that
> debugging this issue is going to require some rather ugly effort.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2004 in Boston!
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Wednesday, January 19, 2005 8:02 AM
> To: ntfsd redirect
> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
>>> It seems to be that on Windows 2003 is some circumstances I do see
>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
> seen
>>> this
>>> on Windows 2000.
>>
>> Maybe some bugs?
>
> Okay well I believe I have established as a fact that this does happen
> on
> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
>
> Maybe it helps if I describe a specific scenario. I process
> IRP_MJ_CLEANUP
> where the ObReferenceObject(FileObject) occurs in the filter driver
> dispatch
> routine, and the at the same time the non paged pool seems to be near to
>
> exhaustion as my filter cannot allocate from non paged pool.
>
> Cheers
> Lyndon
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

[Lyndon_J_Clarke-2]

Hi Tony

So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in the
circumstances where I had the suspicion that the reference count might be
non zero. Then !object on the file object address in windbag … here we are
with PointerCount 2 … any comment?

kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787 {HarddiskVolume1}

Thanks
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
reference count, there is certainly a bug - and at that in the OS. If
you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
did not dereference, that’s a bug, but it means some driver or OS
component is decrementing the reference count when it should not be
doing so. The most likely culprit will be on the stack at the time you
see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
evidence of guilt.

Reference counting problems, particularly in global objects, are a
nightmare to track down. You might wish to start by debugging the
reference count in your driver just to make sure you aren’t releasing it
incorrectly in some other location. Beyond that, I suspect that
debugging this issue is going to require some rather ugly effort.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 8:02 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

>> It seems to be that on Windows 2003 is some circumstances I do see
>> IRP_MJ_CLOSE between such points in time; in contrast I have never
seen
>> this
>> on Windows 2000.
>
> Maybe some bugs?

Okay well I believe I have established as a fact that this does happen
on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process
IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver
dispatch
routine, and the at the same time the non paged pool seems to be near to

exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

Lyndon J Clarke wrote:

>>It seems to be that on Windows 2003 is some circumstances I *do* see
>>IRP_MJ_CLOSE between such points in time; in contrast I have never seen
>>this
>>on Windows 2000.
>
>Maybe some bugs?

Okay well I believe I have established as a fact that this does happen on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver dispatch
routine, and the at the same time the non paged pool seems to be near to
exhaustion as my filter cannot allocate from non paged pool.

Here’s a naive question, I’m sure, but just for my own
edification, does the OS guarantee that the object
reference count will be at least 1 during IRP_MJ_CLEANUP?

Or is it possible that reference count has already
gone to zero when the IRP_MJ_CLEANUP is sent? (I.e.,
the last handle was also the last reference,
and IRP_MJ_CLOSE will be sent immediately after
IRP_MJ_CLEANUP.)

And if it is possible for this to happen, would it be legal
to call ObReferenceObject() in such a case?

I guess after thinking about it, I suspect the OS guarantees
that the reference count will be at least 1 during IRP_MJ_CLEANUP.
But I don’t know that.

Thanks,

• Joseph

[OSR_Community_User]

That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the ref
count is non-zero. Something is definitely screwed up. What does your
stack trace look like?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 10:56 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

Hi Tony

So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
the
circumstances where I had the suspicion that the reference count might
be
non zero. Then !object on the file object address in windbag … here we
are
with PointerCount 2 … any comment?

kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787 {HarddiskVolume1}

Thanks
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
reference count, there is certainly a bug - and at that in the OS. If
you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
did not dereference, that’s a bug, but it means some driver or OS
component is decrementing the reference count when it should not be
doing so. The most likely culprit will be on the stack at the time you
see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
evidence of guilt.

Reference counting problems, particularly in global objects, are a
nightmare to track down. You might wish to start by debugging the
reference count in your driver just to make sure you aren’t releasing it
incorrectly in some other location. Beyond that, I suspect that
debugging this issue is going to require some rather ugly effort.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 8:02 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

>> It seems to be that on Windows 2003 is some circumstances I do see
>> IRP_MJ_CLOSE between such points in time; in contrast I have never
seen
>> this
>> on Windows 2000.
>
> Maybe some bugs?

Okay well I believe I have established as a fact that this does happen
on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process
IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver
dispatch
routine, and the at the same time the non paged pool seems to be near to

exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Tony

Thanks for your attention. Here is stack, the irp, the irp stack location,
and the file object … sorry about the java … i think the
understandable action starts with kernel32!GetFileAttributesW …

Cheers
Lyndon

kd> kv f 100
Memory ChildEBP RetAddr Args to Child
f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint (FPO:
[0,0,0])
18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88 MYDRV!MyCacheFile+0x9c
(CONV: stdcall) [–snip–]
44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0 MYDRV!MyFilterFile+0xa9
(CONV: stdcall) [–snip–]
c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0 MYDRV!MyDispatch+0x1e
(FPO: [2,0,0]) (CONV: stdcall) [–snip–]
10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc nt!IofCallDriver+0x3f
(FPO: [0,0,0])
38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4 nt!IopDeleteFile+0x138
ec f64fcb08 80573600 861bce30 00000000 85e00f30 nt!IopParseDevice+0xe4f
78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
nt!ObpLookupObjectName+0x541
54 f64fcbd4 80585a35 00000000 00000000 ffffff01
nt!ObOpenObjectByName+0xe8
180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
nt!NtQueryAttributesFile+0xe6
0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000 nt!KiSystemService+0xcb
(FPO: [0,0] TrapFrame @ f64fcd64)
0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be
wrong.
1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
jvm!JVM_FindSignal+0x1d4a0
54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
jvm!JVM_StartThread+0x1cd
2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
jvm!JVM_RegisterPerfMethods+0x20ffc
18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
jvm!JVM_RegisterPerfMethods+0x20fcc
34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])

kd> !irp 8598a0a0
Irp is active with 10 stacks 10 is current (= 0x8598a254)
No Mdl Thread 8599c3c0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
\Driver\MYDRV
Args: 00000000 00000000 00000000 00000000
kd> dt nt!_IO_STACK_LOCATION 8598a254
+0x000 MajorFunction : 0x2 ‘’
+0x001 MinorFunction : 0 ‘’
+0x002 Flags : 0 ‘’
+0x003 Control : 0 ‘’
+0x004 Parameters : __unnamed
+0x014 DeviceObject : 0x85999a88
+0x018 FileObject : 0xf64fcc1c
+0x01c CompletionRoutine : (null)
+0x020 Context : (null)
kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787
{HarddiskVolume1}

“Tony Mason” wrote in message news:xxxxx@ntfsd…
That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the ref
count is non-zero. Something is definitely screwed up. What does your
stack trace look like?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 10:56 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

Hi Tony

So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
the
circumstances where I had the suspicion that the reference count might
be
non zero. Then !object on the file object address in windbag … here we
are
with PointerCount 2 … any comment?

kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787 {HarddiskVolume1}

Thanks
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
reference count, there is certainly a bug - and at that in the OS. If
you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
did not dereference, that’s a bug, but it means some driver or OS
component is decrementing the reference count when it should not be
doing so. The most likely culprit will be on the stack at the time you
see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
evidence of guilt.

Reference counting problems, particularly in global objects, are a
nightmare to track down. You might wish to start by debugging the
reference count in your driver just to make sure you aren’t releasing it
incorrectly in some other location. Beyond that, I suspect that
debugging this issue is going to require some rather ugly effort.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 8:02 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

>> It seems to be that on Windows 2003 is some circumstances I do see
>> IRP_MJ_CLOSE between such points in time; in contrast I have never
seen
>> this
>> on Windows 2000.
>
> Maybe some bugs?

Okay well I believe I have established as a fact that this does happen
on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process
IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver
dispatch
routine, and the at the same time the non paged pool seems to be near to

exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

The file object is on the stack - it is a “temporary” file object used
during the query. Bumping the reference count on it is ignored, which
is why you are seeing the “premature” close operation.

There should be discussion on this in the archive, as well as some
articles on OSR Online about this very issue (I talked about it when we
had the issue with IoCancelFileOpen).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 12:33 PM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

Tony

Thanks for your attention. Here is stack, the irp, the irp stack
location,
and the file object … sorry about the java … i think the
understandable action starts with kernel32!GetFileAttributesW …

Cheers
Lyndon

kd> kv f 100
Memory ChildEBP RetAddr Args to Child
f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
(FPO:
[0,0,0])
18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
MYDRV!MyCacheFile+0x9c
(CONV: stdcall) [–snip–]
44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
MYDRV!MyFilterFile+0xa9
(CONV: stdcall) [–snip–]
c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
MYDRV!MyDispatch+0x1e
(FPO: [2,0,0]) (CONV: stdcall) [–snip–]
10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
nt!IofCallDriver+0x3f
(FPO: [0,0,0])
38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
nt!IopDeleteFile+0x138
ec f64fcb08 80573600 861bce30 00000000 85e00f30
nt!IopParseDevice+0xe4f
78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
nt!ObpLookupObjectName+0x541
54 f64fcbd4 80585a35 00000000 00000000 ffffff01
nt!ObOpenObjectByName+0xe8
180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
nt!NtQueryAttributesFile+0xe6
0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
nt!KiSystemService+0xcb
(FPO: [0,0] TrapFrame @ f64fcd64)
0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be

wrong.
1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
jvm!JVM_FindSignal+0x1d4a0
54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
jvm!JVM_StartThread+0x1cd
2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
jvm!JVM_RegisterPerfMethods+0x20ffc
18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
jvm!JVM_RegisterPerfMethods+0x20fcc
34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])

kd> !irp 8598a0a0
Irp is active with 10 stacks 10 is current (= 0x8598a254)
No Mdl Thread 8599c3c0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
\Driver\MYDRV
Args: 00000000 00000000 00000000 00000000
kd> dt nt!_IO_STACK_LOCATION 8598a254
+0x000 MajorFunction : 0x2 ‘’
+0x001 MinorFunction : 0 ‘’
+0x002 Flags : 0 ‘’
+0x003 Control : 0 ‘’
+0x004 Parameters : __unnamed
+0x014 DeviceObject : 0x85999a88
+0x018 FileObject : 0xf64fcc1c
+0x01c CompletionRoutine : (null)
+0x020 Context : (null)
kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787
{HarddiskVolume1}

“Tony Mason” wrote in message news:xxxxx@ntfsd…
That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the ref
count is non-zero. Something is definitely screwed up. What does your
stack trace look like?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 10:56 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

Hi Tony

So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
the
circumstances where I had the suspicion that the reference count might
be
non zero. Then !object on the file object address in windbag … here we
are
with PointerCount 2 … any comment?

kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787 {HarddiskVolume1}

Thanks
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
reference count, there is certainly a bug - and at that in the OS. If
you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
did not dereference, that’s a bug, but it means some driver or OS
component is decrementing the reference count when it should not be
doing so. The most likely culprit will be on the stack at the time you
see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
evidence of guilt.

Reference counting problems, particularly in global objects, are a
nightmare to track down. You might wish to start by debugging the
reference count in your driver just to make sure you aren’t releasing it
incorrectly in some other location. Beyond that, I suspect that
debugging this issue is going to require some rather ugly effort.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 8:02 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

>> It seems to be that on Windows 2003 is some circumstances I do see
>> IRP_MJ_CLOSE between such points in time; in contrast I have never
seen
>> this
>> on Windows 2000.
>
> Maybe some bugs?

Okay well I believe I have established as a fact that this does happen
on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process
IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver
dispatch
routine, and the at the same time the non paged pool seems to be near to

exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Thanks Tony

I read the article about IoCancelFileOpen. I am afraid my searches with
“temporary file object” did not yield much of help to me. I assume you
inferred the file object is on the stack from the address; fair enough. Is
there a “better” way at runtime that we can determine that the
ObReferenceObject(FileObject) will be ignored? For example some
FileObject->Flags that signals we have one of these kinds of beasts on our
hands?

Cheers
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
The file object is on the stack - it is a “temporary” file object used
during the query. Bumping the reference count on it is ignored, which
is why you are seeing the “premature” close operation.

There should be discussion on this in the archive, as well as some
articles on OSR Online about this very issue (I talked about it when we
had the issue with IoCancelFileOpen).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 12:33 PM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

Tony

Thanks for your attention. Here is stack, the irp, the irp stack
location,
and the file object … sorry about the java … i think the
understandable action starts with kernel32!GetFileAttributesW …

Cheers
Lyndon

kd> kv f 100
Memory ChildEBP RetAddr Args to Child
f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
(FPO:
[0,0,0])
18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
MYDRV!MyCacheFile+0x9c
(CONV: stdcall) [–snip–]
44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
MYDRV!MyFilterFile+0xa9
(CONV: stdcall) [–snip–]
c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
MYDRV!MyDispatch+0x1e
(FPO: [2,0,0]) (CONV: stdcall) [–snip–]
10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
nt!IofCallDriver+0x3f
(FPO: [0,0,0])
38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
nt!IopDeleteFile+0x138
ec f64fcb08 80573600 861bce30 00000000 85e00f30
nt!IopParseDevice+0xe4f
78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
nt!ObpLookupObjectName+0x541
54 f64fcbd4 80585a35 00000000 00000000 ffffff01
nt!ObOpenObjectByName+0xe8
180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
nt!NtQueryAttributesFile+0xe6
0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
nt!KiSystemService+0xcb
(FPO: [0,0] TrapFrame @ f64fcd64)
0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be

wrong.
1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
jvm!JVM_FindSignal+0x1d4a0
54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
jvm!JVM_StartThread+0x1cd
2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
jvm!JVM_RegisterPerfMethods+0x20ffc
18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
jvm!JVM_RegisterPerfMethods+0x20fcc
34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])

kd> !irp 8598a0a0
Irp is active with 10 stacks 10 is current (= 0x8598a254)
No Mdl Thread 8599c3c0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
\Driver\MYDRV
Args: 00000000 00000000 00000000 00000000
kd> dt nt!_IO_STACK_LOCATION 8598a254
+0x000 MajorFunction : 0x2 ‘’
+0x001 MinorFunction : 0 ‘’
+0x002 Flags : 0 ‘’
+0x003 Control : 0 ‘’
+0x004 Parameters : __unnamed
+0x014 DeviceObject : 0x85999a88
+0x018 FileObject : 0xf64fcc1c
+0x01c CompletionRoutine : (null)
+0x020 Context : (null)
kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787
{HarddiskVolume1}

“Tony Mason” wrote in message news:xxxxx@ntfsd…
That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the ref
count is non-zero. Something is definitely screwed up. What does your
stack trace look like?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 10:56 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

Hi Tony

So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
the
circumstances where I had the suspicion that the reference count might
be
non zero. Then !object on the file object address in windbag … here we
are
with PointerCount 2 … any comment?

kd> !object f64fcc1c
Object: f64fcc1c Type: (8619a560) File
ObjectHeader: f64fcc04
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \protected\subdir9787 {HarddiskVolume1}

Thanks
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
reference count, there is certainly a bug - and at that in the OS. If
you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
did not dereference, that’s a bug, but it means some driver or OS
component is decrementing the reference count when it should not be
doing so. The most likely culprit will be on the stack at the time you
see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
evidence of guilt.

Reference counting problems, particularly in global objects, are a
nightmare to track down. You might wish to start by debugging the
reference count in your driver just to make sure you aren’t releasing it
incorrectly in some other location. Beyond that, I suspect that
debugging this issue is going to require some rather ugly effort.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 8:02 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

>> It seems to be that on Windows 2003 is some circumstances I do see
>> IRP_MJ_CLOSE between such points in time; in contrast I have never
seen
>> this
>> on Windows 2000.
>
> Maybe some bugs?

Okay well I believe I have established as a fact that this does happen
on
Windows 2003, so, are we saying, maybe some bugs in Windows 2003?

Maybe it helps if I describe a specific scenario. I process
IRP_MJ_CLEANUP
where the ObReferenceObject(FileObject) occurs in the filter driver
dispatch
routine, and the at the same time the non paged pool seems to be near to

exhaustion as my filter cannot allocate from non paged pool.

Cheers
Lyndon

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Dan_Partelly]

Ive been bitten by this long ago. There is no documented way
to distinguish between a real file object and a phony one,
built on stack. There are some undocumented ways, tough.
IIRC , such a file object will not have the Ob manager object
header. Single step through IopParseDevice() to see exactly how this
object is allocated.

Dan

----- Original Message -----
From: “Lyndon J Clarke”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, January 19, 2005 9:01 PM
Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

> Thanks Tony
>
> I read the article about IoCancelFileOpen. I am afraid my searches with
> “temporary file object” did not yield much of help to me. I assume you
> inferred the file object is on the stack from the address; fair enough. Is
> there a “better” way at runtime that we can determine that the
> ObReferenceObject(FileObject) will be ignored? For example some
> FileObject->Flags that signals we have one of these kinds of beasts on our
> hands?
>
> Cheers
> Lyndon
>
> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> The file object is on the stack - it is a “temporary” file object used
> during the query. Bumping the reference count on it is ignored, which
> is why you are seeing the “premature” close operation.
>
> There should be discussion on this in the archive, as well as some
> articles on OSR Online about this very issue (I talked about it when we
> had the issue with IoCancelFileOpen).
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2004 in Boston!
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Wednesday, January 19, 2005 12:33 PM
> To: ntfsd redirect
> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
> Tony
>
> Thanks for your attention. Here is stack, the irp, the irp stack
> location,
> and the file object … sorry about the java … i think the
> understandable action starts with kernel32!GetFileAttributesW …
>
> Cheers
> Lyndon
>
> kd> kv f 100
> Memory ChildEBP RetAddr Args to Child
> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
> (FPO:
> [0,0,0])
> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
> MYDRV!MyCacheFile+0x9c
> (CONV: stdcall) [–snip–]
> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
> MYDRV!MyFilterFile+0xa9
> (CONV: stdcall) [–snip–]
> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
> MYDRV!MyDispatch+0x1e
> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
> nt!IofCallDriver+0x3f
> (FPO: [0,0,0])
> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
> nt!IopDeleteFile+0x138
> ec f64fcb08 80573600 861bce30 00000000 85e00f30
> nt!IopParseDevice+0xe4f
> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
> nt!ObpLookupObjectName+0x541
> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
> nt!ObOpenObjectByName+0xe8
> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
> nt!NtQueryAttributesFile+0xe6
> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
> nt!KiSystemService+0xcb
> (FPO: [0,0] TrapFrame @ f64fcd64)
> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
> WARNING: Stack unwind information not available. Following frames may be
>
> wrong.
> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
> jvm!JVM_FindSignal+0x1d4a0
> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
> jvm!JVM_StartThread+0x1cd
> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
> jvm!JVM_RegisterPerfMethods+0x20ffc
> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
> jvm!JVM_RegisterPerfMethods+0x20fcc
> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
>
> kd> !irp 8598a0a0
> Irp is active with 10 stacks 10 is current (= 0x8598a254)
> No Mdl Thread 8599c3c0: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
> \Driver\MYDRV
> Args: 00000000 00000000 00000000 00000000
> kd> dt nt!_IO_STACK_LOCATION 8598a254
> +0x000 MajorFunction : 0x2 ‘’
> +0x001 MinorFunction : 0 ‘’
> +0x002 Flags : 0 ‘’
> +0x003 Control : 0 ‘’
> +0x004 Parameters : __unnamed
> +0x014 DeviceObject : 0x85999a88
> +0x018 FileObject : 0xf64fcc1c
> +0x01c CompletionRoutine : (null)
> +0x020 Context : (null)
> kd> !object f64fcc1c
> Object: f64fcc1c Type: (8619a560) File
> ObjectHeader: f64fcc04
> HandleCount: 0 PointerCount: 2
> Directory Object: 00000000 Name: \protected\subdir9787
> {HarddiskVolume1}
>
>
>
> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the ref
> count is non-zero. Something is definitely screwed up. What does your
> stack trace look like?
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2004 in Boston!
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Wednesday, January 19, 2005 10:56 AM
> To: ntfsd redirect
> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
> Hi Tony
>
> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
> the
> circumstances where I had the suspicion that the reference count might
> be
> non zero. Then !object on the file object address in windbag … here we
> are
> with PointerCount 2 … any comment?
>
> kd> !object f64fcc1c
> Object: f64fcc1c Type: (8619a560) File
> ObjectHeader: f64fcc04
> HandleCount: 0 PointerCount: 2
> Directory Object: 00000000 Name: \protected\subdir9787 {HarddiskVolume1}
>
>
> Thanks
> Lyndon
>
> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
> reference count, there is certainly a bug - and at that in the OS. If
> you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
> did not dereference, that’s a bug, but it means some driver or OS
> component is decrementing the reference count when it should not be
> doing so. The most likely culprit will be on the stack at the time you
> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
> evidence of guilt.
>
> Reference counting problems, particularly in global objects, are a
> nightmare to track down. You might wish to start by debugging the
> reference count in your driver just to make sure you aren’t releasing it
> incorrectly in some other location. Beyond that, I suspect that
> debugging this issue is going to require some rather ugly effort.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2004 in Boston!
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Wednesday, January 19, 2005 8:02 AM
> To: ntfsd redirect
> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
>>> It seems to be that on Windows 2003 is some circumstances I do see
>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
> seen
>>> this
>>> on Windows 2000.
>>
>> Maybe some bugs?
>
> Okay well I believe I have established as a fact that this does happen
> on
> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
>
> Maybe it helps if I describe a specific scenario. I process
> IRP_MJ_CLEANUP
> where the ObReferenceObject(FileObject) occurs in the filter driver
> dispatch
> routine, and the at the same time the non paged pool seems to be near to
>
> exhaustion as my filter cannot allocate from non paged pool.
>
> Cheers
> Lyndon
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

I see. I imagine, although it might not be a wonderful thng to do, that a
phony file object can also be built on allocated paged pool?

“Dan Partelly” wrote in message news:xxxxx@ntfsd…
> Ive been bitten by this long ago. There is no documented way
> to distinguish between a real file object and a phony one,
> built on stack. There are some undocumented ways, tough.
> IIRC , such a file object will not have the Ob manager object
> header. Single step through IopParseDevice() to see exactly how this
> object is allocated.
>
> Dan
>
>
>
> ----- Original Message -----
> From: “Lyndon J Clarke”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Wednesday, January 19, 2005 9:01 PM
> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
>
>> Thanks Tony
>>
>> I read the article about IoCancelFileOpen. I am afraid my searches with
>> “temporary file object” did not yield much of help to me. I assume you
>> inferred the file object is on the stack from the address; fair enough.
>> Is there a “better” way at runtime that we can determine that the
>> ObReferenceObject(FileObject) will be ignored? For example some
>> FileObject->Flags that signals we have one of these kinds of beasts on
>> our hands?
>>
>> Cheers
>> Lyndon
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> The file object is on the stack - it is a “temporary” file object used
>> during the query. Bumping the reference count on it is ignored, which
>> is why you are seeing the “premature” close operation.
>>
>> There should be discussion on this in the archive, as well as some
>> articles on OSR Online about this very issue (I talked about it when we
>> had the issue with IoCancelFileOpen).
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class April
>> 4, 2004 in Boston!
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 12:33 PM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>> Tony
>>
>> Thanks for your attention. Here is stack, the irp, the irp stack
>> location,
>> and the file object … sorry about the java … i think the
>> understandable action starts with kernel32!GetFileAttributesW …
>>
>> Cheers
>> Lyndon
>>
>> kd> kv f 100
>> Memory ChildEBP RetAddr Args to Child
>> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
>> (FPO:
>> [0,0,0])
>> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
>> MYDRV!MyCacheFile+0x9c
>> (CONV: stdcall) [–snip–]
>> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
>> MYDRV!MyFilterFile+0xa9
>> (CONV: stdcall) [–snip–]
>> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
>> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
>> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
>> MYDRV!MyDispatch+0x1e
>> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
>> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
>> nt!IofCallDriver+0x3f
>> (FPO: [0,0,0])
>> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
>> nt!IopDeleteFile+0x138
>> ec f64fcb08 80573600 861bce30 00000000 85e00f30
>> nt!IopParseDevice+0xe4f
>> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
>> nt!ObpLookupObjectName+0x541
>> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
>> nt!ObOpenObjectByName+0xe8
>> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
>> nt!NtQueryAttributesFile+0xe6
>> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
>> nt!KiSystemService+0xcb
>> (FPO: [0,0] TrapFrame @ f64fcd64)
>> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
>> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
>> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
>> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
>> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
>> WARNING: Stack unwind information not available. Following frames may be
>>
>> wrong.
>> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
>> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
>> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
>> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
>> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
>> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
>> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
>> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
>> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
>> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
>> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
>> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
>> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
>> jvm!JVM_FindSignal+0x1d4a0
>> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
>> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
>> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
>> jvm!JVM_StartThread+0x1cd
>> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
>> jvm!JVM_RegisterPerfMethods+0x20ffc
>> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
>> jvm!JVM_RegisterPerfMethods+0x20fcc
>> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
>> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
>> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
>> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
>>
>> kd> !irp 8598a0a0
>> Irp is active with 10 stacks 10 is current (= 0x8598a254)
>> No Mdl Thread 8599c3c0: Irp stack trace.
>> cmd flg cl Device File Completion-Context
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
>> \Driver\MYDRV
>> Args: 00000000 00000000 00000000 00000000
>> kd> dt nt!_IO_STACK_LOCATION 8598a254
>> +0x000 MajorFunction : 0x2 ‘’
>> +0x001 MinorFunction : 0 ‘’
>> +0x002 Flags : 0 ‘’
>> +0x003 Control : 0 ‘’
>> +0x004 Parameters : __unnamed
>> +0x014 DeviceObject : 0x85999a88
>> +0x018 FileObject : 0xf64fcc1c
>> +0x01c CompletionRoutine : (null)
>> +0x020 Context : (null)
>> kd> !object f64fcc1c
>> Object: f64fcc1c Type: (8619a560) File
>> ObjectHeader: f64fcc04
>> HandleCount: 0 PointerCount: 2
>> Directory Object: 00000000 Name: \protected\subdir9787
>> {HarddiskVolume1}
>>
>>
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the ref
>> count is non-zero. Something is definitely screwed up. What does your
>> stack trace look like?
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class April
>> 4, 2004 in Boston!
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 10:56 AM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>> Hi Tony
>>
>> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
>> the
>> circumstances where I had the suspicion that the reference count might
>> be
>> non zero. Then !object on the file object address in windbag … here we
>> are
>> with PointerCount 2 … any comment?
>>
>> kd> !object f64fcc1c
>> Object: f64fcc1c Type: (8619a560) File
>> ObjectHeader: f64fcc04
>> HandleCount: 0 PointerCount: 2
>> Directory Object: 00000000 Name: \protected\subdir9787 {HarddiskVolume1}
>>
>>
>> Thanks
>> Lyndon
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
>> reference count, there is certainly a bug - and at that in the OS. If
>> you are seeing an IRP_MJ_CLOSE on a file object that you referenced but
>> did not dereference, that’s a bug, but it means some driver or OS
>> component is decrementing the reference count when it should not be
>> doing so. The most likely culprit will be on the stack at the time you
>> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
>> evidence of guilt.
>>
>> Reference counting problems, particularly in global objects, are a
>> nightmare to track down. You might wish to start by debugging the
>> reference count in your driver just to make sure you aren’t releasing it
>> incorrectly in some other location. Beyond that, I suspect that
>> debugging this issue is going to require some rather ugly effort.
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class April
>> 4, 2004 in Boston!
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 8:02 AM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>>>> It seems to be that on Windows 2003 is some circumstances I do see
>>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
>> seen
>>>> this
>>>> on Windows 2000.
>>>
>>> Maybe some bugs?
>>
>> Okay well I believe I have established as a fact that this does happen
>> on
>> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
>>
>> Maybe it helps if I describe a specific scenario. I process
>> IRP_MJ_CLEANUP
>> where the ObReferenceObject(FileObject) occurs in the filter driver
>> dispatch
>> routine, and the at the same time the non paged pool seems to be near to
>>
>> exhaustion as my filter cannot allocate from non paged pool.
>>
>> Cheers
>> Lyndon
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

[OSR_Community_User]

No, these phony file objects are only on the stack as far as I’ve ever
seen - further you are allowed to assume any object is from non-paged
pool, so allocation from paged pool would violate that constraint.

As for detecting it, how about calling IoGetStackLimits and checking to
determine if the object is within that range? There are cases where
IoGetStackLimits doesn’t work (in a DPC) but that should never apply to
any case in which you’d be called.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 3:51 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

I see. I imagine, although it might not be a wonderful thng to do, that
a
phony file object can also be built on allocated paged pool?

“Dan Partelly” wrote in message
news:xxxxx@ntfsd…
> Ive been bitten by this long ago. There is no documented way
> to distinguish between a real file object and a phony one,
> built on stack. There are some undocumented ways, tough.
> IIRC , such a file object will not have the Ob manager object
> header. Single step through IopParseDevice() to see exactly how this
> object is allocated.
>
> Dan
>
>
>
> ----- Original Message -----
> From: “Lyndon J Clarke”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Wednesday, January 19, 2005 9:01 PM
> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
>
>> Thanks Tony
>>
>> I read the article about IoCancelFileOpen. I am afraid my searches
with
>> “temporary file object” did not yield much of help to me. I assume
you
>> inferred the file object is on the stack from the address; fair
enough.
>> Is there a “better” way at runtime that we can determine that the
>> ObReferenceObject(FileObject) will be ignored? For example some
>> FileObject->Flags that signals we have one of these kinds of beasts
on
>> our hands?
>>
>> Cheers
>> Lyndon
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> The file object is on the stack - it is a “temporary” file object
used
>> during the query. Bumping the reference count on it is ignored,
which
>> is why you are seeing the “premature” close operation.
>>
>> There should be discussion on this in the archive, as well as some
>> articles on OSR Online about this very issue (I talked about it when
we
>> had the issue with IoCancelFileOpen).
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class
April
>> 4, 2004 in Boston!
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 12:33 PM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>> Tony
>>
>> Thanks for your attention. Here is stack, the irp, the irp stack
>> location,
>> and the file object … sorry about the java … i think the
>> understandable action starts with kernel32!GetFileAttributesW …
>>
>> Cheers
>> Lyndon
>>
>> kd> kv f 100
>> Memory ChildEBP RetAddr Args to Child
>> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
>> (FPO:
>> [0,0,0])
>> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
>> MYDRV!MyCacheFile+0x9c
>> (CONV: stdcall) [–snip–]
>> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
>> MYDRV!MyFilterFile+0xa9
>> (CONV: stdcall) [–snip–]
>> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
>> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
>> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
>> MYDRV!MyDispatch+0x1e
>> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
>> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
>> nt!IofCallDriver+0x3f
>> (FPO: [0,0,0])
>> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
>> nt!IopDeleteFile+0x138
>> ec f64fcb08 80573600 861bce30 00000000 85e00f30
>> nt!IopParseDevice+0xe4f
>> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
>> nt!ObpLookupObjectName+0x541
>> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
>> nt!ObOpenObjectByName+0xe8
>> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
>> nt!NtQueryAttributesFile+0xe6
>> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
>> nt!KiSystemService+0xcb
>> (FPO: [0,0] TrapFrame @ f64fcd64)
>> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
>> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
>> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
>> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
>> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
>> WARNING: Stack unwind information not available. Following frames may
be
>>
>> wrong.
>> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
>> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
>> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
>> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
>> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
>> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
>> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
>> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
>> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
>> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
>> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
>> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
>> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
>> jvm!JVM_FindSignal+0x1d4a0
>> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
>> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
>> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
>> jvm!JVM_StartThread+0x1cd
>> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
>> jvm!JVM_RegisterPerfMethods+0x20ffc
>> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
>> jvm!JVM_RegisterPerfMethods+0x20fcc
>> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
>> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
>> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
>> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
>>
>> kd> !irp 8598a0a0
>> Irp is active with 10 stacks 10 is current (= 0x8598a254)
>> No Mdl Thread 8599c3c0: Irp stack trace.
>> cmd flg cl Device File Completion-Context
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
>> \Driver\MYDRV
>> Args: 00000000 00000000 00000000 00000000
>> kd> dt nt!_IO_STACK_LOCATION 8598a254
>> +0x000 MajorFunction : 0x2 ‘’
>> +0x001 MinorFunction : 0 ‘’
>> +0x002 Flags : 0 ‘’
>> +0x003 Control : 0 ‘’
>> +0x004 Parameters : __unnamed
>> +0x014 DeviceObject : 0x85999a88
>> +0x018 FileObject : 0xf64fcc1c
>> +0x01c CompletionRoutine : (null)
>> +0x020 Context : (null)
>> kd> !object f64fcc1c
>> Object: f64fcc1c Type: (8619a560) File
>> ObjectHeader: f64fcc04
>> HandleCount: 0 PointerCount: 2
>> Directory Object: 00000000 Name: \protected\subdir9787
>> {HarddiskVolume1}
>>
>>
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the
ref
>> count is non-zero. Something is definitely screwed up. What does
your
>> stack trace look like?
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class
April
>> 4, 2004 in Boston!
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 10:56 AM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>> Hi Tony
>>
>> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
>> the
>> circumstances where I had the suspicion that the reference count
might
>> be
>> non zero. Then !object on the file object address in windbag … here
we
>> are
>> with PointerCount 2 … any comment?
>>
>> kd> !object f64fcc1c
>> Object: f64fcc1c Type: (8619a560) File
>> ObjectHeader: f64fcc04
>> HandleCount: 0 PointerCount: 2
>> Directory Object: 00000000 Name: \protected\subdir9787
{HarddiskVolume1}
>>
>>
>> Thanks
>> Lyndon
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
>> reference count, there is certainly a bug - and at that in the OS.
If
>> you are seeing an IRP_MJ_CLOSE on a file object that you referenced
but
>> did not dereference, that’s a bug, but it means some driver or OS
>> component is decrementing the reference count when it should not be
>> doing so. The most likely culprit will be on the stack at the time
you
>> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
>> evidence of guilt.
>>
>> Reference counting problems, particularly in global objects, are a
>> nightmare to track down. You might wish to start by debugging the
>> reference count in your driver just to make sure you aren’t releasing
it
>> incorrectly in some other location. Beyond that, I suspect that
>> debugging this issue is going to require some rather ugly effort.
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class
April
>> 4, 2004 in Boston!
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 8:02 AM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>>>> It seems to be that on Windows 2003 is some circumstances I do
see
>>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
>> seen
>>>> this
>>>> on Windows 2000.
>>>
>>> Maybe some bugs?
>>
>> Okay well I believe I have established as a fact that this does
happen
>> on
>> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
>>
>> Maybe it helps if I describe a specific scenario. I process
>> IRP_MJ_CLEANUP
>> where the ObReferenceObject(FileObject) occurs in the filter driver
>> dispatch
>> routine, and the at the same time the non paged pool seems to be near
to
>>
>> exhaustion as my filter cannot allocate from non paged pool.
>>
>> Cheers
>> Lyndon
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Hi Tony

Yes, I had assumed IoGetStackLimits to test if the file ahem object address
is within the stack, hence my question regarding whether it is possible that
such non objects are not in the stack. You see, what worries me a bit, in
what you have said is the “… as far as I’ve ever seen …” part. I was
aware that paged pool would be a violation - perhaps I had over specified my
comment and thus thrown a red herring to kind responders.

Cheers
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
No, these phony file objects are only on the stack as far as I’ve ever
seen - further you are allowed to assume any object is from non-paged
pool, so allocation from paged pool would violate that constraint.

As for detecting it, how about calling IoGetStackLimits and checking to
determine if the object is within that range? There are cases where
IoGetStackLimits doesn’t work (in a DPC) but that should never apply to
any case in which you’d be called.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Wednesday, January 19, 2005 3:51 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

I see. I imagine, although it might not be a wonderful thng to do, that
a
phony file object can also be built on allocated paged pool?

“Dan Partelly” wrote in message
news:xxxxx@ntfsd…
> Ive been bitten by this long ago. There is no documented way
> to distinguish between a real file object and a phony one,
> built on stack. There are some undocumented ways, tough.
> IIRC , such a file object will not have the Ob manager object
> header. Single step through IopParseDevice() to see exactly how this
> object is allocated.
>
> Dan
>
>
>
> ----- Original Message -----
> From: “Lyndon J Clarke”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Wednesday, January 19, 2005 9:01 PM
> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
>
>> Thanks Tony
>>
>> I read the article about IoCancelFileOpen. I am afraid my searches
with
>> “temporary file object” did not yield much of help to me. I assume
you
>> inferred the file object is on the stack from the address; fair
enough.
>> Is there a “better” way at runtime that we can determine that the
>> ObReferenceObject(FileObject) will be ignored? For example some
>> FileObject->Flags that signals we have one of these kinds of beasts
on
>> our hands?
>>
>> Cheers
>> Lyndon
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> The file object is on the stack - it is a “temporary” file object
used
>> during the query. Bumping the reference count on it is ignored,
which
>> is why you are seeing the “premature” close operation.
>>
>> There should be discussion on this in the archive, as well as some
>> articles on OSR Online about this very issue (I talked about it when
we
>> had the issue with IoCancelFileOpen).
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class
April
>> 4, 2004 in Boston!
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 12:33 PM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>> Tony
>>
>> Thanks for your attention. Here is stack, the irp, the irp stack
>> location,
>> and the file object … sorry about the java … i think the
>> understandable action starts with kernel32!GetFileAttributesW …
>>
>> Cheers
>> Lyndon
>>
>> kd> kv f 100
>> Memory ChildEBP RetAddr Args to Child
>> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
>> (FPO:
>> [0,0,0])
>> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
>> MYDRV!MyCacheFile+0x9c
>> (CONV: stdcall) [–snip–]
>> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
>> MYDRV!MyFilterFile+0xa9
>> (CONV: stdcall) [–snip–]
>> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
>> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
>> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
>> MYDRV!MyDispatch+0x1e
>> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
>> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
>> nt!IofCallDriver+0x3f
>> (FPO: [0,0,0])
>> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
>> nt!IopDeleteFile+0x138
>> ec f64fcb08 80573600 861bce30 00000000 85e00f30
>> nt!IopParseDevice+0xe4f
>> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
>> nt!ObpLookupObjectName+0x541
>> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
>> nt!ObOpenObjectByName+0xe8
>> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
>> nt!NtQueryAttributesFile+0xe6
>> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
>> nt!KiSystemService+0xcb
>> (FPO: [0,0] TrapFrame @ f64fcd64)
>> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
>> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
>> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
>> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
>> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
>> WARNING: Stack unwind information not available. Following frames may
be
>>
>> wrong.
>> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
>> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
>> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
>> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
>> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
>> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
>> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
>> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
>> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
>> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
>> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
>> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
>> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
>> jvm!JVM_FindSignal+0x1d4a0
>> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
>> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
>> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
>> jvm!JVM_StartThread+0x1cd
>> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
>> jvm!JVM_RegisterPerfMethods+0x20ffc
>> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
>> jvm!JVM_RegisterPerfMethods+0x20fcc
>> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
>> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
>> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
>> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
>>
>> kd> !irp 8598a0a0
>> Irp is active with 10 stacks 10 is current (= 0x8598a254)
>> No Mdl Thread 8599c3c0: Irp stack trace.
>> cmd flg cl Device File Completion-Context
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>
>> Args: 00000000 00000000 00000000 00000000
>>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
>> \Driver\MYDRV
>> Args: 00000000 00000000 00000000 00000000
>> kd> dt nt!_IO_STACK_LOCATION 8598a254
>> +0x000 MajorFunction : 0x2 ‘’
>> +0x001 MinorFunction : 0 ‘’
>> +0x002 Flags : 0 ‘’
>> +0x003 Control : 0 ‘’
>> +0x004 Parameters : __unnamed
>> +0x014 DeviceObject : 0x85999a88
>> +0x018 FileObject : 0xf64fcc1c
>> +0x01c CompletionRoutine : (null)
>> +0x020 Context : (null)
>> kd> !object f64fcc1c
>> Object: f64fcc1c Type: (8619a560) File
>> ObjectHeader: f64fcc04
>> HandleCount: 0 PointerCount: 2
>> Directory Object: 00000000 Name: \protected\subdir9787
>> {HarddiskVolume1}
>>
>>
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the
ref
>> count is non-zero. Something is definitely screwed up. What does
your
>> stack trace look like?
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class
April
>> 4, 2004 in Boston!
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 10:56 AM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>> Hi Tony
>>
>> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
>> the
>> circumstances where I had the suspicion that the reference count
might
>> be
>> non zero. Then !object on the file object address in windbag … here
we
>> are
>> with PointerCount 2 … any comment?
>>
>> kd> !object f64fcc1c
>> Object: f64fcc1c Type: (8619a560) File
>> ObjectHeader: f64fcc04
>> HandleCount: 0 PointerCount: 2
>> Directory Object: 00000000 Name: \protected\subdir9787
{HarddiskVolume1}
>>
>>
>> Thanks
>> Lyndon
>>
>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
>> reference count, there is certainly a bug - and at that in the OS.
If
>> you are seeing an IRP_MJ_CLOSE on a file object that you referenced
but
>> did not dereference, that’s a bug, but it means some driver or OS
>> component is decrementing the reference count when it should not be
>> doing so. The most likely culprit will be on the stack at the time
you
>> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
>> evidence of guilt.
>>
>> Reference counting problems, particularly in global objects, are a
>> nightmare to track down. You might wish to start by debugging the
>> reference count in your driver just to make sure you aren’t releasing
it
>> incorrectly in some other location. Beyond that, I suspect that
>> debugging this issue is going to require some rather ugly effort.
>>
>> Regards,
>>
>> Tony
>>
>> Tony Mason
>> Consulting Partner
>> OSR Open Systems Resources, Inc.
>> http://www.osr.com
>>
>> Looking forward to seeing you at the Next OSR File Systems Class
April
>> 4, 2004 in Boston!
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Wednesday, January 19, 2005 8:02 AM
>> To: ntfsd redirect
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>>>> It seems to be that on Windows 2003 is some circumstances I do
see
>>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
>> seen
>>>> this
>>>> on Windows 2000.
>>>
>>> Maybe some bugs?
>>
>> Okay well I believe I have established as a fact that this does
happen
>> on
>> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
>>
>> Maybe it helps if I describe a specific scenario. I process
>> IRP_MJ_CLEANUP
>> where the ObReferenceObject(FileObject) occurs in the filter driver
>> dispatch
>> routine, and the at the same time the non paged pool seems to be near
to
>>
>> exhaustion as my filter cannot allocate from non paged pool.
>>
>> Cheers
>> Lyndon
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

IoGetStackLimits won’t help if a filter above you posts the request.

• Dan.

At 09:37 PM 1/19/2005 +0000, you wrote:

Hi Tony

Yes, I had assumed IoGetStackLimits to test if the file ahem object address
is within the stack, hence my question regarding whether it is possible that
such non objects are not in the stack. You see, what worries me a bit, in
what you have said is the “… as far as I’ve ever seen …” part. I was
aware that paged pool would be a violation - perhaps I had over specified my
comment and thus thrown a red herring to kind responders.

Cheers
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
>No, these phony file objects are only on the stack as far as I’ve ever
>seen - further you are allowed to assume any object is from non-paged
>pool, so allocation from paged pool would violate that constraint.
>
>As for detecting it, how about calling IoGetStackLimits and checking to
>determine if the object is within that range? There are cases where
>IoGetStackLimits doesn’t work (in a DPC) but that should never apply to
>any case in which you’d be called.
>
>Regards,
>
>Tony
>
>Tony Mason
>Consulting Partner
>OSR Open Systems Resources, Inc.
>http://www.osr.com
>
>Looking forward to seeing you at the Next OSR File Systems Class April
>4, 2004 in Boston!
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>Sent: Wednesday, January 19, 2005 3:51 PM
>To: ntfsd redirect
>Subject: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
>I see. I imagine, although it might not be a wonderful thng to do, that
>a
>phony file object can also be built on allocated paged pool?
>
>“Dan Partelly” wrote in message
>news:xxxxx@ntfsd…
> > Ive been bitten by this long ago. There is no documented way
> > to distinguish between a real file object and a phony one,
> > built on stack. There are some undocumented ways, tough.
> > IIRC , such a file object will not have the Ob manager object
> > header. Single step through IopParseDevice() to see exactly how this
> > object is allocated.
> >
> > Dan
> >
> >
> >
> > ----- Original Message -----
> > From: “Lyndon J Clarke”
> > Newsgroups: ntfsd
> > To: “Windows File Systems Devs Interest List”
> > Sent: Wednesday, January 19, 2005 9:01 PM
> > Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >
> >
> >> Thanks Tony
> >>
> >> I read the article about IoCancelFileOpen. I am afraid my searches
>with
> >> “temporary file object” did not yield much of help to me. I assume
>you
> >> inferred the file object is on the stack from the address; fair
>enough.
> >> Is there a “better” way at runtime that we can determine that the
> >> ObReferenceObject(FileObject) will be ignored? For example some
> >> FileObject->Flags that signals we have one of these kinds of beasts
>on
> >> our hands?
> >>
> >> Cheers
> >> Lyndon
> >>
> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> >> The file object is on the stack - it is a “temporary” file object
>used
> >> during the query. Bumping the reference count on it is ignored,
>which
> >> is why you are seeing the “premature” close operation.
> >>
> >> There should be discussion on this in the archive, as well as some
> >> articles on OSR Online about this very issue (I talked about it when
>we
> >> had the issue with IoCancelFileOpen).
> >>
> >> Regards,
> >>
> >> Tony
> >>
> >> Tony Mason
> >> Consulting Partner
> >> OSR Open Systems Resources, Inc.
> >> http://www.osr.com
> >>
> >> Looking forward to seeing you at the Next OSR File Systems Class
>April
> >> 4, 2004 in Boston!
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> Sent: Wednesday, January 19, 2005 12:33 PM
> >> To: ntfsd redirect
> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >>
> >> Tony
> >>
> >> Thanks for your attention. Here is stack, the irp, the irp stack
> >> location,
> >> and the file object … sorry about the java … i think the
> >> understandable action starts with kernel32!GetFileAttributesW …
> >>
> >> Cheers
> >> Lyndon
> >>
> >> kd> kv f 100
> >> Memory ChildEBP RetAddr Args to Child
> >> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
> >> (FPO:
> >> [0,0,0])
> >> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
> >> MYDRV!MyCacheFile+0x9c
> >> (CONV: stdcall) [–snip–]
> >> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
> >> MYDRV!MyFilterFile+0xa9
> >> (CONV: stdcall) [–snip–]
> >> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
> >> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
> >> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
> >> MYDRV!MyDispatch+0x1e
> >> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
> >> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
> >> nt!IofCallDriver+0x3f
> >> (FPO: [0,0,0])
> >> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
> >> nt!IopDeleteFile+0x138
> >> ec f64fcb08 80573600 861bce30 00000000 85e00f30
> >> nt!IopParseDevice+0xe4f
> >> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
> >> nt!ObpLookupObjectName+0x541
> >> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
> >> nt!ObOpenObjectByName+0xe8
> >> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
> >> nt!NtQueryAttributesFile+0xe6
> >> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
> >> nt!KiSystemService+0xcb
> >> (FPO: [0,0] TrapFrame @ f64fcd64)
> >> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
> >> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> >> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
> >> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
> >> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
> >> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
> >> WARNING: Stack unwind information not available. Following frames may
>be
> >>
> >> wrong.
> >> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
> >> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
> >> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
> >> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
> >> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
> >> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
> >> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
> >> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
> >> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
> >> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
> >> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
> >> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
> >> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
> >> jvm!JVM_FindSignal+0x1d4a0
> >> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
> >> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
> >> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
> >> jvm!JVM_StartThread+0x1cd
> >> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
> >> jvm!JVM_RegisterPerfMethods+0x20ffc
> >> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
> >> jvm!JVM_RegisterPerfMethods+0x20fcc
> >> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
> >> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
> >> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
> >> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
> >>
> >> kd> !irp 8598a0a0
> >> Irp is active with 10 stacks 10 is current (= 0x8598a254)
> >> No Mdl Thread 8599c3c0: Irp stack trace.
> >> cmd flg cl Device File Completion-Context
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >>
> >> Args: 00000000 00000000 00000000 00000000
> >>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
> >> \Driver\MYDRV
> >> Args: 00000000 00000000 00000000 00000000
> >> kd> dt nt!_IO_STACK_LOCATION 8598a254
> >> +0x000 MajorFunction : 0x2 ‘’
> >> +0x001 MinorFunction : 0 ‘’
> >> +0x002 Flags : 0 ‘’
> >> +0x003 Control : 0 ‘’
> >> +0x004 Parameters : __unnamed
> >> +0x014 DeviceObject : 0x85999a88
> >> +0x018 FileObject : 0xf64fcc1c
> >> +0x01c CompletionRoutine : (null)
> >> +0x020 Context : (null)
> >> kd> !object f64fcc1c
> >> Object: f64fcc1c Type: (8619a560) File
> >> ObjectHeader: f64fcc04
> >> HandleCount: 0 PointerCount: 2
> >> Directory Object: 00000000 Name: \protected\subdir9787
> >> {HarddiskVolume1}
> >>
> >>
> >>
> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> >> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the
>ref
> >> count is non-zero. Something is definitely screwed up. What does
>your
> >> stack trace look like?
> >>
> >> Regards,
> >>
> >> Tony
> >>
> >> Tony Mason
> >> Consulting Partner
> >> OSR Open Systems Resources, Inc.
> >> http://www.osr.com
> >>
> >> Looking forward to seeing you at the Next OSR File Systems Class
>April
> >> 4, 2004 in Boston!
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> Sent: Wednesday, January 19, 2005 10:56 AM
> >> To: ntfsd redirect
> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >>
> >> Hi Tony
> >>
> >> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
> >> the
> >> circumstances where I had the suspicion that the reference count
>might
> >> be
> >> non zero. Then !object on the file object address in windbag … here
>we
> >> are
> >> with PointerCount 2 … any comment?
> >>
> >> kd> !object f64fcc1c
> >> Object: f64fcc1c Type: (8619a560) File
> >> ObjectHeader: f64fcc04
> >> HandleCount: 0 PointerCount: 2
> >> Directory Object: 00000000 Name: \protected\subdir9787
>{HarddiskVolume1}
> >>
> >>
> >> Thanks
> >> Lyndon
> >>
> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> >> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
> >> reference count, there is certainly a bug - and at that in the OS.
>If
> >> you are seeing an IRP_MJ_CLOSE on a file object that you referenced
>but
> >> did not dereference, that’s a bug, but it means some driver or OS
> >> component is decrementing the reference count when it should not be
> >> doing so. The most likely culprit will be on the stack at the time
>you
> >> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
> >> evidence of guilt.
> >>
> >> Reference counting problems, particularly in global objects, are a
> >> nightmare to track down. You might wish to start by debugging the
> >> reference count in your driver just to make sure you aren’t releasing
>it
> >> incorrectly in some other location. Beyond that, I suspect that
> >> debugging this issue is going to require some rather ugly effort.
> >>
> >> Regards,
> >>
> >> Tony
> >>
> >> Tony Mason
> >> Consulting Partner
> >> OSR Open Systems Resources, Inc.
> >> http://www.osr.com
> >>
> >> Looking forward to seeing you at the Next OSR File Systems Class
>April
> >> 4, 2004 in Boston!
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> Sent: Wednesday, January 19, 2005 8:02 AM
> >> To: ntfsd redirect
> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >>
> >>>> It seems to be that on Windows 2003 is some circumstances I do
>see
> >>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
> >> seen
> >>>> this
> >>>> on Windows 2000.
> >>>
> >>> Maybe some bugs?
> >>
> >> Okay well I believe I have established as a fact that this does
>happen
> >> on
> >> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
> >>
> >> Maybe it helps if I describe a specific scenario. I process
> >> IRP_MJ_CLEANUP
> >> where the ObReferenceObject(FileObject) occurs in the filter driver
> >> dispatch
> >> routine, and the at the same time the non paged pool seems to be near
>to
> >>
> >> exhaustion as my filter cannot allocate from non paged pool.
> >>
> >> Cheers
> >> Lyndon
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@osr.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@privtek.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

[Lyndon_J_Clarke-2]

Good point! So any suggestions how to proceed in that case?

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> IoGetStackLimits won’t help if a filter above you posts the request.
>
> - Dan.
>
> At 09:37 PM 1/19/2005 +0000, you wrote:
>>Hi Tony
>>
>>Yes, I had assumed IoGetStackLimits to test if the file ahem object
>>address
>>is within the stack, hence my question regarding whether it is possible
>>that
>>such non objects are not in the stack. You see, what worries me a bit, in
>>what you have said is the “… as far as I’ve ever seen …” part. I was
>>aware that paged pool would be a violation - perhaps I had over specified
>>my
>>comment and thus thrown a red herring to kind responders.
>>
>>Cheers
>>Lyndon
>>
>>“Tony Mason” wrote in message news:xxxxx@ntfsd…
>>No, these phony file objects are only on the stack as far as I’ve ever
>>seen - further you are allowed to assume any object is from non-paged
>>pool, so allocation from paged pool would violate that constraint.
>>
>>As for detecting it, how about calling IoGetStackLimits and checking to
>>determine if the object is within that range? There are cases where
>>IoGetStackLimits doesn’t work (in a DPC) but that should never apply to
>>any case in which you’d be called.
>>
>>Regards,
>>
>>Tony
>>
>>Tony Mason
>>Consulting Partner
>>OSR Open Systems Resources, Inc.
>>http://www.osr.com
>>
>>Looking forward to seeing you at the Next OSR File Systems Class April
>>4, 2004 in Boston!
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>>Sent: Wednesday, January 19, 2005 3:51 PM
>>To: ntfsd redirect
>>Subject: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>>I see. I imagine, although it might not be a wonderful thng to do, that
>>a
>>phony file object can also be built on allocated paged pool?
>>
>>“Dan Partelly” wrote in message
>>news:xxxxx@ntfsd…
>> > Ive been bitten by this long ago. There is no documented way
>> > to distinguish between a real file object and a phony one,
>> > built on stack. There are some undocumented ways, tough.
>> > IIRC , such a file object will not have the Ob manager object
>> > header. Single step through IopParseDevice() to see exactly how this
>> > object is allocated.
>> >
>> > Dan
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: “Lyndon J Clarke”
>> > Newsgroups: ntfsd
>> > To: “Windows File Systems Devs Interest List”
>> > Sent: Wednesday, January 19, 2005 9:01 PM
>> > Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>> >
>> >
>> >> Thanks Tony
>> >>
>> >> I read the article about IoCancelFileOpen. I am afraid my searches
>>with
>> >> “temporary file object” did not yield much of help to me. I assume
>>you
>> >> inferred the file object is on the stack from the address; fair
>>enough.
>> >> Is there a “better” way at runtime that we can determine that the
>> >> ObReferenceObject(FileObject) will be ignored? For example some
>> >> FileObject->Flags that signals we have one of these kinds of beasts
>>on
>> >> our hands?
>> >>
>> >> Cheers
>> >> Lyndon
>> >>
>> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> >> The file object is on the stack - it is a “temporary” file object
>>used
>> >> during the query. Bumping the reference count on it is ignored,
>>which
>> >> is why you are seeing the “premature” close operation.
>> >>
>> >> There should be discussion on this in the archive, as well as some
>> >> articles on OSR Online about this very issue (I talked about it when
>>we
>> >> had the issue with IoCancelFileOpen).
>> >>
>> >> Regards,
>> >>
>> >> Tony
>> >>
>> >> Tony Mason
>> >> Consulting Partner
>> >> OSR Open Systems Resources, Inc.
>> >> http://www.osr.com
>> >>
>> >> Looking forward to seeing you at the Next OSR File Systems Class
>>April
>> >> 4, 2004 in Boston!
>> >>
>> >> -----Original Message-----
>> >> From: xxxxx@lists.osr.com
>> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> >> Sent: Wednesday, January 19, 2005 12:33 PM
>> >> To: ntfsd redirect
>> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>> >>
>> >> Tony
>> >>
>> >> Thanks for your attention. Here is stack, the irp, the irp stack
>> >> location,
>> >> and the file object … sorry about the java … i think the
>> >> understandable action starts with kernel32!GetFileAttributesW …
>> >>
>> >> Cheers
>> >> Lyndon
>> >>
>> >> kd> kv f 100
>> >> Memory ChildEBP RetAddr Args to Child
>> >> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
>> >> (FPO:
>> >> [0,0,0])
>> >> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
>> >> MYDRV!MyCacheFile+0x9c
>> >> (CONV: stdcall) [–snip–]
>> >> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
>> >> MYDRV!MyFilterFile+0xa9
>> >> (CONV: stdcall) [–snip–]
>> >> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
>> >> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
>> >> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
>> >> MYDRV!MyDispatch+0x1e
>> >> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
>> >> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
>> >> nt!IofCallDriver+0x3f
>> >> (FPO: [0,0,0])
>> >> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
>> >> nt!IopDeleteFile+0x138
>> >> ec f64fcb08 80573600 861bce30 00000000 85e00f30
>> >> nt!IopParseDevice+0xe4f
>> >> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
>> >> nt!ObpLookupObjectName+0x541
>> >> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
>> >> nt!ObOpenObjectByName+0xe8
>> >> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
>> >> nt!NtQueryAttributesFile+0xe6
>> >> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
>> >> nt!KiSystemService+0xcb
>> >> (FPO: [0,0] TrapFrame @ f64fcd64)
>> >> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
>> >> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>> >> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
>> >> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
>> >> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
>> >> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
>> >> WARNING: Stack unwind information not available. Following frames may
>>be
>> >>
>> >> wrong.
>> >> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
>> >> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
>> >> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
>> >> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
>> >> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
>> >> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
>> >> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
>> >> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
>> >> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
>> >> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
>> >> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
>> >> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
>> >> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
>> >> jvm!JVM_FindSignal+0x1d4a0
>> >> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
>> >> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
>> >> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
>> >> jvm!JVM_StartThread+0x1cd
>> >> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
>> >> jvm!JVM_RegisterPerfMethods+0x20ffc
>> >> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
>> >> jvm!JVM_RegisterPerfMethods+0x20fcc
>> >> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
>> >> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
>> >> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
>> >> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
>> >>
>> >> kd> !irp 8598a0a0
>> >> Irp is active with 10 stacks 10 is current (= 0x8598a254)
>> >> No Mdl Thread 8599c3c0: Irp stack trace.
>> >> cmd flg cl Device File Completion-Context
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >>
>> >> Args: 00000000 00000000 00000000 00000000
>> >>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
>> >> \Driver\MYDRV
>> >> Args: 00000000 00000000 00000000 00000000
>> >> kd> dt nt!_IO_STACK_LOCATION 8598a254
>> >> +0x000 MajorFunction : 0x2 ‘’
>> >> +0x001 MinorFunction : 0 ‘’
>> >> +0x002 Flags : 0 ‘’
>> >> +0x003 Control : 0 ‘’
>> >> +0x004 Parameters : __unnamed
>> >> +0x014 DeviceObject : 0x85999a88
>> >> +0x018 FileObject : 0xf64fcc1c
>> >> +0x01c CompletionRoutine : (null)
>> >> +0x020 Context : (null)
>> >> kd> !object f64fcc1c
>> >> Object: f64fcc1c Type: (8619a560) File
>> >> ObjectHeader: f64fcc04
>> >> HandleCount: 0 PointerCount: 2
>> >> Directory Object: 00000000 Name: \protected\subdir9787
>> >> {HarddiskVolume1}
>> >>
>> >>
>> >>
>> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> >> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the
>>ref
>> >> count is non-zero. Something is definitely screwed up. What does
>>your
>> >> stack trace look like?
>> >>
>> >> Regards,
>> >>
>> >> Tony
>> >>
>> >> Tony Mason
>> >> Consulting Partner
>> >> OSR Open Systems Resources, Inc.
>> >> http://www.osr.com
>> >>
>> >> Looking forward to seeing you at the Next OSR File Systems Class
>>April
>> >> 4, 2004 in Boston!
>> >>
>> >> -----Original Message-----
>> >> From: xxxxx@lists.osr.com
>> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> >> Sent: Wednesday, January 19, 2005 10:56 AM
>> >> To: ntfsd redirect
>> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>> >>
>> >> Hi Tony
>> >>
>> >> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
>> >> the
>> >> circumstances where I had the suspicion that the reference count
>>might
>> >> be
>> >> non zero. Then !object on the file object address in windbag … here
>>we
>> >> are
>> >> with PointerCount 2 … any comment?
>> >>
>> >> kd> !object f64fcc1c
>> >> Object: f64fcc1c Type: (8619a560) File
>> >> ObjectHeader: f64fcc04
>> >> HandleCount: 0 PointerCount: 2
>> >> Directory Object: 00000000 Name: \protected\subdir9787
>>{HarddiskVolume1}
>> >>
>> >>
>> >> Thanks
>> >> Lyndon
>> >>
>> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>> >> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
>> >> reference count, there is certainly a bug - and at that in the OS.
>>If
>> >> you are seeing an IRP_MJ_CLOSE on a file object that you referenced
>>but
>> >> did not dereference, that’s a bug, but it means some driver or OS
>> >> component is decrementing the reference count when it should not be
>> >> doing so. The most likely culprit will be on the stack at the time
>>you
>> >> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
>> >> evidence of guilt.
>> >>
>> >> Reference counting problems, particularly in global objects, are a
>> >> nightmare to track down. You might wish to start by debugging the
>> >> reference count in your driver just to make sure you aren’t releasing
>>it
>> >> incorrectly in some other location. Beyond that, I suspect that
>> >> debugging this issue is going to require some rather ugly effort.
>> >>
>> >> Regards,
>> >>
>> >> Tony
>> >>
>> >> Tony Mason
>> >> Consulting Partner
>> >> OSR Open Systems Resources, Inc.
>> >> http://www.osr.com
>> >>
>> >> Looking forward to seeing you at the Next OSR File Systems Class
>>April
>> >> 4, 2004 in Boston!
>> >> -----Original Message-----
>> >> From: xxxxx@lists.osr.com
>> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> >> Sent: Wednesday, January 19, 2005 8:02 AM
>> >> To: ntfsd redirect
>> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>> >>
>> >>>> It seems to be that on Windows 2003 is some circumstances I do
>>see
>> >>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
>> >> seen
>> >>>> this
>> >>>> on Windows 2000.
>> >>>
>> >>> Maybe some bugs?
>> >>
>> >> Okay well I believe I have established as a fact that this does
>>happen
>> >> on
>> >> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
>> >>
>> >> Maybe it helps if I describe a specific scenario. I process
>> >> IRP_MJ_CLEANUP
>> >> where the ObReferenceObject(FileObject) occurs in the filter driver
>> >> dispatch
>> >> routine, and the at the same time the non paged pool seems to be near
>>to
>> >>
>> >> exhaustion as my filter cannot allocate from non paged pool.
>> >>
>> >> Cheers
>> >> Lyndon
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the IFS FAQ at
>> >> https://www.osronline.com/article.cfm?id=17
>> >>
>> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the IFS FAQ at
>> >> https://www.osronline.com/article.cfm?id=17
>> >>
>> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the IFS FAQ at
>> >> https://www.osronline.com/article.cfm?id=17
>> >>
>> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
>> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the IFS FAQ at
>> >> https://www.osronline.com/article.cfm?id=17
>> >>
>> >> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
>> >
>> >
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@osr.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@privtek.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

[OSR_Community_User]

I don’t have a solution for it. You can tell if the request has been
posted if Irp->Tail.Overlay.Thread != PsGetCurrentThread(). There’s no
thread argument for IoGetStackLimits, and I don’t think you could write
IoGetStackLimitsForThread() without using undocumente ETHREAD offsets.

• Dan.

At 10:00 PM 1/19/2005 +0000, you wrote:

Good point! So any suggestions how to proceed in that case?

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> > IoGetStackLimits won’t help if a filter above you posts the request.
> >
> > - Dan.
> >
> > At 09:37 PM 1/19/2005 +0000, you wrote:
> >>Hi Tony
> >>
> >>Yes, I had assumed IoGetStackLimits to test if the file ahem object
> >>address
> >>is within the stack, hence my question regarding whether it is possible
> >>that
> >>such non objects are not in the stack. You see, what worries me a bit, in
> >>what you have said is the “… as far as I’ve ever seen …” part. I was
> >>aware that paged pool would be a violation - perhaps I had over specified
> >>my
> >>comment and thus thrown a red herring to kind responders.
> >>
> >>Cheers
> >>Lyndon
> >>
> >>“Tony Mason” wrote in message news:xxxxx@ntfsd…
> >>No, these phony file objects are only on the stack as far as I’ve ever
> >>seen - further you are allowed to assume any object is from non-paged
> >>pool, so allocation from paged pool would violate that constraint.
> >>
> >>As for detecting it, how about calling IoGetStackLimits and checking to
> >>determine if the object is within that range? There are cases where
> >>IoGetStackLimits doesn’t work (in a DPC) but that should never apply to
> >>any case in which you’d be called.
> >>
> >>Regards,
> >>
> >>Tony
> >>
> >>Tony Mason
> >>Consulting Partner
> >>OSR Open Systems Resources, Inc.
> >>http://www.osr.com
> >>
> >>Looking forward to seeing you at the Next OSR File Systems Class April
> >>4, 2004 in Boston!
> >>
> >>-----Original Message-----
> >>From: xxxxx@lists.osr.com
> >>[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >>Sent: Wednesday, January 19, 2005 3:51 PM
> >>To: ntfsd redirect
> >>Subject: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >>
> >>I see. I imagine, although it might not be a wonderful thng to do, that
> >>a
> >>phony file object can also be built on allocated paged pool?
> >>
> >>“Dan Partelly” wrote in message
> >>news:xxxxx@ntfsd…
> >> > Ive been bitten by this long ago. There is no documented way
> >> > to distinguish between a real file object and a phony one,
> >> > built on stack. There are some undocumented ways, tough.
> >> > IIRC , such a file object will not have the Ob manager object
> >> > header. Single step through IopParseDevice() to see exactly how this
> >> > object is allocated.
> >> >
> >> > Dan
> >> >
> >> >
> >> >
> >> > ----- Original Message -----
> >> > From: “Lyndon J Clarke”
> >> > Newsgroups: ntfsd
> >> > To: “Windows File Systems Devs Interest List”
> >> > Sent: Wednesday, January 19, 2005 9:01 PM
> >> > Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >> >
> >> >
> >> >> Thanks Tony
> >> >>
> >> >> I read the article about IoCancelFileOpen. I am afraid my searches
> >>with
> >> >> “temporary file object” did not yield much of help to me. I assume
> >>you
> >> >> inferred the file object is on the stack from the address; fair
> >>enough.
> >> >> Is there a “better” way at runtime that we can determine that the
> >> >> ObReferenceObject(FileObject) will be ignored? For example some
> >> >> FileObject->Flags that signals we have one of these kinds of beasts
> >>on
> >> >> our hands?
> >> >>
> >> >> Cheers
> >> >> Lyndon
> >> >>
> >> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> >> >> The file object is on the stack - it is a “temporary” file object
> >>used
> >> >> during the query. Bumping the reference count on it is ignored,
> >>which
> >> >> is why you are seeing the “premature” close operation.
> >> >>
> >> >> There should be discussion on this in the archive, as well as some
> >> >> articles on OSR Online about this very issue (I talked about it when
> >>we
> >> >> had the issue with IoCancelFileOpen).
> >> >>
> >> >> Regards,
> >> >>
> >> >> Tony
> >> >>
> >> >> Tony Mason
> >> >> Consulting Partner
> >> >> OSR Open Systems Resources, Inc.
> >> >> http://www.osr.com
> >> >>
> >> >> Looking forward to seeing you at the Next OSR File Systems Class
> >>April
> >> >> 4, 2004 in Boston!
> >> >>
> >> >> -----Original Message-----
> >> >> From: xxxxx@lists.osr.com
> >> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> >> Sent: Wednesday, January 19, 2005 12:33 PM
> >> >> To: ntfsd redirect
> >> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >> >>
> >> >> Tony
> >> >>
> >> >> Thanks for your attention. Here is stack, the irp, the irp stack
> >> >> location,
> >> >> and the file object … sorry about the java … i think the
> >> >> understandable action starts with kernel32!GetFileAttributesW …
> >> >>
> >> >> Cheers
> >> >> Lyndon
> >> >>
> >> >> kd> kv f 100
> >> >> Memory ChildEBP RetAddr Args to Child
> >> >> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
> >> >> (FPO:
> >> >> [0,0,0])
> >> >> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
> >> >> MYDRV!MyCacheFile+0x9c
> >> >> (CONV: stdcall) [–snip–]
> >> >> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
> >> >> MYDRV!MyFilterFile+0xa9
> >> >> (CONV: stdcall) [–snip–]
> >> >> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
> >> >> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
> >> >> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
> >> >> MYDRV!MyDispatch+0x1e
> >> >> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
> >> >> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
> >> >> nt!IofCallDriver+0x3f
> >> >> (FPO: [0,0,0])
> >> >> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
> >> >> nt!IopDeleteFile+0x138
> >> >> ec f64fcb08 80573600 861bce30 00000000 85e00f30
> >> >> nt!IopParseDevice+0xe4f
> >> >> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
> >> >> nt!ObpLookupObjectName+0x541
> >> >> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
> >> >> nt!ObOpenObjectByName+0xe8
> >> >> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
> >> >> nt!NtQueryAttributesFile+0xe6
> >> >> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
> >> >> nt!KiSystemService+0xcb
> >> >> (FPO: [0,0] TrapFrame @ f64fcd64)
> >> >> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
> >> >> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> >> >> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
> >> >> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
> >> >> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
> >> >> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
> >> >> WARNING: Stack unwind information not available. Following frames may
> >>be
> >> >>
> >> >> wrong.
> >> >> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
> >> >> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
> >> >> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
> >> >> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
> >> >> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
> >> >> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
> >> >> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
> >> >> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
> >> >> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
> >> >> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
> >> >> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
> >> >> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
> >> >> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
> >> >> jvm!JVM_FindSignal+0x1d4a0
> >> >> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
> >> >> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
> >> >> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
> >> >> jvm!JVM_StartThread+0x1cd
> >> >> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
> >> >> jvm!JVM_RegisterPerfMethods+0x20ffc
> >> >> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
> >> >> jvm!JVM_RegisterPerfMethods+0x20fcc
> >> >> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
> >> >> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
> >> >> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
> >> >> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
> >> >>
> >> >> kd> !irp 8598a0a0
> >> >> Irp is active with 10 stacks 10 is current (= 0x8598a254)
> >> >> No Mdl Thread 8599c3c0: Irp stack trace.
> >> >> cmd flg cl Device File Completion-Context
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> [0, 0] 0 0 00000000 00000000 00000000-00000000
> >> >>
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
> >> >> \Driver\MYDRV
> >> >> Args: 00000000 00000000 00000000 00000000
> >> >> kd> dt nt!_IO_STACK_LOCATION 8598a254
> >> >> +0x000 MajorFunction : 0x2 ‘’
> >> >> +0x001 MinorFunction : 0 ‘’
> >> >> +0x002 Flags : 0 ‘’
> >> >> +0x003 Control : 0 ‘’
> >> >> +0x004 Parameters : __unnamed
> >> >> +0x014 DeviceObject : 0x85999a88
> >> >> +0x018 FileObject : 0xf64fcc1c
> >> >> +0x01c CompletionRoutine : (null)
> >> >> +0x020 Context : (null)
> >> >> kd> !object f64fcc1c
> >> >> Object: f64fcc1c Type: (8619a560) File
> >> >> ObjectHeader: f64fcc04
> >> >> HandleCount: 0 PointerCount: 2
> >> >> Directory Object: 00000000 Name: \protected\subdir9787
> >> >> {HarddiskVolume1}
> >> >>
> >> >>
> >> >>
> >> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> >> >> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the
> >>ref
> >> >> count is non-zero. Something is definitely screwed up. What does
> >>your
> >> >> stack trace look like?
> >> >>
> >> >> Regards,
> >> >>
> >> >> Tony
> >> >>
> >> >> Tony Mason
> >> >> Consulting Partner
> >> >> OSR Open Systems Resources, Inc.
> >> >> http://www.osr.com
> >> >>
> >> >> Looking forward to seeing you at the Next OSR File Systems Class
> >>April
> >> >> 4, 2004 in Boston!
> >> >>
> >> >> -----Original Message-----
> >> >> From: xxxxx@lists.osr.com
> >> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> >> Sent: Wednesday, January 19, 2005 10:56 AM
> >> >> To: ntfsd redirect
> >> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >> >>
> >> >> Hi Tony
> >> >>
> >> >> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
> >> >> the
> >> >> circumstances where I had the suspicion that the reference count
> >>might
> >> >> be
> >> >> non zero. Then !object on the file object address in windbag … here
> >>we
> >> >> are
> >> >> with PointerCount 2 … any comment?
> >> >>
> >> >> kd> !object f64fcc1c
> >> >> Object: f64fcc1c Type: (8619a560) File
> >> >> ObjectHeader: f64fcc04
> >> >> HandleCount: 0 PointerCount: 2
> >> >> Directory Object: 00000000 Name: \protected\subdir9787
> >>{HarddiskVolume1}
> >> >>
> >> >>
> >> >> Thanks
> >> >> Lyndon
> >> >>
> >> >> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> >> >> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
> >> >> reference count, there is certainly a bug - and at that in the OS.
> >>If
> >> >> you are seeing an IRP_MJ_CLOSE on a file object that you referenced
> >>but
> >> >> did not dereference, that’s a bug, but it means some driver or OS
> >> >> component is decrementing the reference count when it should not be
> >> >> doing so. The most likely culprit will be on the stack at the time
> >>you
> >> >> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
> >> >> evidence of guilt.
> >> >>
> >> >> Reference counting problems, particularly in global objects, are a
> >> >> nightmare to track down. You might wish to start by debugging the
> >> >> reference count in your driver just to make sure you aren’t releasing
> >>it
> >> >> incorrectly in some other location. Beyond that, I suspect that
> >> >> debugging this issue is going to require some rather ugly effort.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Tony
> >> >>
> >> >> Tony Mason
> >> >> Consulting Partner
> >> >> OSR Open Systems Resources, Inc.
> >> >> http://www.osr.com
> >> >>
> >> >> Looking forward to seeing you at the Next OSR File Systems Class
> >>April
> >> >> 4, 2004 in Boston!
> >> >> -----Original Message-----
> >> >> From: xxxxx@lists.osr.com
> >> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> >> >> Sent: Wednesday, January 19, 2005 8:02 AM
> >> >> To: ntfsd redirect
> >> >> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
> >> >>
> >> >>>> It seems to be that on Windows 2003 is some circumstances I do
> >>see
> >> >>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
> >> >> seen
> >> >>>> this
> >> >>>> on Windows 2000.
> >> >>>
> >> >>> Maybe some bugs?
> >> >>
> >> >> Okay well I believe I have established as a fact that this does
> >>happen
> >> >> on
> >> >> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
> >> >>
> >> >> Maybe it helps if I describe a specific scenario. I process
> >> >> IRP_MJ_CLEANUP
> >> >> where the ObReferenceObject(FileObject) occurs in the filter driver
> >> >> dispatch
> >> >> routine, and the at the same time the non paged pool seems to be near
> >>to
> >> >>
> >> >> exhaustion as my filter cannot allocate from non paged pool.
> >> >>
> >> >> Cheers
> >> >> Lyndon
> >> >>
> >> >>
> >> >>
> >> >> —
> >> >> Questions? First check the IFS FAQ at
> >> >> https://www.osronline.com/article.cfm?id=17
> >> >>
> >> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
> >> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >> >>
> >> >>
> >> >>
> >> >> —
> >> >> Questions? First check the IFS FAQ at
> >> >> https://www.osronline.com/article.cfm?id=17
> >> >>
> >> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
> >> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >> >>
> >> >>
> >> >>
> >> >> —
> >> >> Questions? First check the IFS FAQ at
> >> >> https://www.osronline.com/article.cfm?id=17
> >> >>
> >> >> You are currently subscribed to ntfsd as: xxxxx@osr.com
> >> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >> >>
> >> >>
> >> >>
> >> >> —
> >> >> Questions? First check the IFS FAQ at
> >> >> https://www.osronline.com/article.cfm?id=17
> >> >>
> >> >> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> >> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >> >
> >> >
> >>
> >>
> >>
> >>—
> >>Questions? First check the IFS FAQ at
> >>https://www.osronline.com/article.cfm?id=17
> >>
> >>You are currently subscribed to ntfsd as: xxxxx@osr.com
> >>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >>
> >>—
> >>Questions? First check the IFS FAQ at
> >>https://www.osronline.com/article.cfm?id=17
> >>
> >>You are currently subscribed to ntfsd as: xxxxx@privtek.com
> >>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@privtek.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

[Dan_Partelly]

As far as I seen, as well, there are only on the stack.
Tony’s method with stackl limits should doit. There are only a distinct
set of operations where the IO manager does not need a full blown
file object, and can use a phony one on stack.
There are not so many cases. I even think I isolated all the cases and noted
them somewhere. Now if I could only find my notes …

Dan

----- Original Message -----
From: “Lyndon J Clarke”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, January 19, 2005 11:37 PM
Subject: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

> Hi Tony
>
> Yes, I had assumed IoGetStackLimits to test if the file ahem object
> address is within the stack, hence my question regarding whether it is
> possible that such non objects are not in the stack. You see, what worries
> me a bit, in what you have said is the “… as far as I’ve ever seen …”
> part. I was aware that paged pool would be a violation - perhaps I had
> over specified my comment and thus thrown a red herring to kind
> responders.
>
> Cheers
> Lyndon
>
> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> No, these phony file objects are only on the stack as far as I’ve ever
> seen - further you are allowed to assume any object is from non-paged
> pool, so allocation from paged pool would violate that constraint.
>
> As for detecting it, how about calling IoGetStackLimits and checking to
> determine if the object is within that range? There are cases where
> IoGetStackLimits doesn’t work (in a DPC) but that should never apply to
> any case in which you’d be called.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2004 in Boston!
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Wednesday, January 19, 2005 3:51 PM
> To: ntfsd redirect
> Subject: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>
> I see. I imagine, although it might not be a wonderful thng to do, that
> a
> phony file object can also be built on allocated paged pool?
>
> “Dan Partelly” wrote in message
> news:xxxxx@ntfsd…
>> Ive been bitten by this long ago. There is no documented way
>> to distinguish between a real file object and a phony one,
>> built on stack. There are some undocumented ways, tough.
>> IIRC , such a file object will not have the Ob manager object
>> header. Single step through IopParseDevice() to see exactly how this
>> object is allocated.
>>
>> Dan
>>
>>
>>
>> ----- Original Message -----
>> From: “Lyndon J Clarke”
>> Newsgroups: ntfsd
>> To: “Windows File Systems Devs Interest List”
>> Sent: Wednesday, January 19, 2005 9:01 PM
>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>
>>
>>> Thanks Tony
>>>
>>> I read the article about IoCancelFileOpen. I am afraid my searches
> with
>>> “temporary file object” did not yield much of help to me. I assume
> you
>>> inferred the file object is on the stack from the address; fair
> enough.
>>> Is there a “better” way at runtime that we can determine that the
>>> ObReferenceObject(FileObject) will be ignored? For example some
>>> FileObject->Flags that signals we have one of these kinds of beasts
> on
>>> our hands?
>>>
>>> Cheers
>>> Lyndon
>>>
>>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>>> The file object is on the stack - it is a “temporary” file object
> used
>>> during the query. Bumping the reference count on it is ignored,
> which
>>> is why you are seeing the “premature” close operation.
>>>
>>> There should be discussion on this in the archive, as well as some
>>> articles on OSR Online about this very issue (I talked about it when
> we
>>> had the issue with IoCancelFileOpen).
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> Tony Mason
>>> Consulting Partner
>>> OSR Open Systems Resources, Inc.
>>> http://www.osr.com
>>>
>>> Looking forward to seeing you at the Next OSR File Systems Class
> April
>>> 4, 2004 in Boston!
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>>> Sent: Wednesday, January 19, 2005 12:33 PM
>>> To: ntfsd redirect
>>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>>
>>> Tony
>>>
>>> Thanks for your attention. Here is stack, the irp, the irp stack
>>> location,
>>> and the file object … sorry about the java … i think the
>>> understandable action starts with kernel32!GetFileAttributesW …
>>>
>>> Cheers
>>> Lyndon
>>>
>>> kd> kv f 100
>>> Memory ChildEBP RetAddr Args to Child
>>> f64fc8a4 f60e14f4 f64fcc1c f60e3780 f64fc99c nt!DbgBreakPoint
>>> (FPO:
>>> [0,0,0])
>>> 18 f64fc8bc f60e19fb f64fc8ec f64fcc1c 85999a88
>>> MYDRV!MyCacheFile+0x9c
>>> (CONV: stdcall) [–snip–]
>>> 44 f64fc900 f60d3b00 f64fc99c f64fcc1c f64fc9c0
>>> MYDRV!MyFilterFile+0xa9
>>> (CONV: stdcall) [–snip–]
>>> c4 f64fc9c4 f60d4b5a 85999a88 8598a0a0 85e02f10
>>> MYDRV!MyHookRoutine+0x3be (CONV: stdcall) [–snip–]
>>> 10 f64fc9d4 804e0e0d 85999a88 8598a0a0 8598a0b0
>>> MYDRV!MyDispatch+0x1e
>>> (FPO: [2,0,0]) (CONV: stdcall) [–snip–]
>>> 10 f64fc9e4 80578ced f64fcc1c 00000000 f64fcccc
>>> nt!IofCallDriver+0x3f
>>> (FPO: [0,0,0])
>>> 38 f64fca1c 8058cde0 004fcc1c 861bce18 85e00fd4
>>> nt!IopDeleteFile+0x138
>>> ec f64fcb08 80573600 861bce30 00000000 85e00f30
>>> nt!IopParseDevice+0xe4f
>>> 78 f64fcb80 80577b80 00000000 f64fcbc0 00000040
>>> nt!ObpLookupObjectName+0x541
>>> 54 f64fcbd4 80585a35 00000000 00000000 ffffff01
>>> nt!ObOpenObjectByName+0xe8
>>> 180 f64fcd54 804e7a8c 0eb8fb14 0eb8faec 00000000
>>> nt!NtQueryAttributesFile+0xe6
>>> 0 f64fcd54 7ffe0304 0eb8fb14 0eb8faec 00000000
>>> nt!KiSystemService+0xcb
>>> (FPO: [0,0] TrapFrame @ f64fcd64)
>>> 0eb8facc 77f42cb7 77e426bd 0eb8fb14 0eb8faec
>>> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>>> 4 0eb8fad0 77e426bd 0eb8fb14 0eb8faec 0eea99a8
>>> ntdll!ZwQueryAttributesFile+0xc (FPO: [2,0,0])
>>> 64 0eb8fb34 6d227c79 0eea99a8 00002624 037e6820
>>> kernel32!GetFileAttributesW+0x58 (FPO: [Non-Fpo])
>>> WARNING: Stack unwind information not available. Following frames may
> be
>>>
>>> wrong.
>>> 1c 0eb8fb50 00ec923d 0f381bd4 0eb8fb74 0eb8fb70
>>> java!Java_java_io_WinNTFileSystem_getBooleanAttributes+0x4d
>>> 18 0eb8fb68 00fbb014 037e6820 032685a0 02ee1488 0xec923d
>>> 68 0eb8fbd0 00fbb370 037e6820 036a76f8 039c8b48 0xfbb014
>>> 68 0eb8fc38 00fbb370 036a95d0 036a76f8 02ec0740 0xfbb370
>>> 68 0eb8fca0 00dbb480 0333bb90 036a76f8 0eb8fcbc 0xfbb370
>>> 14 0eb8fcb4 00d62bd3 0333bc38 02f200e0 0eb8fcc4 0xdbb480
>>> 2c 0eb8fce0 00d62bd3 00000000 036a76f8 0eb8fcf0 0xd62bd3
>>> 2c 0eb8fd0c 00d62bd3 036a76f8 0eb8fd18 073425af 0xd62bd3
>>> 28 0eb8fd34 00d600ee 00000000 00000000 00000000 0xd62bd3
>>> 28 0eb8fd5c 6d3ae143 0eb8fd90 0eb8ff38 0000000a 0xd600ee
>>> 88 0eb8fde4 6d3e3e9f 0000000a 00000000 0eb8fe94 jvm+0x6e143
>>> 3c 0eb8fe20 6d3ae057 6d3ae05b 0eb8ff30 0eb8fe44
>>> jvm!JVM_FindSignal+0x1d4a0
>>> 54 0eb8fe74 6d3addd4 0eb8ff30 0b8ef344 6d457b60 jvm+0x6e057
>>> 7c 0eb8fef0 6d3c2e46 0eb8ff30 0b8ef340 0b8ef344 jvm+0x6ddd4
>>> 50 0eb8ff40 6d407c41 0f381b48 0f381b48 0f381b48
>>> jvm!JVM_StartThread+0x1cd
>>> 2c 0eb8ff6c 6d407c11 00000000 0f381b48 6d3e2d25
>>> jvm!JVM_RegisterPerfMethods+0x20ffc
>>> 18 0eb8ff84 77bc91ed 0f381b48 00000000 00000000
>>> jvm!JVM_RegisterPerfMethods+0x20fcc
>>> 34 0eb8ffb8 77e4a990 0eee5138 00000000 00000000
>>> msvcrt!_endthreadex+0x95 (FPO: [Non-Fpo])
>>> 34 0eb8ffec 00000000 77bc917e 0eee5138 00000000
>>> kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo])
>>>
>>> kd> !irp 8598a0a0
>>> Irp is active with 10 stacks 10 is current (= 0x8598a254)
>>> No Mdl Thread 8599c3c0: Irp stack trace.
>>> cmd flg cl Device File Completion-Context
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>> [0, 0] 0 0 00000000 00000000 00000000-00000000
>>>
>>> Args: 00000000 00000000 00000000 00000000
>>>>[2, 0] 0 0 85999a88 f64fcc1c 00000000-00000000
>>> \Driver\MYDRV
>>> Args: 00000000 00000000 00000000 00000000
>>> kd> dt nt!_IO_STACK_LOCATION 8598a254
>>> +0x000 MajorFunction : 0x2 ‘’
>>> +0x001 MinorFunction : 0 ‘’
>>> +0x002 Flags : 0 ‘’
>>> +0x003 Control : 0 ‘’
>>> +0x004 Parameters : __unnamed
>>> +0x014 DeviceObject : 0x85999a88
>>> +0x018 FileObject : 0xf64fcc1c
>>> +0x01c CompletionRoutine : (null)
>>> +0x020 Context : (null)
>>> kd> !object f64fcc1c
>>> Object: f64fcc1c Type: (8619a560) File
>>> ObjectHeader: f64fcc04
>>> HandleCount: 0 PointerCount: 2
>>> Directory Object: 00000000 Name: \protected\subdir9787
>>> {HarddiskVolume1}
>>>
>>>
>>>
>>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>>> That’s bad. This suggests you are getting an IRP_MJ_CLOSE when the
> ref
>>> count is non-zero. Something is definitely screwed up. What does
> your
>>> stack trace look like?
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> Tony Mason
>>> Consulting Partner
>>> OSR Open Systems Resources, Inc.
>>> http://www.osr.com
>>>
>>> Looking forward to seeing you at the Next OSR File Systems Class
> April
>>> 4, 2004 in Boston!
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>>> Sent: Wednesday, January 19, 2005 10:56 AM
>>> To: ntfsd redirect
>>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>>
>>> Hi Tony
>>>
>>> So, i put a break point in the IRP_MJ_CLOSE dispatch handler code, in
>>> the
>>> circumstances where I had the suspicion that the reference count
> might
>>> be
>>> non zero. Then !object on the file object address in windbag … here
> we
>>> are
>>> with PointerCount 2 … any comment?
>>>
>>> kd> !object f64fcc1c
>>> Object: f64fcc1c Type: (8619a560) File
>>> ObjectHeader: f64fcc04
>>> HandleCount: 0 PointerCount: 2
>>> Directory Object: 00000000 Name: \protected\subdir9787
> {HarddiskVolume1}
>>>
>>>
>>> Thanks
>>> Lyndon
>>>
>>> “Tony Mason” wrote in message news:xxxxx@ntfsd…
>>> If you are seeing IRP_MJ_CLOSE on a file object with a non-zero
>>> reference count, there is certainly a bug - and at that in the OS.
> If
>>> you are seeing an IRP_MJ_CLOSE on a file object that you referenced
> but
>>> did not dereference, that’s a bug, but it means some driver or OS
>>> component is decrementing the reference count when it should not be
>>> doing so. The most likely culprit will be on the stack at the time
> you
>>> see the erroneous IRP_MJ_CLOSE call, but of course “likely” isn’t
>>> evidence of guilt.
>>>
>>> Reference counting problems, particularly in global objects, are a
>>> nightmare to track down. You might wish to start by debugging the
>>> reference count in your driver just to make sure you aren’t releasing
> it
>>> incorrectly in some other location. Beyond that, I suspect that
>>> debugging this issue is going to require some rather ugly effort.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> Tony Mason
>>> Consulting Partner
>>> OSR Open Systems Resources, Inc.
>>> http://www.osr.com
>>>
>>> Looking forward to seeing you at the Next OSR File Systems Class
> April
>>> 4, 2004 in Boston!
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>>> Sent: Wednesday, January 19, 2005 8:02 AM
>>> To: ntfsd redirect
>>> Subject: Re:[ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT
>>>
>>>>> It seems to be that on Windows 2003 is some circumstances I do
> see
>>>>> IRP_MJ_CLOSE between such points in time; in contrast I have never
>>> seen
>>>>> this
>>>>> on Windows 2000.
>>>>
>>>> Maybe some bugs?
>>>
>>> Okay well I believe I have established as a fact that this does
> happen
>>> on
>>> Windows 2003, so, are we saying, maybe some bugs in Windows 2003?
>>>
>>> Maybe it helps if I describe a specific scenario. I process
>>> IRP_MJ_CLEANUP
>>> where the ObReferenceObject(FileObject) occurs in the filter driver
>>> dispatch
>>> routine, and the at the same time the non paged pool seems to be near
> to
>>>
>>> exhaustion as my filter cannot allocate from non paged pool.
>>>
>>> Cheers
>>> Lyndon
>>>
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@osr.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com