problem with IoCancelFileOpen workaround

NTFSD
1

Hi all,
I’m getting an assertion while debugging an implementation of
the streamfile create cloning method that is a workaround for the
IoCancelFileOpen issues. It happens in
FsRtlPTeardownPerFileObjectContexts. I’m pretty much doing what Ted
Hess posted in an an earlier email called “Postscript on closing
FileObjects created by IoCreateStreamFile”. The one thing that I’m
doing differently is dereferencing the streamfile object in the
completion routine of the real create. However, this seems to cause
problems. Is there some glaring reason why this wouldn’t work? Below
is a stack trace of what happened before the assert. It only seems to
happen when the SR filter re-enters the stack.

Thanks for any help,
Matt

*** Assertion failed: IsListEmpty( &ctxCtrl->FilterContexts)
*** Source File: d:\xpsp1\base\ntos\fsrtl\filtrctx.c, line 784

Break repeatedly, break Once, Ignore, terminate Process, or terminate
Thread (boipt)? o
Execute ‘.cxr F77FCF4C’ to dump context
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80aaad28 cc int 3
kd> !thread
THREAD 81f07b20 Cid 0310.0468 Teb: 7ffa5000 Win32Thread: 00000000
RUNNING on processor 0
IRP List:
82e56e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
82e6ce48: (0006,01b4) Flags: 40000884 Mdl: 00000000
Impersonation token: e1ab0940 (Level Impersonation)
Owning Process 81ecab78
Wait Start TickCount 622864 Elapsed Ticks: 3
Context Switch Count 184
UserTime 00:00:00.0430
KernelTime 00:00:01.0712
Start Address kernel32!BaseThreadStartThunk (0x77e7d342)
Win32 Start Address schedsvc!PfSvProcessTraceThread (0x751d93ee)
Stack Init f77ff000 Current f77fce44 Base f77ff000 Limit f77fc000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f77fcf38 80aac853 00000000 81f07d80 81f24848 nt!DbgBreakPoint (FPO:
[0,0,0])
f77fd21c 80aac880 80afd09e 80afd07a 00000310 nt!RtlAssert2+0xd8 (FPO:
[Non-Fpo])
f77fd238 80afd133 80afd09e 80afd07a 00000310 nt!RtlAssert+0x16 (FPO:
[Non-Fpo])
f77fd258 80b1dbe8 81f24848 80004528 81f24830
nt!FsRtlPTeardownPerFileObjectContexts+0x6e (FPO: [Non-Fpo])
f77fd294 80b90aa4 00f24848 00000000 81f24830 nt!IopDeleteFile+0x1c0
(FPO: [Non-Fpo])
f77fd2b8 80aa2829 81f24848 00000000 82e56e48
nt!ObpRemoveObjectRoutine+0x1dc (FPO: [Non-Fpo])
f77fd2d4 f706678d 00000001 00000001 81f376f8
nt!ObfDereferenceObject+0x8c (FPO: [Non-Fpo])
f77fd304 80cae2fe 81fa9030 82e56e48 82540ff0
foo!FooCreateCompletion+0x27b (FPO: [Non-Fpo]) (CONV: stdcall)
[c:…\foobar.c @ 1935]
f77fd328 80a23560 81fa9030 82e56e48 f77fd36c
nt!IovpLocalCompletionRoutine+0xb2 (FPO: [Non-Fpo])
f77fd358 80cae738 00000000 82e56e48 00000000 nt!IopfCompleteRequest+0xf4
(FPO: [Non-Fpo])
f77fd3c0 bae9b692 00000000 f77fd460 baebc5a2 nt!IovCompleteRequest+0x90
(FPO: [Non-Fpo])
f77fd3cc baebc5a2 81fa9330 82e56e48 00000000
Ntfs!NtfsCompleteRequest+0xaa (FPO: [3,0,3])
f77fd4a8 80a20812 820f8770 82e56e48 820f8770 Ntfs!NtfsFsdCreate+0x4e7
f77fd4c0 80cae110 00004020 00000001 82e56e48 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd4e4 baf3e2aa 820f9198 82e56e48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fd530 80a20812 820f9250 81e87f80 820f9198 sr!SrCreate+0x12a (FPO:
[Non-Fpo])
f77fd548 80cae110 82e56fd0 82e56ff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd56c f7065ee8 81fa9030 82e56e48 00000001 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdc2c 80a20812 81fa9030 82e56e48 81fa9030 foo!FooCreate+0xf66 (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1660]
f77fdc44 80cae110 82e56e58 82e56e48 81e87f80 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fdc68 80b1cd5b 820df720 80004528 81e5ee00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdd4c 80b96877 820df738 00000000 81e5ee58 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77fddc4 80b91570 00000000 f77fde04 00000240
nt!ObpLookupObjectName+0x59b (FPO: [Non-Fpo])
f77fde18 80b0acdc 00000000 00000000 8200af00 nt!ObOpenObjectByName+0x13e
(FPO: [Non-Fpo])
f77fde94 80b0b5e4 f77fe05c 00100000 f77fe040 nt!IopCreateFile+0x43b
f77fdedc baf42416 f77fe05c 00100000 f77fe040
nt!IoCreateFileSpecifyDeviceObjectHint+0x4c (FPO: [Non-Fpo])
f77fe068 baf42abb 820f9250 00000000 f77fe251
sr!SrpExpandPathOfFileName+0xa8 (FPO: [Non-Fpo])
f77fe088 baf42af5 820f9250 81e7e2e0 f77fe0f4
sr!SrpGetFileNameFromFileObject+0xe5 (FPO: [Non-Fpo])
f77fe0a0 baf42b7a 820f9250 81e7e2e0 00140008 sr!SrpExpandFileName+0x33
(FPO: [Non-Fpo])
f77fe0c8 baf3c19a 820f9250 81e7e2e0 00000000 sr!SrIsFileEligible+0x58
(FPO: [Non-Fpo])
f77fe254 baf3e25e 820f9250 81e7e2e0 00140008 sr!SrCreateContext+0xe4
(FPO: [Non-Fpo])
f77fe2b4 80a20812 820f9250 81e7e2e0 820f9198 sr!SrCreate+0xde (FPO:
[Non-Fpo])
f77fe2cc 80cae110 82e6cfd0 82e6cff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fe2f0 f7066d9d 81fa9030 82e6ce48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fe364 f706555e 81fa9030 82e6ce48 f77fe728 foo!FooCloneCreate+0x2ec
(FPO: [Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 2126]
f77fea30 80a20812 81fa9030 82e6ce48 81fa9030 foo!FooCreate+0x5dc (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1443]
f77fea48 80cae110 82e6ce58 82e6ce48 81e501a8 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fea6c 80b1cd5b 820df720 80004528 81ff7b00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77feb50 80b96877 820df738 00000000 81ff7af8 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77febc8 80b91570 00000000 f77fec08 00000040
nt!ObpLookupObjectName+0x59b (FPO: [Non-Fpo])

2

From where you ASSERTed it looks like your FileObject has an attached
context from somewhere - Probably the FSD or another filter. This is why I
think it is important to release all references to your FO before issuing
the original CREATE. Note: ObDereferenceObject issues the CLOSE which
traverses the entire stack not just what is below your filter.

Also, be aware that if your CREATE of the cloned FO succeeded, you must, at
least, issue a CLEANUP before issuing the original CREATE. Otherwise, you
are left with a sharing problem that may make the original CREATE fail when
it should have succeeded and a possible cache reference to your FO that CC
and/or MM will try to use.

My original intent was to probe the FSD to check for an already opened
instance of the file via the FsContext returned and to be transparent to the
FSD for subsequent (for-real) CREATEs. I’m sure there are issues associated
with holding your file object open while issuing the original CREATE, but I
haven’t tried that.

/ted

-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Wednesday, October 15, 2003 4:26 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem with IoCancelFileOpen workaround

Hi all,
I’m getting an assertion while debugging an implementation of the
streamfile create cloning method that is a workaround for the
IoCancelFileOpen issues. It happens in FsRtlPTeardownPerFileObjectContexts.
I’m pretty much doing what Ted Hess posted in an an earlier email called
“Postscript on closing FileObjects created by IoCreateStreamFile”. The one
thing that I’m doing differently is dereferencing the streamfile object in
the completion routine of the real create. However, this seems to cause
problems. Is there some glaring reason why this wouldn’t work? Below is a
stack trace of what happened before the assert. It only seems to happen
when the SR filter re-enters the stack.

Thanks for any help,
Matt

*** Assertion failed: IsListEmpty( &ctxCtrl->FilterContexts)
*** Source File: d:\xpsp1\base\ntos\fsrtl\filtrctx.c, line 784

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread
(boipt)? o Execute ‘.cxr F77FCF4C’ to dump context Break instruction
exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80aaad28 cc int 3
kd> !thread
THREAD 81f07b20 Cid 0310.0468 Teb: 7ffa5000 Win32Thread: 00000000 RUNNING
on processor 0 IRP List:
82e56e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
82e6ce48: (0006,01b4) Flags: 40000884 Mdl: 00000000 Impersonation
token: e1ab0940 (Level Impersonation)
Owning Process 81ecab78
Wait Start TickCount 622864 Elapsed Ticks: 3
Context Switch Count 184
UserTime 00:00:00.0430
KernelTime 00:00:01.0712
Start Address kernel32!BaseThreadStartThunk (0x77e7d342)
Win32 Start Address schedsvc!PfSvProcessTraceThread (0x751d93ee) Stack Init
f77ff000 Current f77fce44 Base f77ff000 Limit f77fc000 Call 0 Priority 8
BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f77fcf38 80aac853 00000000 81f07d80 81f24848 nt!DbgBreakPoint (FPO:
[0,0,0])
f77fd21c 80aac880 80afd09e 80afd07a 00000310 nt!RtlAssert2+0xd8 (FPO:
[Non-Fpo])
f77fd238 80afd133 80afd09e 80afd07a 00000310 nt!RtlAssert+0x16 (FPO:
[Non-Fpo])
f77fd258 80b1dbe8 81f24848 80004528 81f24830
nt!FsRtlPTeardownPerFileObjectContexts+0x6e (FPO: [Non-Fpo]) f77fd294
80b90aa4 00f24848 00000000 81f24830 nt!IopDeleteFile+0x1c0
(FPO: [Non-Fpo])
f77fd2b8 80aa2829 81f24848 00000000 82e56e48 nt!ObpRemoveObjectRoutine+0x1dc
(FPO: [Non-Fpo]) f77fd2d4 f706678d 00000001 00000001 81f376f8
nt!ObfDereferenceObject+0x8c (FPO: [Non-Fpo]) f77fd304 80cae2fe 81fa9030
82e56e48 82540ff0 foo!FooCreateCompletion+0x27b (FPO: [Non-Fpo]) (CONV:
stdcall) [c:…\foobar.c @ 1935] f77fd328 80a23560 81fa9030 82e56e48
f77fd36c nt!IovpLocalCompletionRoutine+0xb2 (FPO: [Non-Fpo]) f77fd358
80cae738 00000000 82e56e48 00000000 nt!IopfCompleteRequest+0xf4
(FPO: [Non-Fpo])
f77fd3c0 bae9b692 00000000 f77fd460 baebc5a2 nt!IovCompleteRequest+0x90
(FPO: [Non-Fpo])
f77fd3cc baebc5a2 81fa9330 82e56e48 00000000 Ntfs!NtfsCompleteRequest+0xaa
(FPO: [3,0,3]) f77fd4a8 80a20812 820f8770 82e56e48 820f8770
Ntfs!NtfsFsdCreate+0x4e7 f77fd4c0 80cae110 00004020 00000001 82e56e48
nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd4e4 baf3e2aa 820f9198 82e56e48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fd530 80a20812 820f9250 81e87f80 820f9198 sr!SrCreate+0x12a (FPO:
[Non-Fpo])
f77fd548 80cae110 82e56fd0 82e56ff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd56c f7065ee8 81fa9030 82e56e48 00000001 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdc2c 80a20812 81fa9030 82e56e48 81fa9030 foo!FooCreate+0xf66 (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1660]
f77fdc44 80cae110 82e56e58 82e56e48 81e87f80 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fdc68 80b1cd5b 820df720 80004528 81e5ee00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdd4c 80b96877 820df738 00000000 81e5ee58 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77fddc4 80b91570 00000000 f77fde04 00000240 nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo]) f77fde18 80b0acdc 00000000 00000000 8200af00
nt!ObOpenObjectByName+0x13e
(FPO: [Non-Fpo])
f77fde94 80b0b5e4 f77fe05c 00100000 f77fe040 nt!IopCreateFile+0x43b f77fdedc
baf42416 f77fe05c 00100000 f77fe040
nt!IoCreateFileSpecifyDeviceObjectHint+0x4c (FPO: [Non-Fpo]) f77fe068
baf42abb 820f9250 00000000 f77fe251 sr!SrpExpandPathOfFileName+0xa8 (FPO:
[Non-Fpo]) f77fe088 baf42af5 820f9250 81e7e2e0 f77fe0f4
sr!SrpGetFileNameFromFileObject+0xe5 (FPO: [Non-Fpo]) f77fe0a0 baf42b7a
820f9250 81e7e2e0 00140008 sr!SrpExpandFileName+0x33
(FPO: [Non-Fpo])
f77fe0c8 baf3c19a 820f9250 81e7e2e0 00000000 sr!SrIsFileEligible+0x58
(FPO: [Non-Fpo])
f77fe254 baf3e25e 820f9250 81e7e2e0 00140008 sr!SrCreateContext+0xe4
(FPO: [Non-Fpo])
f77fe2b4 80a20812 820f9250 81e7e2e0 820f9198 sr!SrCreate+0xde (FPO:
[Non-Fpo])
f77fe2cc 80cae110 82e6cfd0 82e6cff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fe2f0 f7066d9d 81fa9030 82e6ce48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fe364 f706555e 81fa9030 82e6ce48 f77fe728 foo!FooCloneCreate+0x2ec
(FPO: [Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 2126] f77fea30 80a20812
81fa9030 82e6ce48 81fa9030 foo!FooCreate+0x5dc (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1443]
f77fea48 80cae110 82e6ce58 82e6ce48 81e501a8 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fea6c 80b1cd5b 820df720 80004528 81ff7b00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77feb50 80b96877 820df738 00000000 81ff7af8 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77febc8 80b91570 00000000 f77fec08 00000040 nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo])

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

