KERNEL_DATA_INPAGE_ERROR crash.

NTFSD
1

Hi ALL,

any idea how to debug the following crash? System W2k3 release.
I can reproduce it very consistently :). Any suggestions will be greatly appreciated.

I have written a very simple utility that creates 2 threads that both work with the same file. Thread1 opens the file for buffered IO and writes to the first 8MB of the file. Thread2 opens the file for memory-mapped access (CreateFileMapping for 16MB file; MapViewOfFile to map the whole file) and writes another 8MB starting at offset 8MB. The following crash happens almost instantly.

Thanks in advance.

-Ilya.

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: 00000002, lock type that was held (value 1,2,3, or PTE address)
Arg2: c0000005, error status (normally i/o status code)
Arg3: 00000000, current process (virtual address for lock type 3, or PTE)
Arg4: 00000000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
Debugging Details:

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
BUGCHECK_STR: 0x7a_c0000005
DEFAULT_BUCKET_ID: DRIVER_FAULT
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8082616f to 80871648
STACK_TEXT:
ba2f8218 8082616f 00000003 00000000 0000007a nt!RtlpBreakWithStatusInstruction
ba2f8264 80827044 00000003 808ab640 88d5c830 nt!KiBugCheckDebugBreak+0x19
ba2f85fc 80827451 0000007a 00000002 c0000005 nt!KeBugCheck2+0x5b2
ba2f861c 808519b8 0000007a 00000002 c0000005 nt!KeBugCheckEx+0x1b
ba2f864c 80858daa 00000000 89b7a070 00001000 nt!MiMakeSystemAddressValidPfnSystemWs+0x13c
ba2f879c 8080eca6 89b7a070 b9cf7f84 00000000 nt!MmCopyToCachedPage+0x12c
ba2f882c 8080c7d5 89291008 b9cf7f84 ba2f8870 nt!CcMapAndCopy+0x1b2
ba2f88bc b9e79888 891bcd08 ba2f8bc4 00010000 nt!CcCopyWrite+0x29b
ba2f8be4 b9e77019 891ba944 891bea10 89ad82a0 idefs!MyCommonWrite+0x1f48
ba2f8c2c 8081dce5 892bdab0 891bea10 89b512c0 idefs!MyFsdWrite+0xf9
ba2f8c40 f726fc53 89b512c0 891bea10 00000366 nt!IofCallDriver+0x45
ba2f8c68 8081dce5 89ad82a0 891bea10 00000001 fltMgr!FltpDispatch+0x6f
ba2f8c7c 808f4797 891beac8 00000001 891bea10 nt!IofCallDriver+0x45
ba2f8c90 808f24ce 89ad82a0 891bea10 891bcd08 nt!IopSynchronousServiceTail+0x10b
ba2f8d38 80888c6c 000007d4 00000000 00000000 nt!NtWriteFile+0x65a
ba2f8d38 7c82ed54 000007d4 00000000 00000000 nt!KiFastCallEntry+0xfc
0050fd34 7c822154 77e6f49d 000007d4 00000000 ntdll!KiFastSystemCallRet
0050fd38 77e6f49d 000007d4 00000000 00000000 ntdll!ZwWriteFile+0xc
0050fd98 00411e08 000007d4 0051ff84 00010000 kernel32!WriteFile+0xf7
0052ffb8 77e6608b 00031e40 00000000 00000000 write_test!MainThread+0x148 [c:\dev\write_test\write_test.cpp @ 54]
0052ffec 00000000 00411361 00031e40 00000000 kernel32!BaseThreadStart+0x34

2

Ilya,

If I read this trace right, it sure looks like the address passed into
MiMakeSystemAddressValidPfnSystemWs is zero (first parameter) but it is
possible that this is a re-used value. If you look backwards in that
function you will see where it calls MmAccessFault and that takes the
same address value (2nd parameter) and you should be able to verify what
the address is.

I’m wondering what the lengths of the file are right now: can you tell
what the VDL, EOF and AllocationSize of the file are?

