O computador trava no modo de suspensão. Precisa de ajuda para ler o arquivo dmp

Question

Meu computador está travando quando ele tenta entrar no modo de suspensão. A tela será desligada, mas o computador continuará a funcionar indefinidamente. Eu tentei depurar isso sozinho, mas ele excedeu minhas habilidades. Eu usei o verificador do windows para criar um arquivo dmp, mas eu não sei o que é importante uma vez aberto no WinDbg. Agradeço qualquer ajuda na determinação do problema e / ou solução.

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump0215-17253-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18869.amd64fre.win7sp1_gdr.150525-0603
Machine Name:
Kernel base = 0xfffff800'02e55000 PsLoadedModuleList = 0xfffff800'0309c730
Debug session time: Sun Aug  2 11:53:55.001 2015 (UTC - 4:00)
System Uptime: 0 days 0:00:29.296
Loading Kernel Symbols
...............................................................
................................................................
.........
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D3, {fffff8800102d2b9, 2, 0, fffff80002ef3c22}

Probably caused by : ntkrnlmp.exe ( nt!RtlDispatchException+122 )

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

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

DRIVER_PORTION_MUST_BE_NONPAGED (d3)
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers marking code or data as pageable when it should be
marked nonpaged.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: fffff8800102d2b9, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff80002ef3c22, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80003106100
GetUlongFromAddress: unable to read from fffff800031061c0
 fffff8800102d2b9 Nonpaged pool

CURRENT_IRQL:  2

FAULTING_IP: 
nt!RtlDispatchException+122
fffff800'02ef3c22 410fb60c24      movzx   ecx,byte ptr [r12]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

BUGCHECK_STR:  0xD3

PROCESS_NAME:  WRSA.exe

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

TRAP_FRAME:  fffff88002a0bbd0 -- (.trap 0xfffff88002a0bbd0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8800102a1dc rbx=0000000000000000 rcx=fffff8800102d2d0
rdx=fffff8800102d0d2 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ef3c22 rsp=fffff88002a0bd60 rbp=fffff88002a0cc18
 r8=000000000000017d  r9=000000000000016d r10=fffff88002a0d410
r11=fffff88002a0bda8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!RtlDispatchException+0x122:
fffff800'02ef3c22 410fb60c24      movzx   ecx,byte ptr [r12] ds:00000000'00000000=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002ec8e69 to fffff80002ec98c0

STACK_TEXT:  
fffff880'02a0ba88 fffff800'02ec8e69 : 00000000'0000000a fffff880'0102d2b9 00000000'00000002 00000000'00000000 : nt!KeBugCheckEx
fffff880'02a0ba90 fffff800'02ec7ae0 : 00000000'00000000 00000000'00000000 00000000'00000000 00000000'000001e7 : nt!KiBugCheckDispatch+0x69
fffff880'02a0bbd0 fffff800'02ef3c22 : fffff880'0102d2b9 fffff880'02a0bda8 fffff880'02a0cc18 fffff880'0100b000 : nt!KiPageFault+0x260
fffff880'02a0bd60 fffff800'02f04e81 : fffff880'02a0cc18 fffff880'02a0c470 fffff880'00000000 fffff880'0104a090 : nt!RtlDispatchException+0x122
fffff880'02a0c440 00000000'00000000 : 00000000'00000000 00000000'00000000 00000000'00000000 00000000'00000000 : nt!KiDispatchException+0x135


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!RtlDispatchException+122
fffff800'02ef3c22 410fb60c24      movzx   ecx,byte ptr [r12]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nt!RtlDispatchException+122

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  556356e8

IMAGE_VERSION:  6.1.7601.18869

FAILURE_BUCKET_ID:  X64_0xD3_VRF_nt!RtlDispatchException+122

BUCKET_ID:  X64_0xD3_VRF_nt!RtlDispatchException+122

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:x64_0xd3_vrf_nt!rtldispatchexception+122

FAILURE_ID_HASH:  {a7462664-d56e-ca97-7a53-f31727fb43aa}

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

ATUALIZAÇÃO: Eu desinstalei o webroot. A execução de verifier /standard /all não causa mais um arquivo BSOD e dmp, mas o problema com a função sleep permanece. Qualquer ajuda sobre os próximos passos é bem-vinda.

ATUALIZAÇÃO 2: O comando powercfg -a produz o seguinte

C:\windows\system32>powercfg -a
The following sleep states are available on this system: Standby ( S3 ) Hibernat
e Hybrid Sleep
The following sleep states are not available on this system:
Standby (S1)
        The system firmware does not support this standby state.
Standby (S2)
        The system firmware does not support this standby state.

Atualização 3: Parece que não consegui dormir para iniciar no modo de segurança. Saída de powercfg -energy : link

    

Answer 1

Forneça a exclusão do arquivo de hibernação.

link

1. Executar o CMD como administrador
2. powercfg -h now
3. Reinicializar
4. Verifique se hiberfil.sys foi excluído em C:\

Talvez seja necessário garantir que essa configuração seja desmarcada em Visualizar > Pasta Ver do Windows Explorer para ver visualmente o arquivo hiberfil.sys .

Reativar a hibernação (no CMD sendo executado como administrador): powercfg –h on

Reinicialize e teste novamente

Answer 2

Eu experimentei esse sono para retomar problemas normalmente com o Network & Cartões WiFi em vários laptops que tive ao longo das décadas.

Mais do que provavelmente, problemas de driver que podem ser ignorados de duas formas:

• Encontrar um driver - upgrade ou downgrade - que funciona sem problemas de suspensão
• Alterar / desativar o dispositivo, por exemplo Conexão sem fio antes de ir dormir e ligar novamente ao retomar. Isso funcionou para mim em muitos laptops da Compaq, HP, Dell, IBM & Lenovo Thinkpads.

Sem aprofundar as especificidades de cada dispositivo, os cards de dispositivos & ônibus sendo usados e versões específicas do driver, isso não será fácil / direto para resolver.

Específicos:

Se você estiver usando drivers do Vista, como visto no dump, então atualize os drivers para o Win 7/8 ou faça o downgrade para o XP. O driver mais horrível & Experiências WiFi que tive no meu Thinkpad foram com o Vista, e felizmente eu poderia até 7 ou até o XP.

    

Answer 3

Eu mesmo tive o mesmo problema. Os passos que eu sugiro que você seja:

1. Desinstalar / atualizar todos os drivers (Display / USB / rede em particular)
2. Redefinir o gerenciamento de energia para o padrão
3. Reinstale o sistema operacional

Infelizmente, o Passo 3 foi a resolução para mim - no entanto eu encontrei um monte de usuários que o passo 1 resolveu o problema para eles (ele ainda pode ser um adaptador de rede VPN ou Virtualbox em alguns casos)

Estou certo, no entanto, que é uma falha de software e não qualquer erro / falha de hardware.

    

Answer 4

A parte mais crítica do despertar de um computador são os procedimentos de driver para retornar o hardware no mesmo estado de antes de dormir.

Pode ser que um de seus motoristas seja responsável pelo acidente? Tente atualizar seus drivers. Você pode usar algum programa de coleta de drivers - por exemplo, o Driver Pack Solution - link