3

When you say “probe the FSD to check for an already opened instance of
the file via the FsContext returned” do you mean that you can assume
that the FsContext returned for the stream file will be the same as the
one returned for the “real” create? I want to make sure that this is
the case, and thought that it may not be unless I held the reference…

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Wednesday, October 15, 2003 7:33 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: problem with IoCancelFileOpen workaround

From where you ASSERTed it looks like your FileObject has an attached
context from somewhere - Probably the FSD or another filter. This is why
I think it is important to release all references to your FO before
issuing the original CREATE. Note: ObDereferenceObject issues the CLOSE
which traverses the entire stack not just what is below your filter.

Also, be aware that if your CREATE of the cloned FO succeeded, you must,
at least, issue a CLEANUP before issuing the original CREATE. Otherwise,
you are left with a sharing problem that may make the original CREATE
fail when it should have succeeded and a possible cache reference to
your FO that CC and/or MM will try to use.

My original intent was to probe the FSD to check for an already opened
instance of the file via the FsContext returned and to be transparent to
the FSD for subsequent (for-real) CREATEs. I’m sure there are issues
associated with holding your file object open while issuing the original
CREATE, but I haven’t tried that.

/ted

-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Wednesday, October 15, 2003 4:26 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem with IoCancelFileOpen workaround

