none
windows 2016蓝屏 PAGE_FAULT_IN_NONPAGED_AREA RRS feed

  • 问题

  • 非常频繁,一小时来一次,硬件是HPEDL388G10,2台都这样,系统已重装过,驱动已安装到最新,如果进入安全模式就不出现蓝屏现象

    PAGE_FAULT_IN_NONPAGED_AREA (50)

    Invalid system memory was referenced.  This cannot be protected by try-except,
    it must be protected by a Probe.  Typically the address is just plain bad or it
    is pointing at freed memory.
    Arguments:
    Arg1: ffffd98ee953d000, memory referenced.
    Arg2: 0000000000000002, value 0 = read operation, 1 = write operation.
    Arg3: fffff8037d7e28b0, If non-zero, the instruction address which referenced the bad memory
    address.
    Arg4: 0000000000000000, (reserved)

    Debugging Details:
    ------------------


    Could not read faulting driver name



    WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
    unable to get nt!MmSpecialPoolEnd
    unable to get nt!MmPoolCodeStart
    unable to get nt!MmPoolCodeEnd
     ffffd98ee953d000 

    FAULTING_IP: 
    srv!SrvOs2FeaToNt+48
    fffff803`7d7e28b0 c60300          mov     byte ptr [rbx],0

    MM_INTERNAL_CODE:  0

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  CODE_CORRUPTION

    BUGCHECK_STR:  0x50

    PROCESS_NAME:  System

    CURRENT_IRQL:  2

    LAST_CONTROL_TRANSFER:  from fffff802f5b771af to fffff802f5b5ef90

    STACK_TEXT:  
    ffff8181`ad049d28 fffff802`f5b771af : 00000000`00000050 ffffd98e`e953d000 00000000`00000002 ffff8181`ad04a020 : nt!KeBugCheckEx
    ffff8181`ad049d30 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x8fef


    STACK_COMMAND:  .bugcheck ; kb

    CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
        fffff802f5a8186b - nt!MiAssignNonPagedPoolPtes+19b
    [ f6:ac ]
        fffff802f5a8193c-fffff802f5a8193d  2 bytes - nt!MiInsertLargePageInNodeListHelper+4c (+0xd1)
    [ 80 fa:00 f0 ]
        fffff802f5a8b2b7-fffff802f5a8b2b8  2 bytes - nt!MiGetPage+97 (+0x997b)
    [ 80 fa:00 f0 ]
        fffff802f5b231dd-fffff802f5b231de  2 bytes - nt!MiPurgeZeroList+6d (+0x97f26)
    [ 80 fa:00 f0 ]
    7 errors : !nt (fffff802f5a8186b-fffff802f5b231de)

    MODULE_NAME: memory_corruption

    IMAGE_NAME:  memory_corruption

    FOLLOWUP_NAME:  memory_corruption

    DEBUG_FLR_IMAGE_TIMESTAMP:  0

    MEMORY_CORRUPTOR:  LARGE

    FAILURE_BUCKET_ID:  X64_MEMORY_CORRUPTION_LARGE

    BUCKET_ID:  X64_MEMORY_CORRUPTION_LARGE

    Followup: memory_corruption

    2019年11月13日 6:22

