Verificação de bugs 0x116: VIDEO_TDR_FAILURE
A verificação de bugs VIDEO_TDR_FAILURE tem um valor de 0x00000116. Essa verificação de bugs indica que uma tentativa de redefinir o driver do monitor e recuperar-se de um tempo limite falhou.
Importante
Este artigo é para programadores. Se você é um cliente que recebeu um código de erro de tela azul ao usar o computador, consulte Solucionar problemas de erros de tela azul.
VIDEO_TDR_FAILURE parâmetros
| Parâmetro | Descrição |
|---|---|
| 1 | O ponteiro para o contexto de recuperação de TDR interno, se disponível. |
| 2 | Um ponteiro para o módulo de driver de dispositivo responsável (por exemplo, a marca de proprietário). |
| 3 | O código de erro da última operação com falha, se disponível. |
| 4 | Dados internos dependentes de contexto, se disponíveis. |
Causa
Um problema comum de estabilidade em gráficos ocorre quando o sistema aparece completamente congelado ou travado ao processar um comando ou operação do usuário final. Geralmente, a GPU está ocupada processando operações gráficas intensivas, normalmente durante o jogo. Não ocorrem atualizações de tela, e os usuários presumem que seu sistema esteja congelado. Os usuários geralmente aguardam alguns segundos e reinicializam o sistema pressionando o botão liga/desliga. O Windows tenta detectar essas situações problemáticas de travamento e recuperar dinamicamente uma área de trabalho responsiva.
Esse processo de detecção e recuperação é conhecido como TDR (Detecção e recuperação de tempo limite). O tempo limite padrão é de 2 segundos. No processo de TDR em placas de vídeo, o agendador de GPU do sistema operacional chama a função DxgkDdiResetFromTimeout do driver da miniporta de exibição para reinicializar o driver e redefinir a GPU.
Durante esse processo, o sistema operacional diz ao driver para não acessar o hardware ou a memória e dá a ele um curto período de tempo para que os threads em execução sejam concluídos. Se os threads não forem concluídos dentro do tempo limite, o sistema faz a verificação de bugs com 0x116 VIDEO_TDR_FAILURE. Para obter mais informações, consulte Sincronização de thread e TDR.
O sistema também pode fazer a verificação de bugs com VIDEO_TDR_FAILURE se vários eventos de TDR ocorrerem em um curto período de tempo. O valor padrão é mais de cinco TDRs em um minuto.
Se o processo de recuperação for bem-sucedido, aparecerá uma mensagem indicando que o "driver de vídeo parou de responder e foi recuperado".
Para mais informações, consulte detecção e recuperação de tempo limite (TDR),, chaves de registro do TDR e alterações do TDR no Windows 8 e posterior.
Resolução
A GPU está demorando mais do que o permitido para exibir gráficos em seu monitor. Esse comportamento pode ocorrer por uma ou mais das seguintes razões:
- Talvez seja necessário instalar as atualizações mais recentes do driver do monitor, para que ele ofereça suporte adequado ao processo TDR.
- Problemas de hardware que afetam a capacidade da placa de vídeo de funcionar corretamente, inclusive:
- Componentes com overclock, como a placa-mãe
- Compatibilidade e configurações incorretas de componentes (principalmente configuração e tempos de memória)
- Resfriamento insuficiente do sistema
- Energia insuficiente do sistema
- Peças avariadas (módulos de memória, placas-mãe etc.)
- Efeitos visuais ou muitos programas em execução em segundo plano podem deixar o PC mais lento, fazendo com que a placa de vídeo não responda conforme necessário.
A extensão de depuração !analyze exibe informações sobre a verificação de bugs e pode ser útil para determinar a causa raiz.
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
VIDEO_TDR_FAILURE (116)
Attempt to reset the display driver and recover from timeout failed.
Arguments:
Arg1: ffffe000c2c404c0, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: fffff8016470c14c, The pointer into responsible device driver module (e.g. owner tag).
Arg3: ffffffffc000009a, Optional error code (NTSTATUS) of the last failed operation.
Arg4: 0000000000000004, Optional internal context dependent data.
...
O nome do módulo com falha também é mostrado.
MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys
Você pode usar o comando lm (Lista de módulos carregados) para exibir informações sobre o driver com falha, incluindo o registro de data e hora.
1: kd> lmvm nvlddmkm
Browse full module list
start end module name
fffff801`63ec0000 fffff801`649a7000 nvlddmkm T (no symbols)
Loaded symbol image file: nvlddmkm.sys
Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys
Image name: nvlddmkm.sys
Browse all global symbols functions data
Timestamp: Wed Jul 8 15:43:44 2015 (559DA7A0)
CheckSum: 00AA7491
ImageSize: 00AE7000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
O parâmetro 1 contém um ponteiro para o TDR_RECOVERY_CONTEXT. Conforme mostrado na saída !analyze, se você tiver símbolos para o código associado, poderá usar o comando dt para exibir esses dados.
1: kd> dt dxgkrnl!_TDR_RECOVERY_CONTEXT ffffe000c2c404c0
+0x000 Signature : 0x52445476
+0x008 pState : 0xffffe000`c2b12a40 ??
+0x010 TimeoutReason : 9 ( TdrEngineTimeoutPromotedToAdapterReset )
+0x018 Tick : _ULARGE_INTEGER 0xb2
+0x020 pAdapter : 0xffffe000`c2a89010 DXGADAPTER
+0x028 pVidSchContext : (null)
+0x030 GPUTimeoutData : _TDR_RECOVERY_GPU_DATA
+0x048 CrtcTimeoutData : _TDR_RECOVERY_CONTEXT::<unnamed-type-CrtcTimeoutData>
+0x050 pProcessName : (null)
+0x058 DbgOwnerTag : 0xfffff801`6470c14c
+0x060 PrivateDbgInfo : _TDR_DEBUG_REPORT_PRIVATE_INFO
+0xb00 pDbgReport : 0xffffe000`c2c3f750 _WD_DEBUG_REPORT
+0xb08 pDbgBuffer : 0xffffc000`bd000000 Void
+0xb10 DbgBufferSize : 0x37515
+0xb18 pDumpBufferHelper : (null)
+0xb20 pDbgInfoExtension : 0xffffc000`ba7e47a0 _DXGKARG_COLLECTDBGINFO_EXT
+0xb28 pDbgBufferUpdatePrivateInfo : 0xffffc000`bd000140 Void
+0xb30 ReferenceCount : 0n1
+0xb38 pResetCompletedEvent : (null)
O parâmetro 2 contém um ponteiro para o módulo de driver de dispositivo responsável (por exemplo, a marca de proprietário).
1: kd> ub fffff8016470c14c
nvlddmkm+0x84c132:
fffff801`6470c132 cc int 3
fffff801`6470c133 cc int 3
fffff801`6470c134 48ff254d2deaff jmp qword ptr [nvlddmkm+0x6eee88 (fffff801`645aee88)]
fffff801`6470c13b cc int 3
fffff801`6470c13c 48ff252d2eeaff jmp qword ptr [nvlddmkm+0x6eef70 (fffff801`645aef70)]
fffff801`6470c143 cc int 3
fffff801`6470c144 48ff257d2deaff jmp qword ptr [nvlddmkm+0x6eeec8 (fffff801`645aeec8)]
fffff801`6470c14b cc int 3
Talvez você queira examinar o rastreamento da pilha usando o comando k, kb, kc, kd, kp, kP, kv (exibir backtrace da pilha).
1: kd> k
# Child-SP RetAddr Call Site
00 ffffd001`7d53d918 fffff801`61ba2b4c nt!KeBugCheckEx [d:\th\minkernel\ntos\ke\amd64\procstat.asm @ 122]
01 ffffd001`7d53d920 fffff801`61b8da0e dxgkrnl!TdrBugcheckOnTimeout+0xec [d:\th\windows\core\dxkernel\dxgkrnl\core\dxgtdr.cxx @ 2731]
02 ffffd001`7d53d960 fffff801`61b8dd7f dxgkrnl!ADAPTER_RENDER::Reset+0x15e [d:\th\windows\core\dxkernel\dxgkrnl\core\adapter.cxx @ 19443]
03 ffffd001`7d53d990 fffff801`61ba2385 dxgkrnl!DXGADAPTER::Reset+0x177 [d:\th\windows\core\dxkernel\dxgkrnl\core\adapter.cxx @ 19316]
04 ffffd001`7d53d9e0 fffff801`63c5fba7 dxgkrnl!TdrResetFromTimeout+0x15 [d:\th\windows\core\dxkernel\dxgkrnl\core\dxgtdr.cxx @ 2554]
05 ffffd001`7d53da10 fffff801`63c47e5d dxgmms1!VidSchiRecoverFromTDR+0x11b [d:\th\windows\core\dxkernel\dxgkrnl\dxgmms1\vidsch\vidscher.cxx @ 1055]
06 ffffd001`7d53dbc0 fffff801`aa55c698 dxgmms1!VidSchiWorkerThread+0x8d [d:\th\windows\core\dxkernel\dxgkrnl\dxgmms1\vidsch\vidschi.cxx @ 426]
07 ffffd001`7d53dc00 fffff801`aa5c9306 nt!PspSystemThreadStartup+0x58 [d:\th\minkernel\ntos\ps\psexec.c @ 6845]
08 ffffd001`7d53dc60 00000000`00000000 nt!KxStartSystemThread+0x16 [d:\th\minkernel\ntos\ke\amd64\threadbg.asm @ 80]
Você também pode definir um ponto de quebra no código que leva a esse código de parada e tentar avançar uma única etapa no código de falha, se conseguir reproduzir consistentemente o código de parada.
Para obter mais informações, consulte Analisar arquivos de despejo de memória usando o WinDbg.
Se você não estiver equipado para usar o depurador do Windows para resolver esse problema, poderá usar algumas técnicas básicas de solução de problemas.
Verifique o log do sistema no visualizador de eventos para ver se há outras mensagens de erro que possam ajudar a identificar o dispositivo ou driver que está causando essa verificação de bugs.
Se um driver for identificado na mensagem de verificação de bugs, desabilite o driver ou verifique com o fabricante se há atualizações de driver.
Verifique se todos os softwares relacionados a gráficos, como DirectX e OpenGL, estão atualizados e se todos os aplicativos que usam muitos gráficos (como jogos) estão totalmente corrigidos.
Confirme se o novo hardware que foi instalado é compatível com a versão instalada do Windows. Por exemplo, você pode obter informações sobre o hardware necessário em Especificações do Windows 10.
Execute a ferramenta de diagnóstico de memória do Windows para testar a memória. Na caixa de pesquisa do painel de controle, insira Memory, e depois selecione Diagnosticar problemas de memória do computador. Depois que o teste for executado, use o visualizador de eventos para exibir os resultados no log do sistema. Procure a entrada MemoryDiagnostics-Results para exibir os resultados.
Você pode tentar executar o diagnóstico de hardware fornecido pelo fabricante do sistema.
Use o modo de segurança
Use o Modo de segurança para ajudar a isolar esse problema. O uso do Modo de segurança carrega apenas os drivers e serviços do sistema mínimos necessários durante a inicialização do Windows.
- Para entrar no Modo de segurança, vá para Atualização e segurança, em Configurações.
- Selecione Recuperação>Inicialização avançada para inicializar no modo de manutenção.
- No menu resultante, escolha Solução de problemas>Opções avançadas>Configurações de inicialização>Reiniciar.
- Depois que o Windows reiniciar na tela Configurações de inicialização, selecione a opção 4, 5 ou 6 para inicializar no Modo de segurança.
O Modo de segurança costuma estar disponível ao pressionar uma tecla de função durante a inicialização, por exemplo, F8. Consulte as informações do fabricante para obter opções específicas de inicialização.
Para obter informações gerais sobre solução de problemas, consulte Analisar dados de tela azul de verificação de bugs.
Comentários
Para obter informações sobre os requisitos que os dispositivos de hardware devem atender ao implementar o TDR, consulte a documentação do Windows Hardware Lab Kit. Por exemplo, TDR2: gráficos de teste de dois dispositivos padrão.