Hi all,
I’m getting an assertion while debugging an implementation of
the streamfile create cloning method that is a workaround for the
IoCancelFileOpen issues. It happens in
FsRtlPTeardownPerFileObjectContexts.
I’m pretty much doing what Ted Hess posted in an an earlier email called
“Postscript on closing FileObjects created by IoCreateStreamFile”. The
one thing that I’m doing differently is dereferencing the streamfile
object in the completion routine of the real create. However, this
seems to cause problems. Is there some glaring reason why this wouldn’t
work? Below is a stack trace of what happened before the assert. It
only seems to happen when the SR filter re-enters the stack.

Thanks for any help,
Matt

*** Assertion failed: IsListEmpty( &ctxCtrl->FilterContexts)
*** Source File: d:\xpsp1\base\ntos\fsrtl\filtrctx.c, line 784

Break repeatedly, break Once, Ignore, terminate Process, or terminate
Thread (boipt)? o Execute ‘.cxr F77FCF4C’ to dump context Break
instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80aaad28 cc int 3
kd> !thread
THREAD 81f07b20 Cid 0310.0468 Teb: 7ffa5000 Win32Thread: 00000000
RUNNING on processor 0 IRP List:
82e56e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
82e6ce48: (0006,01b4) Flags: 40000884 Mdl: 00000000 Impersonation
token: e1ab0940 (Level Impersonation)
Owning Process 81ecab78
Wait Start TickCount 622864 Elapsed Ticks: 3
Context Switch Count 184
UserTime 00:00:00.0430
KernelTime 00:00:01.0712
Start Address kernel32!BaseThreadStartThunk (0x77e7d342)
Win32 Start Address schedsvc!PfSvProcessTraceThread (0x751d93ee) Stack
Init f77ff000 Current f77fce44 Base f77ff000 Limit f77fc000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f77fcf38 80aac853 00000000 81f07d80 81f24848 nt!DbgBreakPoint (FPO:
[0,0,0])
f77fd21c 80aac880 80afd09e 80afd07a 00000310 nt!RtlAssert2+0xd8 (FPO:
[Non-Fpo])
f77fd238 80afd133 80afd09e 80afd07a 00000310 nt!RtlAssert+0x16 (FPO:
[Non-Fpo])
f77fd258 80b1dbe8 81f24848 80004528 81f24830
nt!FsRtlPTeardownPerFileObjectContexts+0x6e (FPO: [Non-Fpo]) f77fd294
80b90aa4 00f24848 00000000 81f24830 nt!IopDeleteFile+0x1c0
(FPO: [Non-Fpo])
f77fd2b8 80aa2829 81f24848 00000000 82e56e48
nt!ObpRemoveObjectRoutine+0x1dc
(FPO: [Non-Fpo]) f77fd2d4 f706678d 00000001 00000001 81f376f8
nt!ObfDereferenceObject+0x8c (FPO: [Non-Fpo]) f77fd304 80cae2fe 81fa9030
82e56e48 82540ff0 foo!FooCreateCompletion+0x27b (FPO: [Non-Fpo]) (CONV:
stdcall) [c:…\foobar.c @ 1935] f77fd328 80a23560 81fa9030 82e56e48
f77fd36c nt!IovpLocalCompletionRoutine+0xb2 (FPO: [Non-Fpo]) f77fd358
80cae738 00000000 82e56e48 00000000 nt!IopfCompleteRequest+0xf4
(FPO: [Non-Fpo])
f77fd3c0 bae9b692 00000000 f77fd460 baebc5a2 nt!IovCompleteRequest+0x90
(FPO: [Non-Fpo])
f77fd3cc baebc5a2 81fa9330 82e56e48 00000000
Ntfs!NtfsCompleteRequest+0xaa
(FPO: [3,0,3]) f77fd4a8 80a20812 820f8770 82e56e48 820f8770
Ntfs!NtfsFsdCreate+0x4e7 f77fd4c0 80cae110 00004020 00000001 82e56e48
nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd4e4 baf3e2aa 820f9198 82e56e48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fd530 80a20812 820f9250 81e87f80 820f9198 sr!SrCreate+0x12a (FPO:
[Non-Fpo])
f77fd548 80cae110 82e56fd0 82e56ff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd56c f7065ee8 81fa9030 82e56e48 00000001 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdc2c 80a20812 81fa9030 82e56e48 81fa9030 foo!FooCreate+0xf66 (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1660]
f77fdc44 80cae110 82e56e58 82e56e48 81e87f80 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fdc68 80b1cd5b 820df720 80004528 81e5ee00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdd4c 80b96877 820df738 00000000 81e5ee58 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77fddc4 80b91570 00000000 f77fde04 00000240
nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo]) f77fde18 80b0acdc 00000000 00000000 8200af00
nt!ObOpenObjectByName+0x13e
(FPO: [Non-Fpo])
f77fde94 80b0b5e4 f77fe05c 00100000 f77fe040 nt!IopCreateFile+0x43b
f77fdedc baf42416 f77fe05c 00100000 f77fe040
nt!IoCreateFileSpecifyDeviceObjectHint+0x4c (FPO: [Non-Fpo]) f77fe068
baf42abb 820f9250 00000000 f77fe251 sr!SrpExpandPathOfFileName+0xa8
(FPO:
[Non-Fpo]) f77fe088 baf42af5 820f9250 81e7e2e0 f77fe0f4
sr!SrpGetFileNameFromFileObject+0xe5 (FPO: [Non-Fpo]) f77fe0a0 baf42b7a
820f9250 81e7e2e0 00140008 sr!SrpExpandFileName+0x33
(FPO: [Non-Fpo])
f77fe0c8 baf3c19a 820f9250 81e7e2e0 00000000 sr!SrIsFileEligible+0x58
(FPO: [Non-Fpo])
f77fe254 baf3e25e 820f9250 81e7e2e0 00140008 sr!SrCreateContext+0xe4
(FPO: [Non-Fpo])
f77fe2b4 80a20812 820f9250 81e7e2e0 820f9198 sr!SrCreate+0xde (FPO:
[Non-Fpo])
f77fe2cc 80cae110 82e6cfd0 82e6cff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fe2f0 f7066d9d 81fa9030 82e6ce48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fe364 f706555e 81fa9030 82e6ce48 f77fe728 foo!FooCloneCreate+0x2ec
(FPO: [Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 2126] f77fea30
80a20812 81fa9030 82e6ce48 81fa9030 foo!FooCreate+0x5dc (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1443]
f77fea48 80cae110 82e6ce58 82e6ce48 81e501a8 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fea6c 80b1cd5b 820df720 80004528 81ff7b00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77feb50 80b96877 820df738 00000000 81ff7af8 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77febc8 80b91570 00000000 f77fec08 00000040
nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo])

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

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

