Como explicar KMODE_EXCEPTION_NOT_HANDLED em ntoskrnl.exe +70380?

Question

Eu tenho um quebra-cabeça muito difícil com telas azuis no windows 7. Algumas semanas atrás, um computador começou a ter algumas telas blu durante a computação de cartão inteligente. Esta é uma máquina POS com um cartão inteligente, para cada receita emitida tem que calcular um hash no cartão inteligente.

Então comecei a procurar por drivers / erros de hardware, atualizei alguns drivers (também se os drivers antigos funcionassem por muitos anos sem erros) ... sem sucesso. Por isso mudei o smartcard e o smartcard, mas ainda assim não funcionou. Eu também tentei mudar todo o sistema POS para outro computador, mas a cada 10-20 hash de computação, a tela azul apareceu novamente.

Eu tentei analisar o arquivo de despejo, e parece que o componente com falha foi ntoskrnl.exe, e isso não parece ser um erro conectado ao driver.

Este é o arquivo de despejo: link

Estes são os detalhes do dump:

KMODE_EXCEPTION_NOT_HANDLED 0x0000001e  ffffffff'c0000005   00000000'00000000   00000000'00000008   00000000'00000000   ntoskrnl.exe    ntoskrnl.exe+70380

e os dados da análise de despejo:

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.23392.amd64fre.win7sp1_ldr.160317-0600
Machine Name:
Kernel base = 0xfffff800'02e4f000 PsLoadedModuleList = 0xfffff800'03091730
Debug session time: Sat May  7 14:48:33.499 2016 (UTC - 4:00)
System Uptime: 0 days 0:24:58.841
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000008, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

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

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP: 
+0
00000000'00000000 ??              ???

EXCEPTION_PARAMETER1:  0000000000000008

EXCEPTION_PARAMETER2:  0000000000000000

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800030fb100
GetUlongFromAddress: unable to read from fffff800030fb1c8
 0000000000000000 Nonpaged pool

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

BUGCHECK_STR:  0x1e_c0000005

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  1

