no more stack locations and DFS

I’m seeing some crashes with NO_MORE_IRP_STACK_LOCATIONS as the fault when a
file rename is performed inside a dfs share ( WinXp sp2 )

The irp with the problem looks like:

kd> !irp 817e2bf8

Irp is active with 5 stacks 0 is current (= 0x817934c0)

No Mdl System buffer = 81979840 Thread 00000064: Irp stack trace.

cmd flg cl Device File Completion-Context

[6, 0] 0 e0 817934c0 8188e128 f995a822-81945af0 Success Error Cancel

\FileSystem\FltMgr
fltmgr!FltpNoFilterCallbackCompletion

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 1 818d7ee8 8188e128 00000000-00000000 pending

\FileSystem\FltMgr

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 e0 818e1948 8188e128 f995a822-81951230 Success Error Cancel

\Driver\SymEvent fltmgr!FltpNoFilterCallbackCompletion

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 1 818e7ee8 8188e128 00000000-00000000 pending

\FileSystem\FltMgr

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 0 81b2e508 8188e128 00000000-00000000

\FileSystem\Mup

Args: 00000064 0000000a 81a4cf28
00000000

And the redirector stack is:

!DevObj !DrvObj !DevExt ObjectName

818e7ee8 \FileSystem\FltMgr 818e7fa0

818e1948 \Driver\SymEvent 818e1a00

818d7ee8 \FileSystem\FltMgr 818d7fa0

817934c0 \FileSystem\FltMgr 81793578

8196a158 \FileSystem\MRxSmb 8196a210 LanmanRedirector

!DevObj !DrvObj !DevExt ObjectName

81b2e508 \FileSystem\Mup 81b2e5c0 Root

Create irps work without any issue, even though mup uses the same device as
the target of the IoCallDriver (818e7ee8). In that case, the irp looks like:

Irp is active with 5 stacks 3 is current (= 0x818d2540)

No Mdl Thread 81978020: 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 e1 818d7ee8 819ffc90 f83320b0-f6cc6420 Success Error Cancel
pending

\FileSystem\FltMgr
SYMEVENT!SYMEvent_GetVMDataPtr

Args: f6cc6704 01000158 00070080
00000000

[0, 0] 0 e0 818e1948 819ffc90 f985ba4d-817f3008 Success Error Cancel

\Driver\SymEvent Mup!DnrCompleteFileOpen

Args: f6cc6704 01000158 00070080
00000000

[0, 0] 0 0 81b2e508 819ffc90 00000000-00000000

\FileSystem\Mup

Args: f6cc6704 01000158 00070080
00000000

From what I’ve seen, it looks like the only thing required to reproduce the
crash is a couple of minifilters and a legacy filter on lanman, so the
number of devices on the stack is bigger than the default stack size for
windfs (that seems to be 5).

Even with dfs skipping filters at the top of the redirector stack (that
doesn’t seems to happen on this test), there seems to be a bug on either mup
or the filter manager.

The actual stack:

f6cc846c 8053225b nt!RtlpBreakWithStatusInstruction

f6cc84b8 80532d2e nt!KiBugCheckDebugBreak+0x19

f6cc8898 8053331e nt!KeBugCheck2+0x574

f6cc88b8 8051bbe3 nt!KeBugCheckEx+0x1b

f6cc88d0 f995ab7d nt!IopfCallDriver+0x17

f6cc88e4 f995affb fltmgr!FltpPassThrough+0x147

f6cc8914 804e37f7 fltmgr!FltpDispatch+0xf3

f6cc8924 f995ab7d nt!IopfCallDriver+0x31

f6cc8938 f995affb fltmgr!FltpPassThrough+0x147

f6cc8968 804e37f7 fltmgr!FltpDispatch+0xf3

f6cc8978 f8332074 nt!IopfCallDriver+0x31

WARNING: Stack unwind information not available. Following frames may be
wrong.

f6cc8a00 f995affb SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4

f6cc8a30 804e37f7 fltmgr!FltpDispatch+0xf3

f6cc8a40 f986bd5a nt!IopfCallDriver+0x31

f6cc8a84 f986be55 Mup!DfsCommonSetInformation+0xa3

f6cc8ac4 804e37f7 Mup!DfsFsdSetInformation+0x63

f6cc8ad4 8058c8c0 nt!IopfCallDriver+0x31

f6cc8b80 f80a26f0 nt!NtSetInformationFile+0x56f

Ricardo

This is an issue with MUP. They maintain their own IRP cache of a fixed
size stack. There is a registry setting (I don’t remember what it is)
that can be specified so MUP will allocate IRPs with bigger stacks.

This is something I have complained about many times to the owners of
MUP.