4

What I was looking for is whether the file is already opened before I let
the original CREATE proceed. I need to check if I am already tracking this
file and use some of the data that I already have for it. I need to lookup
the FsContext in my local data for this case.

To answer your question: You cannot assume the FsContext returned by the
caller’s (orignal) CREATE will be the same FsContext after you close your
reference to the file. You need to deal with the issues of tracking and
ref-counting FOs & FCBs elsewhere and not PreCreate.

Hope this helps… /ted

-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Thursday, October 16, 2003 11:13 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: problem with IoCancelFileOpen workaround

When you say “probe the FSD to check for an already opened instance of the
file via the FsContext returned” do you mean that you can assume that the
FsContext returned for the stream file will be the same as the one returned
for the “real” create? I want to make sure that this is the case, and
thought that it may not be unless I held the reference…

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Wednesday, October 15, 2003 7:33 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: problem with IoCancelFileOpen workaround

From where you ASSERTed it looks like your FileObject has an attached
context from somewhere - Probably the FSD or another filter. This is why I
think it is important to release all references to your FO before issuing
the original CREATE. Note: ObDereferenceObject issues the CLOSE which
traverses the entire stack not just what is below your filter.

Also, be aware that if your CREATE of the cloned FO succeeded, you must, at
least, issue a CLEANUP before issuing the original CREATE. Otherwise, you
are left with a sharing problem that may make the original CREATE fail when
it should have succeeded and a possible cache reference to your FO that CC
and/or MM will try to use.

