none
Server 2008 R2 Enterprise BSOD - KERNEL_DATA_INPAGE_ERROR (7a) RRS feed

  • Question

  • Hi guys,

    I've just had a BSOD on one of our servers. Below is the memory.dmp file

    I'm not entirely sure how to read these errors, can somebody let me know what has caused it?

    Thanks

    Robbie

    *******************************************************************************

    *                                                                             *

    *                        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: fffff6fc40046b00, lock type that was held (value 1,2,3, or PTE address)

    Arg2: ffffffffc000003c, error status (normally i/o status code)

    Arg3: 0000000d45c07be0, current process (virtual address for lock type 3, or PTE)

    Arg4: fffff88008d60000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

    Debugging Details:

    ------------------

     

    ERROR_CODE: (NTSTATUS) 0xc000003c - {Data Overrun}  A data overrun error occurred.

    BUGCHECK_STR:  0x7a_c000003c

    DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

    PROCESS_NAME:  System

    CURRENT_IRQL:  0

    ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

    LAST_CONTROL_TRANSFER:  from fffff80001ce9752 to fffff80001c76bc0

    STACK_TEXT: 

    fffff880`0431d748 fffff800`01ce9752 : 00000000`0000007a fffff6fc`40046b00 ffffffff`c000003c 0000000d`45c07be0 : nt!KeBugCheckEx

    fffff880`0431d750 fffff800`01c9d91f : fffffa80`8d64bdf0 fffff880`0431d880 fffff800`01eb1540 fffff800`01c8642e : nt! ?? ::FNODOBFM::`string'+0x36c1a

    fffff880`0431d830 fffff800`01c841b9 : 00000000`00000000 00000000`00000001 ffffffff`ffffffff 00000000`00000008 : nt!MiIssueHardFault+0x28b

    fffff880`0431d8c0 fffff800`01caa6e0 : 00000000`00000001 fffff880`08d60000 04016400`00790000 fffff6fc`40046ad8 : nt!MmAccessFault+0x1399

    fffff880`0431da20 fffff800`01caa8d0 : fffffa80`33e88b50 00000000`00000001 fffffa80`6f175640 fffff800`01ca770b : nt!MiInPageSingleKernelStack+0x134

    fffff880`0431db30 fffff800`01caa85f : fffffa80`6f175640 00000000`00000080 fffffa80`30fc9890 fffffa80`33e88bf0 : nt!MmInPageKernelStack+0x40

    fffff880`0431db90 fffff800`01caa5a4 : 00000000`00000000 00000000`00000000 fffffa80`30fc9800 fffffa80`30fc9800 : nt!KiInSwapKernelStacks+0x1f

    fffff880`0431dbc0 fffff800`01f132ea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeSwapProcessOrStack+0x84

    fffff880`0431dc00 fffff800`01c678e6 : fffff880`036f5180 fffffa80`310983e0 fffff880`03700ec0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a

    fffff880`0431dc40 00000000`00000000 : fffff880`0431e000 fffff880`04318000 fffff880`0431d910 00000000`00000000 : nt!KxStartSystemThread+0x16

     

    STACK_COMMAND:  kb

    FOLLOWUP_IP:

    nt! ?? ::FNODOBFM::`string'+36c1a

    fffff800`01ce9752 cc              int     3

    SYMBOL_STACK_INDEX:  1

    SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+36c1a

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: nt

    IMAGE_NAME:  ntkrnlmp.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  521ea035

    IMAGE_VERSION:  6.1.7601.18247

    FAILURE_BUCKET_ID:  X64_0x7a_c000003c_nt!_??_::FNODOBFM::_string_+36c1a

    BUCKET_ID:  X64_0x7a_c000003c_nt!_??_::FNODOBFM::_string_+36c1a

    ANALYSIS_SOURCE:  KM

    FAILURE_ID_HASH_STRING:  km:x64_0x7a_c000003c_nt!_??_::fnodobfm::_string_+36c1a

    FAILURE_ID_HASH:  {a0dbf327-b0f3-2e9e-85d7-b70fc889e78a}

    Followup: MachineOwner

    ---------

    Wednesday, May 7, 2014 9:03 AM

Answers

All replies

  • Hi Robbie,

    Regarding to Bug Check 0x7A, indicates that the requested page of kernel data from the paging file could not be read into memory. For more details, please refer to the following article.

    Bug Check 0x7A: KERNEL_DATA_INPAGE_ERROR

    Would you please let me know which operation had been done, then this BSOD issue occurred? Or just this BSOD issue occurred suddenly? In addition, please refer to following link and check if can help you.

    http://www.dell.com/support/troubleshooting/bb/en/bbdhs1/KCS/KcsArticles/ArticleIframeView?docid=645709&doclang=EN#Issue5

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    By the way, it is not effective for us to debug the crash dump file here in the forum. If this issues is a state of emergency for you. Please contact Microsoft Customer Service and Support (CSS) via telephone so that a dedicated Support Professional can assist with your request.

    To obtain the phone numbers for specific technology request, please refer to the web site listed below:

    http://support.microsoft.com/default.aspx?scid=fh;EN-US;OfferProPhone#faq607

    Hope this helps.

    Best regards,

    Justin Gu

    Thursday, May 8, 2014 10:32 AM
    Moderator
  • Hi Justin,

    Thanks for your reply.

    This problem isn't critical to us at the moment but if we see a repeat of it I will contact support.

    A backup was running on the server when the BSOD happened. The Dell page that you linked too suggests a disk or controller error. I think I will upgrade the storage controller drivers at our next downtime and hopefully we won't see a repeat of this problem.

    Thanks again for your help

    Robbie

    Thursday, May 8, 2014 12:32 PM