I really suspect you are reading into a region that just doesn’t exist.
On that note, what is the SOURCE of your data? It sure looks like it is
the source of the data that is failing, not the destination (write) of
the data (e.g., it’s faulting in the destination that looks to be
failing.) Are you certain that you are at IRQL < DISPATCH_LEVEL?

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@comcast.net
Sent: Thursday, March 29, 2007 3:40 PM
To: ntfsd redirect
Subject: [ntfsd] KERNEL_DATA_INPAGE_ERROR crash.

Hi ALL,

any idea how to debug the following crash? System W2k3 release.

I can reproduce it very consistently :). Any suggestions will be greatly
appreciated.

I have written a very simple utility that creates 2 threads that both
work with the same file. Thread1 opens the file for buffered IO and
writes to the first 8MB of the file. Thread2 opens the file for
memory-mapped access (CreateFileMapping for 16MB file; MapViewOfFile to
map the whole file) and writes another 8MB starting at offset 8MB. The
following crash happens almost instantly.

Thanks in advance.

-Ilya.

2: kd> !analyze -v
************************************************************************
*******
*
*
* Bugcheck Analysis
*
* &nbs p;
*
************************************************************************
*******

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically
caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed
because
a filesystem failed to make forward progress.
Arguments:
Arg1: 00000002, lock type that was held (value 1,2,3, or PTE address)
Arg2: c0000005, error status (normally i/o status code)
Arg3: 00000000, current process (virtual address for lock type 3, or
PTE)
Arg4: 00000000, virtual address that could not be in-paged (or PTE
contents if arg1 is a PTE address)

Debugging Details:

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

BUGCHECK_STR: 0x7a_c0000005

DEFAULT_BUCKET_ID: DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 8082616f to 80871648

STACK_TEXT:
ba2f8218 8082616f 00000003 00000000 0000007a
nt!RtlpBreakWithStatusInstruction
ba2f8264 80827044 00000003 808ab640 88d5c830
nt!KiBugCheckDebugBreak+0x19
ba2f85fc 80827451 0000007a 00000002 c0000005 nt!KeBugCheck2+0x5b2
ba2f861c 808519b8 0000007a 00000002 c0000005 nt!KeBugCheckEx+0x1b
ba2f864c 80858daa 00000000 89b7a070 00001000
nt!MiMakeSystemAddressValidPfnSystemWs+0x13c
ba2f879c 8080eca6 89b7a070 b9cf7f84 00000000 nt!MmCopyToCachedPage+0x12c
ba2f882c 8080c7d5 89291008 b9cf7f84 ba2f8870 nt!CcMapAndCopy+0x1b2
ba2f88bc b9e79888 891bcd08 ba2f8bc4 00010000 nt!CcCopyWrite+0x29b
ba2f8be4 b9e77019 891ba944 891bea10 89ad82a0 idefs!MyCommonWrite+0x1f48

ba2f8c2c 8081dce5 892bdab0 891bea10 89b512c0 idefs!MyFsdWrite+0xf9

ba2f8c40 f726fc53 89b512c0 891bea10 00000366 nt!IofCallDriver+0x45
ba2f8c68 8081dce5 89ad82a0 891bea10 00000001 fltMgr!FltpDispatch+0x6f
ba2f8c7c 808f4797 891beac8 00000001 891bea10 nt!IofCallDriver+0x45
ba2f8c90 808f24ce 89ad82a0 891bea10 891bcd08
nt!IopSynchronousServiceTail+0x10b
ba2f8d38 80888c6c 000007d4 00000000 00000000 nt!NtWriteFile+0x65a
ba2f8d38 7c82ed54 000007d4 00000000 00000000 nt!KiFastCallEntry+0xfc
0050fd34 7c822154 77e6f49d 000007d4 00000000 ntdll!KiFastSystemCallRet
0050fd38 77e6f49d 000007d4 00000000 00000000 ntdll!ZwWriteFile+0xc
0050fd98 00411e08 000007d4 0051ff84 00010000 kernel32!WriteFile+0xf7
0052ffb8 77e6608b 00031e40 00000000 00000000 write_test!MainThread+0x148
[c:\dev\write_test\write_test.cpp @ 54]
0052ffec 00000000 00411361 00031e40 00000000
kernel32!BaseThreadStart+0x34

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