My original intent was to probe the FSD to check for an already opened
instance of the file via the FsContext returned and to be transparent to the
FSD for subsequent (for-real) CREATEs. I’m sure there are issues associated
with holding your file object open while issuing the original CREATE, but I
haven’t tried that.

/ted

-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Wednesday, October 15, 2003 4:26 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem with IoCancelFileOpen workaround

Hi all,
I’m getting an assertion while debugging an implementation of the
streamfile create cloning method that is a workaround for the
IoCancelFileOpen issues. It happens in FsRtlPTeardownPerFileObjectContexts.
I’m pretty much doing what Ted Hess posted in an an earlier email called
“Postscript on closing FileObjects created by IoCreateStreamFile”. The one
thing that I’m doing differently is dereferencing the streamfile object in
the completion routine of the real create. However, this seems to cause
problems. Is there some glaring reason why this wouldn’t work? Below is a
stack trace of what happened before the assert. It only seems to happen
when the SR filter re-enters the stack.

Thanks for any help,
Matt

*** Assertion failed: IsListEmpty( &ctxCtrl->FilterContexts)
*** Source File: d:\xpsp1\base\ntos\fsrtl\filtrctx.c, line 784

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread
(boipt)? o Execute ‘.cxr F77FCF4C’ to dump context Break instruction
exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80aaad28 cc int 3
kd> !thread
THREAD 81f07b20 Cid 0310.0468 Teb: 7ffa5000 Win32Thread: 00000000 RUNNING
on processor 0 IRP List:
82e56e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
82e6ce48: (0006,01b4) Flags: 40000884 Mdl: 00000000 Impersonation
token: e1ab0940 (Level Impersonation)
Owning Process 81ecab78
Wait Start TickCount 622864 Elapsed Ticks: 3
Context Switch Count 184
UserTime 00:00:00.0430
KernelTime 00:00:01.0712
Start Address kernel32!BaseThreadStartThunk (0x77e7d342)
Win32 Start Address schedsvc!PfSvProcessTraceThread (0x751d93ee) Stack Init
f77ff000 Current f77fce44 Base f77ff000 Limit f77fc000 Call 0 Priority 8
BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f77fcf38 80aac853 00000000 81f07d80 81f24848 nt!DbgBreakPoint (FPO:
[0,0,0])
f77fd21c 80aac880 80afd09e 80afd07a 00000310 nt!RtlAssert2+0xd8 (FPO:
[Non-Fpo])
f77fd238 80afd133 80afd09e 80afd07a 00000310 nt!RtlAssert+0x16 (FPO:
[Non-Fpo])
f77fd258 80b1dbe8 81f24848 80004528 81f24830
nt!FsRtlPTeardownPerFileObjectContexts+0x6e (FPO: [Non-Fpo]) f77fd294
80b90aa4 00f24848 00000000 81f24830 nt!IopDeleteFile+0x1c0
(FPO: [Non-Fpo])
f77fd2b8 80aa2829 81f24848 00000000 82e56e48 nt!ObpRemoveObjectRoutine+0x1dc
(FPO: [Non-Fpo]) f77fd2d4 f706678d 00000001 00000001 81f376f8
nt!ObfDereferenceObject+0x8c (FPO: [Non-Fpo]) f77fd304 80cae2fe 81fa9030
82e56e48 82540ff0 foo!FooCreateCompletion+0x27b (FPO: [Non-Fpo]) (CONV:
stdcall) [c:…\foobar.c @ 1935] f77fd328 80a23560 81fa9030 82e56e48
f77fd36c nt!IovpLocalCompletionRoutine+0xb2 (FPO: [Non-Fpo]) f77fd358
80cae738 00000000 82e56e48 00000000 nt!IopfCompleteRequest+0xf4
(FPO: [Non-Fpo])
f77fd3c0 bae9b692 00000000 f77fd460 baebc5a2 nt!IovCompleteRequest+0x90
(FPO: [Non-Fpo])
f77fd3cc baebc5a2 81fa9330 82e56e48 00000000 Ntfs!NtfsCompleteRequest+0xaa
(FPO: [3,0,3]) f77fd4a8 80a20812 820f8770 82e56e48 820f8770
Ntfs!NtfsFsdCreate+0x4e7 f77fd4c0 80cae110 00004020 00000001 82e56e48
nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd4e4 baf3e2aa 820f9198 82e56e48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fd530 80a20812 820f9250 81e87f80 820f9198 sr!SrCreate+0x12a (FPO:
[Non-Fpo])
f77fd548 80cae110 82e56fd0 82e56ff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd56c f7065ee8 81fa9030 82e56e48 00000001 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdc2c 80a20812 81fa9030 82e56e48 81fa9030 foo!FooCreate+0xf66 (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1660]
f77fdc44 80cae110 82e56e58 82e56e48 81e87f80 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fdc68 80b1cd5b 820df720 80004528 81e5ee00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdd4c 80b96877 820df738 00000000 81e5ee58 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77fddc4 80b91570 00000000 f77fde04 00000240 nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo]) f77fde18 80b0acdc 00000000 00000000 8200af00
nt!ObOpenObjectByName+0x13e
(FPO: [Non-Fpo])
f77fde94 80b0b5e4 f77fe05c 00100000 f77fe040 nt!IopCreateFile+0x43b f77fdedc
baf42416 f77fe05c 00100000 f77fe040
nt!IoCreateFileSpecifyDeviceObjectHint+0x4c (FPO: [Non-Fpo]) f77fe068
baf42abb 820f9250 00000000 f77fe251 sr!SrpExpandPathOfFileName+0xa8
(FPO:
[Non-Fpo]) f77fe088 baf42af5 820f9250 81e7e2e0 f77fe0f4
sr!SrpGetFileNameFromFileObject+0xe5 (FPO: [Non-Fpo]) f77fe0a0 baf42b7a
820f9250 81e7e2e0 00140008 sr!SrpExpandFileName+0x33
(FPO: [Non-Fpo])
f77fe0c8 baf3c19a 820f9250 81e7e2e0 00000000 sr!SrIsFileEligible+0x58
(FPO: [Non-Fpo])
f77fe254 baf3e25e 820f9250 81e7e2e0 00140008 sr!SrCreateContext+0xe4
(FPO: [Non-Fpo])
f77fe2b4 80a20812 820f9250 81e7e2e0 820f9198 sr!SrCreate+0xde (FPO:
[Non-Fpo])
f77fe2cc 80cae110 82e6cfd0 82e6cff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fe2f0 f7066d9d 81fa9030 82e6ce48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fe364 f706555e 81fa9030 82e6ce48 f77fe728 foo!FooCloneCreate+0x2ec
(FPO: [Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 2126] f77fea30 80a20812
81fa9030 82e6ce48 81fa9030 foo!FooCreate+0x5dc (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1443]
f77fea48 80cae110 82e6ce58 82e6ce48 81e501a8 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fea6c 80b1cd5b 820df720 80004528 81ff7b00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77feb50 80b96877 820df738 00000000 81ff7af8 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77febc8 80b91570 00000000 f77fec08 00000040 nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo])

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

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

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

