Tenho tido problemas com o meu computador a acordar do sono. Parece que depois que o computador dorme "por um longo tempo" (tende a ser durante a noite) ele falha com um KERNEL_STACK_INPAGE_ERROR, que de acordo com o despejo de memória foi "Provavelmente causada por: ntkrnlmp.exe (nt! ?? :: FNODOBFM :: 'string' + 1ecfd) ”. Meu computador estava bem até que experimentei o servidor Xen do Linux. Minha experiência exigiu a adição de uma placa de vídeo sobressalente e a modificação das configurações do bois. Depois que terminei minha experimentação, redefini as BIOS para os padrões otimizados e reinstalei o Windows (a partir de uma imagem que eu havia criado quando configurei o computador originalmente) e ele não iria mais sair do modo de suspensão.
Meu hardware:
Mobo: Asus M5A99FX Pro R2.0
CPU: processador AMD FX-8320 de oito núcleos
Memória: 1 módulo KHX1600C10D3B / 8G, kit 1/2 KVR 1333D3N9K2 / 4G para um total de 10 GB
Placa gráfica: AMD Radeon HD 6700
HDD: Seagate Hybrid Drive ST1000DX001
Sistema operacional: Windows 8.1 Pro x64
O que eu tentei:
- Redefinindo o BIOS
- Instalando todos os drivers para o Mobo e a placa gráfica
- Substituiu o HDD (o SMART alegou que tudo correu mal)
- Cabo SATA substituído conectado ao HDD
- Ran MemTest86 + por 12 horas
- O estresse testou a placa gráfica e a CPU
- Nova instalação do Windows
- Placa de vídeo substituída com uma placa de vídeo sobressalente
- Atualizou o BIOS
Mais informações relevantes:
Entradas do registro de eventos:
- “O serviço AODDriver4.3 falhou ao iniciar devido ao seguinte erro: O sistema não pode encontrar o arquivo especificado.”
- “O firmware do sistema alterou os registros de intervalo de tipos de memória (MTRRs) do processador em uma transição de estado de suspensão (S4). Isso pode resultar em redução do desempenho do currículo ”.
Um erro que ocorreu no reinício da suspensão:
“A instrução em 0x00007FFA4AD167D5 consultou a memória em 0x00007FFA226C40100. Os dados necessários não foram colocados na memória devido a um status de erro de E / S de 0xc000000e. ”
Memory.dmp Resultados (posso postar o despejo se alguém estiver interessado):
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
---------