我的计算机从睡眠状态唤醒时一直存在问题。似乎计算机在“长时间”(通常是一整夜)睡眠后会崩溃,并出现 KERNEL_STACK_INPAGE_ERROR,根据崩溃转储,该错误“可能是由 ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+1ecfd ) 导致的”。我的计算机一直很好,直到我尝试使用 Linux 的 Xen 服务器。我的实验需要添加备用视频卡并修改 bois 设置。完成实验后,我将 bios 重置为优化默认值并重新安装 Windows(从我最初设置计算机时制作的映像开始),计算机再也无法从睡眠状态唤醒。我的硬件:
主板:华硕 M5A99FX Pro R2.0
中央处理器:AMD FX-8320 八核处理器
记忆:1 个 KHX1600C10D3B/8G 模块,1/2 个 KVR 1333D3N9K2/4G 套件,共计 10GB
显卡:AMD Radeon HD 6700
硬盘:Seagate 混合硬盘 ST1000DX001
操作系统:Windows 8.1 专业版 x64
我尝试过的:
- 重置 BIOS
- 安装主板和显卡的所有驱动程序
- 更换了硬盘(SMART 声称硬盘已经坏了)
- 更换连接 HDD 的 SATA 电缆
- 运行 MemTest86+ 12 小时
- 对显卡和 CPU 进行压力测试
- 全新安装 Windows
- 用备用显卡替换显卡
- 升级了 BIOS
更多相关信息:
事件日志条目:
- “AODDriver4.3 服务由于以下错误启动失败:系统找不到指定的文件。”
- “系统固件在睡眠状态转换 (S4) 期间更改了处理器的内存类型范围寄存器 (MTRR)。这可能会导致恢复性能下降。”
恢复睡眠时发生的错误:
“0x00007FFA4AD167D5 处的指令引用了 0x00007FFA226C40100 处的内存。由于 I/O 错误状态 0xc000000e,所需数据未放入内存。”Memory.dmp 结果(如果有人感兴趣,我可以发布转储本身):
Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred symsrv*symsrv.dll*c:\localsymbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: symsrv*symsrv.dll*c:\localsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17085.amd64fre.winblue_gdr.140330-1035
Machine Name:
Kernel base = 0xfffff803`ee418000 PsLoadedModuleList = 0xfffff803`ee6e22d0
Debug session time: Wed Sep 17 11:14:48.743 2014 (UTC - 7:00)
System Uptime: 0 days 14:57:00.106
Loading Kernel Symbols
...............................................................
................................................................
.......................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00007ff5`ffffd018). Type ".hh dbgerr001" for details
Loading unloaded module list
........................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7A, {fffff6fac0080000, ffffffffc00000c0, adcc2880, fffff58010000000}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+1ecfd )
Followup: MachineOwner
---------
7: 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: fffff6fac0080000, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc00000c0, error status (normally i/o status code)
Arg3: 00000000adcc2880, current process (virtual address for lock type 3, or PTE)
Arg4: fffff58010000000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
Debugging Details:
------------------
ERROR_CODE: (NTSTATUS) 0xc00000c0 - This device does not exist.
BUGCHECK_STR: 0x7a_c00000c0
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: RtkNGUI64.exe
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
TRAP_FRAME: ffffd0011f6b34f0 -- (.trap 0xffffd0011f6b34f0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=fffff580108042e8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff803ee816924 rsp=ffffd0011f6b3680 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=fffff58010000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!MiCommitPageTablesForVad+0x1c0:
fffff803`ee816924 410fa302 bt dword ptr [r10],eax ds:fffff580`10000000=00000000
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff803ee59b1ad to fffff803ee56bfa0
STACK_TEXT:
ffffd001`1f6b31f8 fffff803`ee59b1ad : 00000000`0000007a fffff6fa`c0080000 ffffffff`c00000c0 00000000`adcc2880 : nt!KeBugCheckEx
ffffd001`1f6b3200 fffff803`ee4a05f8 : 00000000`00000002 ffffd001`1f6b3368 ffffe001`2e329a98 ffffd001`00000000 : nt! ?? ::FNODOBFM::`string'+0x1ecfd
ffffd001`1f6b32f0 fffff803`ee47f5f5 : ffffe001`2ed03080 ffffe001`2e329a98 00000000`c0033333 fffff803`00000000 : nt!MiIssueHardFault+0x184
ffffd001`1f6b33b0 fffff803`ee57622f : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd001`1f6b34f0 : nt!MmAccessFault+0x3d5
ffffd001`1f6b34f0 fffff803`ee816924 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff803`eeba769a : nt!KiPageFault+0x12f
ffffd001`1f6b3680 fffff803`ee486ed4 : fffff6fa`c0080000 00000000`00000001 00000000`00000001 00000000`00000001 : nt!MiCommitPageTablesForVad+0x1c0
ffffd001`1f6b36f0 fffff803`ee81563c : ffffe001`2effa1b0 00000000`00000001 ffffd001`1f6b3b00 00000000`00000004 : nt!MiCommitExistingVad+0x314
ffffd001`1f6b3810 fffff803`ee5777b3 : ffffe001`2ed03080 00000000`0013fdf8 ffffd001`1f6b3a28 00000001`401dd250 : nt!NtAllocateVirtualMemory+0x46c
ffffd001`1f6b3a10 00007ffd`e84717fa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0013e9a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffd`e84717fa
STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+1ecfd
fffff803`ee59b1ad cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+1ecfd
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 53388e13
BUCKET_ID_FUNC_OFFSET: 1ecfd
FAILURE_BUCKET_ID: 0x7a_c00000c0_nt!_??_::FNODOBFM::_string_
BUCKET_ID: 0x7a_c00000c0_nt!_??_::FNODOBFM::_string_
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x7a_c00000c0_nt!_??_::fnodobfm::_string_
FAILURE_ID_HASH: {90f07b7f-b6ca-d03a-b3d4-2f5aff8f8644}
Followup: MachineOwner
---------
答案1
我知道这个帖子比较旧了,但我仍然想发布我发现的修复/解决方法,因为我最近购买了华硕 M5A99FX PRO R2.0,并且在从睡眠状态唤醒时遇到了完全相同的 BSOD 问题。
这里的原因是板载默认启用的 ASmedia SATA 控制器。起初,我将主 SSD Sata 启动驱动器连接到主板上的蓝色 SATA 控制器,即 2 个 ASmedia SATA 控制器。通过排除法,我最终决定将主 SSD 启动驱动器移动到其他白色 SATA 端口(AMD SB 控制器),并在 BIOS 中完全禁用 ASmedia 芯片。我的电脑现在从睡眠状态唤醒时没有任何问题。因此,除非您需要 AMD SB950 SB 控制器支持的 5 个以上 SATA 端口,否则这里不会有太大损失。我仍然很恼火,因为没有驱动程序或 BIOS 更新来解决这个问题(当您购买某些东西时,所有组件都应该正常工作!)但总的来说,它不会影响我的设置。
我希望这能帮助那些苦苦思索为什么他们的 ASUS M5A99FX PRO R2.0 设置在从睡眠模式唤醒时会出现 BSOD 的人!
答案2
在我看来,问题出在 RtkNGUI64.exe 上。我有一台定制的电脑,配有 ROG Crosshair V Formula-Z 主板和 ASUS Radeon R9 290 显卡,我遇到了一些问题,我的电脑从睡眠状态唤醒后只显示黑屏,直到我按下 ctrl+alt+del。然后,一旦锁定屏幕出现,我只需点击取消,我的桌面就会重新出现。但是,我的主要音频设备随后不见了。耳机插孔/前面板仍然有效,但主音频设备只是从我的系统中消失,直到我重新启动。我检查了一些崩溃转储,并找到了一个常见的可执行文件... RtkNGUI64.exe。
答案3
您在参数 2 中看到的错误代码c00000c0
意味着 Windows 无法检测到驱动器(STATUS_DEVICE_DOES_NOT_EXIST
):
C:\Users\André>err c00000c0
# for hex 0xc00000c0 / decimal -1073741632
STATUS_DEVICE_DOES_NOT_EXIST ntstatus.h
# This device does not exist.
# as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0xc0
# for hex 0xc0 / decimal 192
ERROR_EXE_MARKED_INVALID winerror.h
# The operating system cannot run %1.
# 2 matches found for "c00000c0"
更新 Seagate 混合硬盘的固件/软件。同时运行 Seagate 的 HDD 诊断工具以确保硬盘正常。