5

Ok, I see what you are saying. I guess I’m wondering how can you
guarantee that after you call ObDereference() on your streamfile, that
the file will still be “already opened” when the real create hits the
FSD. Does this make sense?

The reason I was doing that was that I thought that holding the onto the
reference to the streamfileobject would make sure that the FsContext
vals would be the same after the real create has gone through the FSD,
since the FsContext is unique per file stream, and the FSD can’t change
the FsContext val with FileObjects referencing it.

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Thursday, October 16, 2003 12:50 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: problem with IoCancelFileOpen workaround

What I was looking for is whether the file is already opened before I
let the original CREATE proceed. I need to check if I am already
tracking this file and use some of the data that I already have for it.
I need to lookup the FsContext in my local data for this case.

To answer your question: You cannot assume the FsContext returned by the
caller’s (orignal) CREATE will be the same FsContext after you close
your reference to the file. You need to deal with the issues of tracking
and ref-counting FOs & FCBs elsewhere and not PreCreate.

Hope this helps… /ted

-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Thursday, October 16, 2003 11:13 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: problem with IoCancelFileOpen workaround

When you say “probe the FSD to check for an already opened instance of
the file via the FsContext returned” do you mean that you can assume
that the FsContext returned for the stream file will be the same as the
one returned for the “real” create? I want to make sure that this is
the case, and thought that it may not be unless I held the reference…

Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Wednesday, October 15, 2003 7:33 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RE: problem with IoCancelFileOpen workaround

