O computador trava ao acordar do sono

3

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:

  1. Redefinindo o BIOS
  2. Instalando todos os drivers para o Mobo e a placa gráfica
  3. Substituiu o HDD (o SMART alegou que tudo correu mal)
  4. Cabo SATA substituído conectado ao HDD
  5. Ran MemTest86 + por 12 horas
  6. O estresse testou a placa gráfica e a CPU
  7. Nova instalação do Windows
  8. Placa de vídeo substituída com uma placa de vídeo sobressalente
  9. Atualizou o BIOS

Mais informações relevantes:

Entradas do registro de eventos:

  1. “O serviço AODDriver4.3 falhou ao iniciar devido ao seguinte erro: O sistema não pode encontrar o arquivo especificado.”
  2. “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
---------
    
por Chris Crutchfield 17.09.2014 / 20:48

3 respostas

2

Eu sei que este post é mais antigo, mas pensei em postar a correção / solução que eu encontrei desde que eu comprei recentemente um ASUS M5A99FX PRO R2.0 e estava correndo para o mesmo problema exato com BSOD ao acordar do sono.

A causa aqui é o controlador SATA ASMedia habilitado por padrão no sistema. No início, eu tinha o meu disco de inicialização SSD Sata principal conectado aos controladores SATA azuis na placa-mãe, que são os 2 controladores ASTA ASTA. Através do processo de eliminação, eu finalmente decidi mover minha unidade de inicialização SSD principal para as outras portas SATA de cor branca (AMD SB Controller) e eu desabilitei completamente o chip ASMedia no BIOS. Meu computador acorda do sono sem problemas agora. Portanto, a menos que você tenha a necessidade de mais de 5 portas SATA suportadas pelo controlador SB950 SB da AMD, não há muita perda aqui. Eu ainda estou irritado que não há atualizações de driver ou BIOS para consertar isso (quando você compra algo, todos os componentes devem funcionar corretamente!), Mas no geral não afeta minha configuração.

Espero que isso ajude alguém que está no final tentando descobrir por que a configuração do ASUS M5A99FX PRO R2.0 é BSOD ao acordar do modo de suspensão!

    
por 11.04.2015 / 16:58
0

Parece que o problema está no RtkNGUI64.exe. Eu tenho um computador personalizado construído com uma placa de vídeo ROG Crosshair V Fórmula-Z mobo e ASUS Radeon R9 290 e eu tive alguns problemas com o meu computador acordando do sono e mostrando nada além de uma tela preta até que eu apertei ctrl + alt + del . Então, quando a tela de bloqueio aparecer, acabei de cancelar e minha área de trabalho reaparecerá. No entanto, meu principal dispositivo de áudio está ausente depois. O conector de fone de ouvido / painel frontal ainda funciona, mas o dispositivo de áudio principal simplesmente desaparece do meu sistema até que eu reinicie. Eu verifiquei alguns dos meus despejos e surgiu com um executável comum ... RtkNGUI64.exe.

    
por 18.09.2014 / 05:39
0

O código de erro c00000c0 que você vê no parâmetro 2 significa que o Windows não conseguiu detectar a unidade ( 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"

Atualize o firmware / softwwre do seu Seagate Hybrid Drive. Além disso, execute uma ferramenta de diagramação HDD da Seagate para garantir que a unidade esteja funcionando bem.

    
por 18.09.2014 / 06:21