TRAP_FRAME:  fffff8800701b7f0 -- (.trap 0xfffff8800701b7f0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800737ee70 rbx=0000000000000000 rcx=fffffa8008f13a20
rdx=fffffa800737ee70 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=fffff8800701b980 rbp=0000000000000000
 r8=fffffa800398b010  r9=fffff8000303de80 r10=fffffa80036fb570
r11=fffffa8004a55c10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
00000000'00000000 ??              ???
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002f3f512 to fffff80002ebf380

STACK_TEXT:  
fffff880'0701af68 fffff800'02f3f512 : 00000000'0000001e ffffffff'c0000005 00000000'00000000 00000000'00000008 : nt!KeBugCheckEx
fffff880'0701af70 fffff800'02ebea02 : fffff880'0701b748 fffffa80'c0000120 fffff880'0701b7f0 00000000'00000000 : nt! ?? ::FNODOBFM::'string'+0x40e2d
fffff880'0701b610 fffff800'02ebd57a : 00000000'00000008 00000000'00000000 00000000'00000200 fffffa80'c0000120 : nt!KiExceptionDispatch+0xc2
fffff880'0701b7f0 00000000'00000000 : 00000000'00000000 00000000'00000000 fffff880'0507cf00 fffffa80'08239bb8 : nt!KiPageFault+0x23a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::'string'+40e2d
fffff800'02f3f512 cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt! ?? ::FNODOBFM::'string'+40e2d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  56eb24e6

FAILURE_BUCKET_ID:  X64_0x1e_c0000005_nt!_??_::FNODOBFM::_string_+40e2d

BUCKET_ID:  X64_0x1e_c0000005_nt!_??_::FNODOBFM::_string_+40e2d

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

A BSOD está sempre presente na mesma operação: o cálculo de hash de smart card, mas não é sistemático porque pode funcionar para muitos cálculos antes de travar e às vezes funciona por alguns dias sem erros.

Eu tentei ler sobre a última atualização do Windows da máquina feita alguns dias antes do primeiro acidente: KB2952664, KB3137061, KB3138901, KB3142042, KB3145739, KB3146706, KB3146963, KB3147071, KB3148198, KB3148851, KB3149090 mas nada parece estar conectado ao smartcard, eu também tentei desinstalá-los sem sorte.

Após alguns dias, outro computador POS começou a ter o mesmo problema com o mesmo erro. Esse era um sistema com outro hardware de computador, mas com o mesmo smartcard, leitor de cartão inteligente e impressora de recepção térmica. Eu enfatizo que esses sistemas funcionaram bem várias vezes e a única mudança recente em que consegui pensar foram as atualizações do Windows.

No final, resolvi a atualização do O.S. do Windows 7 para o Windows 10, mas isso não é realmente uma solução!

Você pode me dizer como ler esses detalhes de despejo? Existe alguma informação que eu não esteja considerando?

    

Answer 1

Parece que o seu problema está no iusb3xhc.sys, um driver para um controlador host USB 3.

A ferramenta de análise integrada do depurador, o comando !analyze -v , chegou a essa conclusão. Para usá-lo, você deve instalar o pacote "Debugging Tools for Windows" e configurar o caminho do arquivo de símbolo. Em seguida, abra o arquivo de despejo no WinDbg e digite! Analyze -v no prompt de comando.

Para fazer isso manualmente, abra o arquivo de despejo e use o comando kv:

0: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880'0701af68 fffff800'02f3f512 : 00000000'0000001e ffffffff'c0000005 00000000'00000000 00000000'00000008 : nt!KeBugCheckEx
fffff880'0701af70 fffff800'02ebea02 : fffff880'0701b748 fffffa80'c0000120 fffff880'0701b7f0 00000000'00000000 : nt! ?? ::FNODOBFM::'string'+0x40e2d
fffff880'0701b610 fffff800'02ebd57a : 00000000'00000008 00000000'00000000 00000000'00000200 fffffa80'c0000120 : nt!KiExceptionDispatch+0xc2
fffff880'0701b7f0 00000000'00000000 : 00000000'00000000 00000000'00000000 fffff880'0507cf00 fffffa80'08239bb8 : nt!KiPageFault+0x23a (TrapFrame @ fffff880'0701b7f0)

Isso mostra uma pilha muito pequena. Mas na borda direita da última linha, vemos uma chamada do KiPageFault (indicando que o processamento de uma falha de acesso à memória estava em andamento) com uma indicação de "Trap frame". O quadro de trap registra o estado do processador no ponto da exceção de falha da página. O comando .trap do depurador nos permite definir o estado do depurador (em parte, de qualquer forma) para o que está gravado no quadro de interceptação:

0: kd> .trap fffff880'0701b7f0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed.
rax=fffffa800737ee70 rbx=0000000000000000 rcx=fffffa8008f13a20
rdx=fffffa800737ee70 rsi=0000000000000001 rdi=0000000000000000
rip=0000000000000000 rsp=fffff8800701b980 rbp=0000000000000000
 r8=fffffa800398b010  r9=fffff8000303de80 r10=fffffa80036fb570
r11=fffffa8004a55c10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
00000000'00000000 ??               ???

Agora, tentamos novamente o comando kv :

0: kd> kv
  *** Stack trace for last set context - .thread/.cxr resets it
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880'0701b980 00000000'00000000 : 00000000'00000000 fffff880'0507cf00 fffffa80'08239bb8 fffff880'0701ba18 : 0x0
fffff880'0701b988 00000000'00000000 : fffff880'0507cf00 fffffa80'08239bb8 fffff880'0701ba18 fffff880'0507cf60 : 0x0
fffff880'0701b990 fffff880'0507cf00 : fffffa80'08239bb8 fffff880'0701ba18 fffff880'0507cf60 fffffa80'08f13a50 : 0x0
fffff880'0701b998 fffffa80'08239bb8 : fffff880'0701ba18 fffff880'0507cf60 fffffa80'08f13a50 00000000'00000000 : iusb3xhc+0x7cf00
fffff880'0701b9a0 fffff880'0701ba18 : fffff880'0507cf60 fffffa80'08f13a50 00000000'00000000 00000000'0000004f : 0xfffffa80'08239bb8
fffff880'0701b9a8 fffff880'0507cf60 : fffffa80'08f13a50 00000000'00000000 00000000'0000004f fffff880'009f1380 : 0xfffff880'0701ba18
fffff880'0701b9b0 fffffa80'08f13a50 : 00000000'00000000 00000000'0000004f fffff880'009f1380 00000000'00000000 : iusb3xhc+0x7cf60
fffff880'0701b9b8 00000000'00000000 : 00000000'0000004f fffff880'009f1380 00000000'00000000 00000000'00000100 : 0xfffffa80'08f13a50
fffff880'0701b9c0 00000000'0000004f : fffff880'009f1380 00000000'00000000 00000000'00000100 00000000'00000000 : 0x0
fffff880'0701b9c8 fffff880'009f1380 : 00000000'00000000 00000000'00000100 00000000'00000000 00000000'00000001 : 0x4f
fffff880'0701b9d0 00000000'00000000 : 00000000'00000100 00000000'00000000 00000000'00000001 fffff880'009f1f60 : 0xfffff880'009f1380
fffff880'0701b9d8 00000000'00000100 : 00000000'00000000 00000000'00000001 fffff880'009f1f60 fffff800'02eb4fbd : 0x0
fffff880'0701b9e0 00000000'00000000 : 00000000'00000001 fffff880'009f1f60 fffff800'02eb4fbd fffffa80'04807810 : 0x100
fffff880'0701b9e8 00000000'00000001 : fffff880'009f1f60 fffff800'02eb4fbd fffffa80'04807810 00000000'00000000 : 0x0
fffff880'0701b9f0 fffff880'009f1f60 : fffff800'02eb4fbd fffffa80'04807810 00000000'00000000 00000000'00000000 : 0x1
fffff880'0701b9f8 fffff800'02eb4fbd : fffffa80'04807810 00000000'00000000 00000000'00000000 00000000'00000000 : 0xfffff880'009f1f60
fffff880'0701ba00 fffff800'02ec48c2 : 00000000'00000001 00000000'00000000 00000000'0000004f fffffa80'036c66d0 : nt!KiCommitThreadWait+0x3dd
fffff880'0701ba90 fffff800'0319365f : fffffa80'04807b40 fffffa80'04807b40 00000000'00000000 fffffa80'0000004f : nt!KeDelayExecutionThread+0x186
fffff880'0701bb00 fffff800'03193fed : 00000000'00000000 ffffffff'fffe7960 00000000'00000000 00000000'00000000 : nt!IoCancelThreadIo+0x6f
fffff880'0701bb30 fffff800'03194651 : 00000000'00000000 fffff800'03158400 fffffa80'075e6100 00000000'00000000 : nt!PspExitThread+0x58d

Esta pilha está corrompida (observe todos os 0s onde deve haver endereços de sites de chamada), mas está claro que as chamadas do driver iusb3xhc.sys estavam em andamento.

Solução sugerida: Tenho certeza de que o driver foi escrito pela Intel. Vá para o site da Intel e veja se há uma versão mais recente que a fornecida pela Microsoft. Se não houver, ou se não ajudar, tente as anteriores. Último recurso: desative o controlador host USB 3 e viva com as velocidades USB 2 até que um driver melhor seja fornecido.