From where you ASSERTed it looks like your FileObject has an attached
context from somewhere - Probably the FSD or another filter. This is why
I think it is important to release all references to your FO before
issuing the original CREATE. Note: ObDereferenceObject issues the CLOSE
which traverses the entire stack not just what is below your filter.

Also, be aware that if your CREATE of the cloned FO succeeded, you must,
at least, issue a CLEANUP before issuing the original CREATE. Otherwise,
you are left with a sharing problem that may make the original CREATE
fail when it should have succeeded and a possible cache reference to
your FO that CC and/or MM will try to use.

My original intent was to probe the FSD to check for an already opened
instance of the file via the FsContext returned and to be transparent to
the FSD for subsequent (for-real) CREATEs. I’m sure there are issues
associated with holding your file object open while issuing the original
CREATE, but I haven’t tried that.

/ted

-----Original Message-----
From: Matthew N. White [mailto:xxxxx@bitarmor.com]
Sent: Wednesday, October 15, 2003 4:26 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem with IoCancelFileOpen workaround

Hi all,
I’m getting an assertion while debugging an implementation of
the streamfile create cloning method that is a workaround for the
IoCancelFileOpen issues. It happens in
FsRtlPTeardownPerFileObjectContexts.
I’m pretty much doing what Ted Hess posted in an an earlier email called
“Postscript on closing FileObjects created by IoCreateStreamFile”. The
one thing that I’m doing differently is dereferencing the streamfile
object in the completion routine of the real create. However, this
seems to cause problems. Is there some glaring reason why this wouldn’t
work? Below is a stack trace of what happened before the assert. It
only seems to happen when the SR filter re-enters the stack.

Thanks for any help,
Matt

*** Assertion failed: IsListEmpty( &ctxCtrl->FilterContexts)
*** Source File: d:\xpsp1\base\ntos\fsrtl\filtrctx.c, line 784