3

> nt!MiMakeSystemAddressValidPfnSystemWs+0x13c

This looks like an improper or damaged Shared Cache Map.
The system tried to make valid a page from System Working Set, in the case of writing in a cache this should be a page that contains ProtoPTEs for a memory mapped file.
Check file caching initialization and deinitialization and how you report CC_FILE_SIZES.

–
Slava Imameyev, xxxxx@hotmail.com

wrote in message news:xxxxx@ntfsd…
Hi ALL,

any idea how to debug the following crash? System W2k3 release.
I can reproduce it very consistently :). Any suggestions will be greatly appreciated.

I have written a very simple utility that creates 2 threads that both work with the same file. Thread1 opens the file for buffered IO and writes to the first 8MB of the file. Thread2 opens the file for memory-mapped access (CreateFileMapping for 16MB file; MapViewOfFile to map the whole file) and writes another 8MB starting at offset 8MB. The following crash happens almost instantly.

Thanks in advance.

-Ilya.

2: kd> !analyze -v
***
*
* Bugcheck Analysis
* &nbs p;

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: 00000002, lock type that was held (value 1,2,3, or PTE address)
Arg2: c0000005, error status (normally i/o status code)
Arg3: 00000000, current process (virtual address for lock type 3, or PTE)
Arg4: 00000000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
Debugging Details:
------------------

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
BUGCHECK_STR: 0x7a_c0000005
DEFAULT_BUCKET_ID: DRIVER_FAULT
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8082616f to 80871648
STACK_TEXT:
ba2f8218 8082616f 00000003 00000000 0000007a nt!RtlpBreakWithStatusInstruction
ba2f8264 80827044 00000003 808ab640 88d5c830 nt!KiBugCheckDebugBreak+0x19
ba2f85fc 80827451 0000007a 00000002 c0000005 nt!KeBugCheck2+0x5b2
ba2f861c 808519b8 0000007a 00000002 c0000005 nt!KeBugCheckEx+0x1b
ba2f864c 80858daa 00000000 89b7a070 00001000 nt!MiMakeSystemAddressValidPfnSystemWs+0x13c
ba2f879c 8080eca6 89b7a070 b9cf7f84 00000000 nt!MmCopyToCachedPage+0x12c
ba2f882c 8080c7d5 89291008 b9cf7f84 ba2f8870 nt!CcMapAndCopy+0x1b2
ba2f88bc b9e79888 891bcd08 ba2f8bc4 00010000 nt!CcCopyWrite+0x29b
ba2f8be4 b9e77019 891ba944 891bea10 89ad82a0 idefs!MyCommonWrite+0x1f48
ba2f8c2c 8081dce5 892bdab0 891bea10 89b512c0 idefs!MyFsdWrite+0xf9
ba2f8c40 f726fc53 89b512c0 891bea10 00000366 nt!IofCallDriver+0x45
ba2f8c68 8081dce5 89ad82a0 891bea10 00000001 fltMgr!FltpDispatch+0x6f
ba2f8c7c 808f4797 891beac8 00000001 891bea10 nt!IofCallDriver+0x45
ba2f8c90 808f24ce 89ad82a0 891bea10 891bcd08 nt!IopSynchronousServiceTail+0x10b
ba2f8d38 80888c6c 000007d4 00000000 00000000 nt!NtWriteFile+0x65a
ba2f8d38 7c82ed54 000007d4 00000000 00000000 nt!KiFastCallEntry+0xfc
0050fd34 7c822154 77e6f49d 000007d4 00000000 ntdll!KiFastSystemCallRet
0050fd38 77e6f49d 000007d4 00000000 00000000 ntdll!ZwWriteFile+0xc
0050fd98 00411e08 000007d4 0051ff84 00010000 kernel32!WriteFile+0xf7
0052ffb8 77e6608b 00031e40 00000000 00000000 write_test!MainThread+0x148 [c:\dev\write_test\write_test.cpp @ 54]
0052ffec 00000000 00411361 00031e40 00000000 kernel32!BaseThreadStart+0x34