全部回复

  • 用途是域控2016,由原先的2008R2升级过来的,昨天测试了一台删除了AD和DNS服务,一晚上没有蓝屏,不知是啥问题
    2019年11月14日 1:55
  • 你好,

    由于安全模式并不会出现该问题,推测可能是由于某个驱动程序引起的。 为了排查具体故障信息,建议使用driver verifier 工具查一下具体是什么驱动。

    driver verifier


    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。
     



    • 已编辑 Joy-Qiao 2019年11月14日 2:56
    2019年11月14日 2:54

  • Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
    Copyright (c) Microsoft Corporation. All rights reserved.


    Loading Dump File [C:\Users\mche\Desktop\111519-7281-01.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols

    Executable search path is: 
    Windows Kernel Version 14393 MP (16 procs) Free x64
    Product: LanManNt, suite: Enterprise TerminalServer SingleUserTS
    Built by: 14393.0.amd64fre.rs1_release.160715-1616
    Kernel base = 0xfffff801`fd682000 PsLoadedModuleList = 0xfffff801`fd987060
    Debug session time: Fri Nov 15 11:05:37.370 2019 (GMT+8)
    System Uptime: 0 days 0:05:20.046
    Loading Kernel Symbols
    ..............................................................
    Loading User Symbols
    Loading unloaded module list
    ....
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck C4, {2000, fffff807d56112e7, 0, 6b667072}



    Probably caused by : ntkrnlmp.exe ( nt!VerifierBugCheckIfAppropriate+48 )

    Followup: MachineOwner
    ---------

    0: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
    A device driver attempting to corrupt the system has been caught.  This is
    because the driver was specified in the registry as being suspect (by the
    administrator) and the kernel has enabled substantial checking of this driver.
    If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
    be among the most commonly seen crashes.
            Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
                   Typically the code is 0x1001 (deadlock detected) and you can
                   issue a '!deadlock' KD command to get more information.
    Arguments:
    Arg1: 0000000000002000, subclass of driver violation.
    Arg2: fffff807d56112e7
    Arg3: 0000000000000000
    Arg4: 000000006b667072

    Debugging Details:
    ------------------




    BUGCHECK_STR:  0xc4_2000

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

    PROCESS_NAME:  System

    CURRENT_IRQL:  0

    LAST_CONTROL_TRANSFER:  from fffff801fdd8e330 to fffff801fd7cbf90

    STACK_TEXT:  
    ffffdf00`4d16b068 fffff801`fdd8e330 : 00000000`000000c4 00000000`00002000 fffff807`d56112e7 00000000`00000000 : nt!KeBugCheckEx
    ffffdf00`4d16b070 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!VerifierBugCheckIfAppropriate+0x48


    STACK_COMMAND:  kb

    FOLLOWUP_IP: 
    nt!VerifierBugCheckIfAppropriate+48
    fffff801`fdd8e330 cc              int     3

    SYMBOL_STACK_INDEX:  1

    SYMBOL_NAME:  nt!VerifierBugCheckIfAppropriate+48

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: nt

    IMAGE_NAME:  ntkrnlmp.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  578998f1

    FAILURE_BUCKET_ID:  X64_0xc4_2000_VRF_nt!VerifierBugCheckIfAppropriate+48

    BUCKET_ID:  X64_0xc4_2000_VRF_nt!VerifierBugCheckIfAppropriate+48

    Followup: MachineOwner
    ---------

    0: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
    A device driver attempting to corrupt the system has been caught.  This is
    because the driver was specified in the registry as being suspect (by the
    administrator) and the kernel has enabled substantial checking of this driver.
    If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
    be among the most commonly seen crashes.
            Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
                   Typically the code is 0x1001 (deadlock detected) and you can
                   issue a '!deadlock' KD command to get more information.
    Arguments:
    Arg1: 0000000000002000, subclass of driver violation.
    Arg2: fffff807d56112e7
    Arg3: 0000000000000000
    Arg4: 000000006b667072

    Debugging Details:
    ------------------




    BUGCHECK_STR:  0xc4_2000

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

    PROCESS_NAME:  System

    CURRENT_IRQL:  0

    LAST_CONTROL_TRANSFER:  from fffff801fdd8e330 to fffff801fd7cbf90

    STACK_TEXT:  
    ffffdf00`4d16b068 fffff801`fdd8e330 : 00000000`000000c4 00000000`00002000 fffff807`d56112e7 00000000`00000000 : nt!KeBugCheckEx
    ffffdf00`4d16b070 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!VerifierBugCheckIfAppropriate+0x48


    STACK_COMMAND:  kb

    FOLLOWUP_IP: 
    nt!VerifierBugCheckIfAppropriate+48
    fffff801`fdd8e330 cc              int     3

    SYMBOL_STACK_INDEX:  1

    SYMBOL_NAME:  nt!VerifierBugCheckIfAppropriate+48

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: nt

    IMAGE_NAME:  ntkrnlmp.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  578998f1

    FAILURE_BUCKET_ID:  X64_0xc4_2000_VRF_nt!VerifierBugCheckIfAppropriate+48

    BUCKET_ID:  X64_0xc4_2000_VRF_nt!VerifierBugCheckIfAppropriate+48

    Followup: MachineOwner
    ---------

    0: kd> !verifier

    Verify Level 3afefbf ... enabled options are:
    Special pool
    Special irql
    Inject random low-resource API failures
    All pool allocations checked on unload
    Io subsystem checking enabled
    Deadlock detection enabled
    DMA checking enabled
    Security checks enabled
    Force pending I/O requests
    IRP Logging
    Miscellaneous checks enabled

    Summary of All Verifier Statistics

    RaiseIrqls                             0x3d44
    AcquireSpinLocks                       0x56ae3
    Synch Executions                       0x0
    Trims                                  0x147d

    Pool Allocations Attempted             0x391cd
    Pool Allocations Succeeded             0x391cd
    Pool Allocations Succeeded SpecialPool 0x391cd
    Pool Allocations With NO TAG           0x0
    Pool Allocations Failed                0x0
    Resource Allocations Failed Deliberately   0x0

    Current paged pool allocations         0x608 for 00176FAD bytes
    Peak paged pool allocations            0x665 for 0049CA69 bytes
    Current nonpaged pool allocations      0x12ec for 0253A6AA bytes
    Peak nonpaged pool allocations         0x12f0 for 0253C80A bytes

    unable to get nt!MmSpecialPoolStart
    unable to get nt!MmSpecialPoolEnd
    2019年11月15日 3:39
  • 另外发现一个奇怪的问题,如果服务器不用原先AD和DNS的IP地址,而是配置个新IP,就不发生蓝屏现象
    2019年11月15日 3:42
  • 你好,

    请尝试将服务器的网卡驱动卸载重新启动以加载一个新的网卡驱动,或者在设备官网下载一个最新版本的网卡驱动看一下该问题是否还会出现。


    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。


    • 已编辑 Joy-Qiao 2019年11月20日 9:42
    2019年11月15日 9:33
  • 你的报错是Could not read faulting driver name,无法读取正确驱动名称,你的驱动故障,建议卸载全部驱动,驱动不需要最新的,但必须是官网的,建议下载历史版本的前2代驱动
    2019年11月15日 17:14
  • 请问主板芯片组如何卸载
    2019年11月18日 1:48
  • 网卡无需安装驱动,卸载后重启配置好IP,问题依旧,我再来详细说下情况,原先2台2008域控IP分别为20,21,新购了2台HPE服务器安装了2016,安装了AD和DNS,初始配置IP为22,23,后续把2台2016提升为域控制器,IP改成了20,21出现了蓝屏现象,然后把硬件日志发给HPE,查下来硬件没有问题,后续系统重装过,驱动都是官方提供的,IP先使用了22,23,观察了几天没有出现过一次蓝屏现象,随即把IP改成了20,21,其中一台改完立马蓝屏重启了,目前没什么头绪,因为20,21这两个IP是用户DNS地址,由于我们是手工配置的静态地址,如果要改DNS地址,工作量比较大,实在是太奇怪的问题了,目前是先用着,白天上班时间蓝屏次数相对较少,2台同时蓝屏的概率也比较低,晚上的蓝屏频率比较高
    2019年11月18日 6:59
  • 主板驱动,一般是usb等外设驱动程序,一个一个卸载不好卸载,可以使用第三方驱动程序软件进行卸载驱动

    2019年11月18日 10:36
  • 建议将系统虚拟化出来,或者克隆,安装到其他终端上,看看运行是否正常,一步一步排是否是,硬件,通信,系统等问题
    2019年11月18日 10:38
  • 其他旧的服务器测试过,只要用了那2个原来的IP,机器就会发生意外关闭的情况,使用其他IP就正常了,虚拟化没有条件测试
    2019年11月19日 1:46
  • 不管哪台服务器用这两个ip都报错?

    检查网络设备配置,或者抓包查看有没有异常报文

    2019年11月19日 3:31
  • 网络配置应该没问题,装了wireshark,抓取后如何查看问题所在呢
    2019年11月20日 3:01
  • 你好,

    我们可以参考下面链接了解wireshark的使用方式及故障排查方法。

    How to Use Wireshark to Capture, Filter and Inspect Packets

    但是由于该软件是三方软件,详细情况建议咨询该软件的技术支持。


    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。

    • 已编辑 Joy-Qiao 2019年11月21日 9:25
    2019年11月21日 9:24
  • 实在没办法,其中一台换了新的系统安装镜像安装,配置成原先使用的IP地址,一天下来没有出现过一次意外关闭的情况,再多观察几天情况,原先使用的镜像是原版光盘镜像,新的是我网上下了一个,但这个原版光盘其他服务器也装的,而且域控服务器用这个镜像如果配置成不是原先使用的IP地址,都一切正常,唯独配置成原先使用的IP就会经常意外关闭,好神奇的问题,还是希望能够解决
    2019年11月29日 6:37
  • 换了个系统安装镜像后,应该是解决了,好奇葩的问题
    2019年12月5日 8:30
  • 你好,

    感谢您的反馈。

    原先的光盘镜像应该是之前版本,并没有涉及安装最新的补丁。但是如果是官网上下载的镜像,都默认打入了最新的补丁包。我认为可能还是和Windows 更新补丁中包含的一些最新的系统文件或驱动有关。

    请将该帖中有用的跟帖标记为答案,以方便其他用户快速检索有效信息。

    感谢您的配合。


    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。


    • 已编辑 Joy-Qiao 2019年12月12日 2:33
    2019年12月12日 2:33