Re: Bug Check 0x50: PAGE_FAULT_IN_NONPAGED_AREA in NTFS.?

Hi.

Just a guess:

MsNfs completes the IRP with STATUS_REPARSE…modifies and reissues the IRP
from its completion routine with FltReissueSynchronousIo. May be you do not
honor STATUS_REPARSE in one of your completion routines which causes the
crash…somehow?

wrote news:xxxxx@ntfsd…
Hi,

We have a system crashing regulary inside NTFS. The crash stack also lists
couple of other file system drivers. From my analysis it looks like the
system is crashing inside NTFS as an improper length is being passed in the
fileobject->FileName. As far as both the drviers FSD1 and FSD2 are concerned
they do not alter the fileName length, and they also receive the invalid
file length in the fileobject while processing the request. I am still not
able to understand from the dump file who exactly could be corrupting the
filename length. Would appreciate any kind help or comments on this.

Here are the details:
kd> kv
*** Stack trace for last set context - .thread/.cxr resets it

ChildEBP RetAddr Args to Child
f66f1604 f71c6ef8 863f11a0 8636d008 f66f1644 Ntfs!NtfsCommonCreate+0xc33
(FPO: [Non-Fpo]) (CONV: stdcall)
f66f1708 8081d5a3 85e83020 8636d008 8636d008 Ntfs!NtfsFsdCreate+0x17d (FPO:
[Non-Fpo]) (CONV: stdcall)
f66f171c f724c54d 8636d008 00000000 8654e5d0 nt!IofCallDriver+0x45 (FPO:
[Non-Fpo]) (CONV: fastcall)
f66f174c 8081d5a3 862dc9b0 8636d008 8636d174 fltmgr!FltpCreate+0x1d9 (FPO:
[Non-Fpo]) (CONV: stdcall)
f66f1760 f69d69a3 8636d1bc 863d6030 857480d0 nt!IofCallDriver+0x45 (FPO:
[Non-Fpo]) (CONV: fastcall)
WARNING: Stack unwind information not available. Following frames may be
wrong.
f66f17cc 8081d5a3 85ed2ed8 8636d008 8636d008 FSD2+0xd9a3
f66f17e0 f69a4914 863b56a0 8636d008 f66f185c nt!IofCallDriver+0x45 (FPO:
[Non-Fpo]) (CONV: fastcall)
f66f180c f69af90b 863b56a0 8636d008 862eae00 FSD1!+0x2914
f66f185c f69a3d40 863b56a0 8636d008 f69a458c FSD1+0xd90b
f66f1888 f723eb25 00000000 85edf264 8575199c FSD1+0x1d40
f66f18ac f724f2c2 f66f18cc 85eceb28 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b (FPO: [Non-Fpo])
(CONV: stdcall)
f66f18e4 f62c6495 862ca4a0 00000000 85751940
fltmgr!FltReissueSynchronousIo+0x150 (FPO: [Non-Fpo]) (CONV: stdcall)
f66f1950 f723bb73 85fe8728 f66f1974 85760150
msnfsflt!MsNfsFltPostOpCreate+0x14b (FPO: [Non-Fpo]) (CONV: stdcall)
f66f19b8 f723dfc2 00751940 00000000 85751940
fltmgr!FltpPerformPostCallbacks+0x1c5 (FPO: [Non-Fpo]) (CONV: stdcall)
f66f19cc f723e4f1 85751940 8636d008 f66f1a0c
fltmgr!FltpProcessIoCompletion+0x10 (FPO: [Non-Fpo]) (CONV: stdcall)
f66f19dc f723eb83 85eceb28 8636d008 85751940
fltmgr!FltpPassThroughCompletion+0x89 (FPO: [Non-Fpo]) (CONV: stdcall)
f66f1a0c f724c5de f66f1a2c c0000043 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269 (FPO: [Non-Fpo])
(CONV: stdcall)
f66f1a48 8081d5a3 85eceb28 8636d008 8636d008 fltmgr!FltpCreate+0x26a (FPO:
[Non-Fpo]) (CONV: stdcall)
f66f1a5c 808f0f1b f66f1c04 865444a8 00000000 nt!IofCallDriver+0x45 (FPO:
[Non-Fpo]) (CONV: fastcall)
f66f1b44 8092f71c 865444c0 00000000 862f88c0 nt!IopParseDevice+0xa35 (FPO:
[Non-Fpo]) (CONV: stdcall)

The problem stems from the length set in the FileObject->FileName on the
stack gets changed from 0x56 to 0x01. This is the IRP at the time of the
crash with the file object highlighted.

kd> !irp 0x8636d008

Irp is active with 11 stacks 8 is current (= 0x8636d174)
No Mdl: No System Buffer: Thread 8639bc00: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 2 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 c0000043
[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 85e83020 857480d0 00000000-00000000
\FileSystem\Ntfs
Args: f66f1a88 01004160 00010001 00000000
[0, 0] 0 e0 85ed2ed8 857480d0 f69a3d63-862eae28 Success Error Cancel
\FileSystem\FSD2Driver FSD1
Args: f66f1a88 01004160 00010001 00000000
[0, 0] 0 e0 863b56a0 857480d0 f723df8e-85edf208 Success Error Cancel
\FileSystem\FSD1Driver
fltmgr!FltpSynchronizedOperationCompletion
Args: f66f1a88 01000060 00010001 00000000
[0, 0] 0 0 85eceb28 857480d0 00000000-00000000
\FileSystem\FltMgr
Args: f66f1a88 01000060 00010001 00000000

kd> dt _FILE_OBJECT 857480d0

ntdll!_FILE_OBJECT
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x865444c0 _DEVICE_OBJECT
+0x008 Vpb : 0x86557818 _VPB
+0x00c FsContext : (null)
+0x010 FsContext2 : 0xe163bc10
+0x014 SectionObjectPointer : 0x85f44264 _SECTION_OBJECT_POINTERS
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0x1 ‘’
+0x027 WriteAccess : 0 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0x42
+0x030 FileName : _UNICODE_STRING ""
+0x038 CurrentByteOffset : 0x0
+0x040 Waiters : 0
+0x044 Busy : 0
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

kd> dt _UNICODE_STRING 85748100
+0x000 Length : 1
+0x002 MaximumLength : 0x78
+0x004 Buffer : 0xe1a5ca08 "" ß–there’s a string in here
larger than 1 (see below)

kd> dc 0xe1a5ca08

e1a5ca08 0055005c 00650073 00730072 0075005c .U.s.e.r.s..u.
e1a5ca18 00650073 00700072 006f0072 00690066 s.e.r.p.r.o.f.i.
e1a5ca28 0065006c 005c0073 00310032 005c0030 l.e.s..2.1.0..
e1a5ca38 00610046 006f0076 00690072 00650074 F.a.v.o.r.i.t.e.
e1a5ca48 005c0073 00720070 00390066 002e0030 s..p.r.f.9.0…
e1a5ca58 006d0074 00000070 a0020000 00000201 t.m.p.

- Gautham

An odd length is not valid for a file name (since sizeof(WCHAR) = 2) But that shouldn’t cause an invalid memory reference. Since you don’t mention the OS version it’s tough to even look at what this code fragment is trying to do and I don’t see anything obvious from the snippets of data you have provided that would even lead me to believe this is related to FO->FileName. What seems more likely is that you’ve got someone trouncing on memory, and they are whacking the FO->FileName field.

Have you tried this with special pool enabled?

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