Neal Christiansen
Microsoft NTFS Development 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 Ricardo Vargas
Sent: Tuesday, January 23, 2007 5:19 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] no more stack locations and DFS

I’m seeing some crashes with NO_MORE_IRP_STACK_LOCATIONS as the fault
when a
file rename is performed inside a dfs share ( WinXp sp2 )

The irp with the problem looks like:

kd> !irp 817e2bf8

Irp is active with 5 stacks 0 is current (= 0x817934c0)

No Mdl System buffer = 81979840 Thread 00000064: Irp stack trace.

cmd flg cl Device File Completion-Context

[6, 0] 0 e0 817934c0 8188e128 f995a822-81945af0 Success Error
Cancel

\FileSystem\FltMgr
fltmgr!FltpNoFilterCallbackCompletion

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 1 818d7ee8 8188e128 00000000-00000000 pending

\FileSystem\FltMgr

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 e0 818e1948 8188e128 f995a822-81951230 Success Error
Cancel

\Driver\SymEvent
fltmgr!FltpNoFilterCallbackCompletion

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 1 818e7ee8 8188e128 00000000-00000000 pending

\FileSystem\FltMgr

Args: 00000064 0000000a 81a4cf28
00000000

[6, 0] 0 0 81b2e508 8188e128 00000000-00000000

\FileSystem\Mup

Args: 00000064 0000000a 81a4cf28
00000000

And the redirector stack is:

!DevObj !DrvObj !DevExt ObjectName

818e7ee8 \FileSystem\FltMgr 818e7fa0

818e1948 \Driver\SymEvent 818e1a00

818d7ee8 \FileSystem\FltMgr 818d7fa0

817934c0 \FileSystem\FltMgr 81793578

8196a158 \FileSystem\MRxSmb 8196a210 LanmanRedirector

!DevObj !DrvObj !DevExt ObjectName

81b2e508 \FileSystem\Mup 81b2e5c0 Root

Create irps work without any issue, even though mup uses the same device
as
the target of the IoCallDriver (818e7ee8). In that case, the irp looks
like:

Irp is active with 5 stacks 3 is current (= 0x818d2540)

No Mdl Thread 81978020: 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 e1 818d7ee8 819ffc90 f83320b0-f6cc6420 Success Error
Cancel
pending

\FileSystem\FltMgr
SYMEVENT!SYMEvent_GetVMDataPtr

Args: f6cc6704 01000158 00070080
00000000

[0, 0] 0 e0 818e1948 819ffc90 f985ba4d-817f3008 Success Error
Cancel

\Driver\SymEvent Mup!DnrCompleteFileOpen

Args: f6cc6704 01000158 00070080
00000000

[0, 0] 0 0 81b2e508 819ffc90 00000000-00000000

\FileSystem\Mup

Args: f6cc6704 01000158 00070080
00000000

From what I’ve seen, it looks like the only thing required to reproduce
the
crash is a couple of minifilters and a legacy filter on lanman, so the
number of devices on the stack is bigger than the default stack size for

windfs (that seems to be 5).

Even with dfs skipping filters at the top of the redirector stack (that
doesn’t seems to happen on this test), there seems to be a bug on either
mup
or the filter manager.

The actual stack:

f6cc846c 8053225b nt!RtlpBreakWithStatusInstruction

f6cc84b8 80532d2e nt!KiBugCheckDebugBreak+0x19

f6cc8898 8053331e nt!KeBugCheck2+0x574

f6cc88b8 8051bbe3 nt!KeBugCheckEx+0x1b

f6cc88d0 f995ab7d nt!IopfCallDriver+0x17

f6cc88e4 f995affb fltmgr!FltpPassThrough+0x147

f6cc8914 804e37f7 fltmgr!FltpDispatch+0xf3

f6cc8924 f995ab7d nt!IopfCallDriver+0x31

f6cc8938 f995affb fltmgr!FltpPassThrough+0x147

f6cc8968 804e37f7 fltmgr!FltpDispatch+0xf3

f6cc8978 f8332074 nt!IopfCallDriver+0x31

WARNING: Stack unwind information not available. Following frames may be

wrong.

f6cc8a00 f995affb SYMEVENT!SYMEvent_GetVMDataPtr+0x86d4

f6cc8a30 804e37f7 fltmgr!FltpDispatch+0xf3

f6cc8a40 f986bd5a nt!IopfCallDriver+0x31

f6cc8a84 f986be55 Mup!DfsCommonSetInformation+0xa3

f6cc8ac4 804e37f7 Mup!DfsFsdSetInformation+0x63

f6cc8ad4 8058c8c0 nt!IopfCallDriver+0x31

f6cc8b80 f80a26f0 nt!NtSetInformationFile+0x56f

Ricardo


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

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