Break repeatedly, break Once, Ignore, terminate Process, or terminate
Thread (boipt)? o Execute ‘.cxr F77FCF4C’ to dump context Break
instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80aaad28 cc int 3
kd> !thread
THREAD 81f07b20 Cid 0310.0468 Teb: 7ffa5000 Win32Thread: 00000000
RUNNING on processor 0 IRP List:
82e56e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
82e6ce48: (0006,01b4) Flags: 40000884 Mdl: 00000000 Impersonation
token: e1ab0940 (Level Impersonation)
Owning Process 81ecab78
Wait Start TickCount 622864 Elapsed Ticks: 3
Context Switch Count 184
UserTime 00:00:00.0430
KernelTime 00:00:01.0712
Start Address kernel32!BaseThreadStartThunk (0x77e7d342)
Win32 Start Address schedsvc!PfSvProcessTraceThread (0x751d93ee) Stack
Init f77ff000 Current f77fce44 Base f77ff000 Limit f77fc000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f77fcf38 80aac853 00000000 81f07d80 81f24848 nt!DbgBreakPoint (FPO:
[0,0,0])
f77fd21c 80aac880 80afd09e 80afd07a 00000310 nt!RtlAssert2+0xd8 (FPO:
[Non-Fpo])
f77fd238 80afd133 80afd09e 80afd07a 00000310 nt!RtlAssert+0x16 (FPO:
[Non-Fpo])
f77fd258 80b1dbe8 81f24848 80004528 81f24830
nt!FsRtlPTeardownPerFileObjectContexts+0x6e (FPO: [Non-Fpo]) f77fd294
80b90aa4 00f24848 00000000 81f24830 nt!IopDeleteFile+0x1c0
(FPO: [Non-Fpo])
f77fd2b8 80aa2829 81f24848 00000000 82e56e48
nt!ObpRemoveObjectRoutine+0x1dc
(FPO: [Non-Fpo]) f77fd2d4 f706678d 00000001 00000001 81f376f8
nt!ObfDereferenceObject+0x8c (FPO: [Non-Fpo]) f77fd304 80cae2fe 81fa9030
82e56e48 82540ff0 foo!FooCreateCompletion+0x27b (FPO: [Non-Fpo]) (CONV:
stdcall) [c:…\foobar.c @ 1935] f77fd328 80a23560 81fa9030 82e56e48
f77fd36c nt!IovpLocalCompletionRoutine+0xb2 (FPO: [Non-Fpo]) f77fd358
80cae738 00000000 82e56e48 00000000 nt!IopfCompleteRequest+0xf4
(FPO: [Non-Fpo])
f77fd3c0 bae9b692 00000000 f77fd460 baebc5a2 nt!IovCompleteRequest+0x90
(FPO: [Non-Fpo])
f77fd3cc baebc5a2 81fa9330 82e56e48 00000000
Ntfs!NtfsCompleteRequest+0xaa
(FPO: [3,0,3]) f77fd4a8 80a20812 820f8770 82e56e48 820f8770
Ntfs!NtfsFsdCreate+0x4e7 f77fd4c0 80cae110 00004020 00000001 82e56e48
nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd4e4 baf3e2aa 820f9198 82e56e48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fd530 80a20812 820f9250 81e87f80 820f9198 sr!SrCreate+0x12a (FPO:
[Non-Fpo])
f77fd548 80cae110 82e56fd0 82e56ff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fd56c f7065ee8 81fa9030 82e56e48 00000001 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdc2c 80a20812 81fa9030 82e56e48 81fa9030 foo!FooCreate+0xf66 (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1660]
f77fdc44 80cae110 82e56e58 82e56e48 81e87f80 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fdc68 80b1cd5b 820df720 80004528 81e5ee00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fdd4c 80b96877 820df738 00000000 81e5ee58 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77fddc4 80b91570 00000000 f77fde04 00000240
nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo]) f77fde18 80b0acdc 00000000 00000000 8200af00
nt!ObOpenObjectByName+0x13e
(FPO: [Non-Fpo])
f77fde94 80b0b5e4 f77fe05c 00100000 f77fe040 nt!IopCreateFile+0x43b
f77fdedc baf42416 f77fe05c 00100000 f77fe040
nt!IoCreateFileSpecifyDeviceObjectHint+0x4c (FPO: [Non-Fpo]) f77fe068
baf42abb 820f9250 00000000 f77fe251 sr!SrpExpandPathOfFileName+0xa8
(FPO:
[Non-Fpo]) f77fe088 baf42af5 820f9250 81e7e2e0 f77fe0f4
sr!SrpGetFileNameFromFileObject+0xe5 (FPO: [Non-Fpo]) f77fe0a0 baf42b7a
820f9250 81e7e2e0 00140008 sr!SrpExpandFileName+0x33
(FPO: [Non-Fpo])
f77fe0c8 baf3c19a 820f9250 81e7e2e0 00000000 sr!SrIsFileEligible+0x58
(FPO: [Non-Fpo])
f77fe254 baf3e25e 820f9250 81e7e2e0 00140008 sr!SrCreateContext+0xe4
(FPO: [Non-Fpo])
f77fe2b4 80a20812 820f9250 81e7e2e0 820f9198 sr!SrCreate+0xde (FPO:
[Non-Fpo])
f77fe2cc 80cae110 82e6cfd0 82e6cff4 00000000 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fe2f0 f7066d9d 81fa9030 82e6ce48 00000000 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77fe364 f706555e 81fa9030 82e6ce48 f77fe728 foo!FooCloneCreate+0x2ec
(FPO: [Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 2126] f77fea30
80a20812 81fa9030 82e6ce48 81fa9030 foo!FooCreate+0x5dc (FPO:
[Non-Fpo]) (CONV: stdcall) [c:.…\foobar.c @ 1443]
f77fea48 80cae110 82e6ce58 82e6ce48 81e501a8 nt!IopfCallDriver+0x4f
(FPO: [0,0,3])
f77fea6c 80b1cd5b 820df720 80004528 81ff7b00 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
f77feb50 80b96877 820df738 00000000 81ff7af8 nt!IopParseDevice+0xb84
(FPO: [Non-Fpo])
f77febc8 80b91570 00000000 f77fec08 00000040
nt!ObpLookupObjectName+0x59b
(FPO: [Non-Fpo])

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

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

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

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