IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

NTFSD
21

Hi Tony,

Bumping the reference count on it is ignored,

When you say “ignored”, don’t you actually mean “corrupting the stack”?

  • Dan.

At 01:38 PM 1/19/2005 -0500, Tony Mason wrote:

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 :wink: … 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: unknown lmsubst tag argument: ‘’
>To unsubscribe send a blank email to xxxxx@lists.osr.com

22

Well, we are certainly off in the “esoteric and complex side effects”
arena.

First, this occurs in the IRP_MJ_CREATE path which is seldom (if ever)
posted. However, if it proves to be the case that is HAS BEEN posted,
you could just retrieve the stack limits of the original thread by
constructing and sending an APC to that specific thread. Of course,
there is the rather annoying issue that the APC queuing routines are not
in the IFS Kit, but have been publicly documented (there is a Microsoft
Systems Journal article that describes them, for example). Google turns
up plenty of references to KeInsertQueueApc. Not a pretty solution, but
then again this is not a pretty problem, either, so the solution is
probably fitting in some fashion.

I’m still curious why you are finding it necessary to ref count this
file object in the IRP_MJ_CREATE path. Perhaps there is a better way of
detecting that this is one of those screw cases in THIS path, rather
than later in the IRP_MJ_CLOSE path.

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 Dan Kyler
Sent: Wednesday, January 19, 2005 5:12 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

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 :wink: … 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

—
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

23

There are very few cases:

  • A call to IoFastQueryNetworkAttributes
  • A call to ZwQueryAttributesFile
  • A call to ZwQueryFullAttributesFile
  • A call to ZwDeleteFile

The first is in ntifs.h. The second and third are undocumented native
API calls (but you can see them in the debugger when you breakpoint for
this condition) and the last is also in ntifs.h. Generally, I summarize
and say: query operations (FILE_NETWORK_OPEN_INFORMATION) and file
delete operations.

The point is that none of these need a full file object - the network
query operations are supposed to be optimized FAST paths, the delete
path should destroy the file. None of them should create persistent
state. That it screws up file system filter drivers is just an
unexpected side-effect.

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 Dan Partelly
Sent: Wednesday, January 19, 2005 5:15 PM
To: ntfsd redirect
Subject: Re: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of
FILE_OBJECT

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 :wink: … 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

—
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

24

Actually, no, it doesn’t corrupt the stack - there IS storage allocated
for the object header in front of the file object. It is just that when
done with the “file object” the I/O Manager directly calls to delete the
file object (IopDeleteFile) as we saw on Lyndon’s stack trace.

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 Dan Kyler
Sent: Wednesday, January 19, 2005 5:33 PM
To: ntfsd redirect
Subject: RE: [ntfsd] IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

Hi Tony,

Bumping the reference count on it is ignored,

When you say “ignored”, don’t you actually mean “corrupting the stack”?

  • Dan.

At 01:38 PM 1/19/2005 -0500, Tony Mason wrote:

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 :wink: … 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: unknown lmsubst tag argument:
‘’
>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

25

Tony

I wasnt sure if the question about Create path was targetted at self, or
even where the Create path came into the discussion, so, anwyay. In fact, I
have never needed to and have never done ref count of the file object in the
Create path; the same applies to the Close path. There are some code paths
in between where I might ref count a file object.

Cheers
Lyndon

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Well, we are certainly off in the “esoteric and complex side effects”
arena.

First, this occurs in the IRP_MJ_CREATE path which is seldom (if ever)
posted. However, if it proves to be the case that is HAS BEEN posted,
you could just retrieve the stack limits of the original thread by
constructing and sending an APC to that specific thread. Of course,
there is the rather annoying issue that the APC queuing routines are not
in the IFS Kit, but have been publicly documented (there is a Microsoft
Systems Journal article that describes them, for example). Google turns
up plenty of references to KeInsertQueueApc. Not a pretty solution, but
then again this is not a pretty problem, either, so the solution is
probably fitting in some fashion.

I’m still curious why you are finding it necessary to ref count this
file object in the IRP_MJ_CREATE path. Perhaps there is a better way of
detecting that this is one of those screw cases in THIS path, rather
than later in the IRP_MJ_CLOSE path.

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 Dan Kyler
Sent: Wednesday, January 19, 2005 5:12 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:Re:IRP_MJ_CLOSE and ReferenceCount of FILE_OBJECT

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 :wink: … 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

—
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

26

>There are very few cases:

  • A call to IoFastQueryNetworkAttributes
  • A call to ZwQueryAttributesFile
  • A call to ZwQueryFullAttributesFile
  • A call to ZwDeleteFile

This is, in fact, all about “do something with the file given its pathname”
operations.

These operations needs pathname parsing, correct? By they want to avoid full
MJ_CREATE path (or at least give the FSD the chance of avoiding it, since
pathname parsing with this purpose can be possibly done in simpler way by the
FSD), so they use FastIoQueryOpen instead of MJ_CREATE IRP (if possible).

The fake on-stack file object is passed to FastIoQueryOpen, it sets it up.
Then - usually - one of the FastIoQueryInformation routines is called, all
without an IRP.

This is the general conceptual picture. Ask Tony more for gory details :slight_smile:

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

27

FYI: The use of stack based File Objects will be removed from longhorn.
This does not help you today but going forward this issue will go away.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, January 19, 2005 3:12 PM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of
FILE_OBJECT

There are very few cases:

  • A call to IoFastQueryNetworkAttributes
  • A call to ZwQueryAttributesFile
  • A call to ZwQueryFullAttributesFile
  • A call to ZwDeleteFile

The first is in ntifs.h. The second and third are undocumented native
API calls (but you can see them in the debugger when you breakpoint for
this condition) and the last is also in ntifs.h. Generally, I summarize
and say: query operations (FILE_NETWORK_OPEN_INFORMATION) and file
delete operations.

The point is that none of these need a full file object - the network
query operations are supposed to be optimized FAST paths, the delete
path should destroy the file. None of them should create persistent
state. That it screws up file system filter drivers is just an
unexpected side-effect.

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 Dan Partelly
Sent: Wednesday, January 19, 2005 5:15 PM
To: ntfsd redirect
Subject: Re: Re:[ntfsd] Re:IRP_MJ_CLOSE and ReferenceCount of
FILE_OBJECT

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 :wink: … 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

—
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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com