Partilhar via


Verificação de Erro 0x9F: DRIVER_POWER_STATE_FAILURE

A verificação de bug DRIVER_POWER_STATE_FAILURE tem um valor de 0x0000009F. Esta verificação de bug indica que o driver está em um estado de energia inconsistente ou inválido.

Importante

Este artigo é para programadores. Se for um cliente que recebeu um código de erro de ecrã azul enquanto utiliza o computador, consulte Resolução de problemas de erros de ecrã azul.

DRIVER_POWER_STATE_FAILURE Parâmetros

O parâmetro 1 indica o tipo de violação.

Parâmetro 1 Parâmetro 2 Parâmetro 3 Parâmetro 4 Motivo
0x1 O objeto do dispositivo Reservado Reservado O objeto de dispositivo que está sendo liberado ainda tem uma solicitação de energia pendente que não foi concluída.
0x2 O objeto de dispositivo do dispositivo de destino, se estiver disponível O objeto do dispositivo O objeto driver, se estiver disponível O objeto de dispositivo concluiu o pacote de solicitação de E/S (IRP) para a solicitação de estado de energia do sistema, mas não chamou PoStartNextPowerIrp.
0x3 O objeto de dispositivo físico (DOP) da pilha nt!_TRIAGE_9F_POWER. O IRP bloqueado Um objeto de dispositivo está bloqueando um IRP há muito tempo.
0x4 Valor de tempo limite, em segundos. O thread atualmente segurando o bloqueio Plug-and-Play (PnP). nt!_TRIAGE_9F_PNP. A transição do estado de energia atingiu o tempo limite de espera para sincronizar com o subsistema PnP.
0x5 Objeto de dispositivo físico da pilha O objeto POP_FX_DEVICE Reservado - 0 O dispositivo não conseguiu concluir uma transição de energia direcionada dentro do período de tempo necessário.
0x6 O objeto POP_FX_DEVICE Indica se esta foi uma conclusão de Directed Power Down(1) ou Power Up(0). Reservado - 0 O dispositivo não concluiu seu retorno de chamada de transição de energia direcionada com êxito.
0x500 Reservado O objeto de dispositivo do dispositivo de destino, se disponível Objeto do dispositivo O objeto de dispositivo concluiu o IRP para a solicitação de estado de energia do sistema, mas não chamou PoStartNextPowerIrp.

Motivo

Para obter uma descrição das possíveis causas, consulte a descrição de cada código na seção Parâmetros. As causas comuns incluem:

  • Objeto de dispositivo liberado com solicitação de energia pendente incompleta
  • Tempo limite de transição do estado de energia esgotado
  • Objeto de dispositivo bloqueando um IRP
  • IRP concluído, mas não chamou PoStartNextPowerIrp

Resolução

Para determinar a causa específica e criar uma correção de código, é necessária experiência de programação e acesso ao código-fonte do módulo com falha.

A verificação de bugs de depuração 0x9F quando o Parâmetro 1 é igual a 0x3

  • Em um depurador do kernel, use o comando !analyze -v para executar a análise inicial de verificação de bugs. A análise detalhada exibe o endereço do nt! TRIAGE_9F_POWER estrutura, que está em Arg3.
kd>!analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

    DRIVER_POWER_STATE_FAILURE (9f)
    A driver has failed to complete a power IRP within a specific time.
    Arguments:
    Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
    Arg2: fffffa8007b13440, Physical Device Object of the stack
    Arg3: fffff8000386c3d8, nt!_TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
    Arg4: fffffa800ab61bd0, The blocked IRP

Se um driver que é responsável pelo erro pode ser identificado, seu nome é impresso na tela azul e armazenado na memória no local (PUNICODE_STRING) KiBugCheckDriver. Você pode usar dx (display debugger object model expression), um comando do depurador, para exibir isso: dx KiBugCheckDriver.

O nt! TRIAGE_9F_POWER estrutura fornece informações adicionais de verificação de bug que podem ajudá-lo a determinar a causa dessa verificação de bug. A estrutura pode fornecer uma lista de todos os IRPs de energia pendentes, uma lista de todos os threads de trabalho de IRP de energia e um ponteiro para a fila de trabalhadores do sistema atrasados.

  • Use o comando dt (Display Type) e especifique o nt! TRIAGE_9F_POWER estrutura usando o endereço de Arg3.
    0: kd> dt nt!_TRIAGE_9F_POWER fffff8000386c3d8
       +0x000 Signature        : 0x8000
       +0x002 Revision         : 1
       +0x008 IrpList          : 0xfffff800`01c78bd0 _LIST_ENTRY [ 0xfffffa80`09f43620 - 0xfffffa80`0ad00170 ]
       +0x010 ThreadList       : 0xfffff800`01c78520 _LIST_ENTRY [ 0xfffff880`009cdb98 - 0xfffff880`181f2b98 ]
       +0x018 DelayedWorkQueue : 0xfffff800`01c6d2d8 _TRIAGE_EX_WORK_QUEUE

O comando dt (Display Type) exibe a estrutura. Você pode usar vários comandos do depurador para seguir os campos LIST_ENTRY para examinar a lista de IRPs pendentes e os threads de trabalho de IRP de energia.

  • Use o comando !irp para examinar o IRP que foi bloqueado. O endereço deste IRP está em Arg4.
    0: kd> !irp fffffa800ab61bd0
    Irp is active with 7 stacks 6 is current (= 0xfffffa800ab61e08)
     No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
         cmd  flg cl Device   File     Completion-Context
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
    >[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
                0 e1 fffffa800783f060 00000000 00000000-00000000    pending
               \Driver\HidUsb
                Args: 00016600 00000001 00000004 00000006
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-fffffa800ad00170    

                Args: 00000000 00000000 00000000 00000000
  • Use o comando !devstack com o endereço DOP no Arg2 para exibir informações associadas ao driver com falha.
    0: kd> !devstack fffffa8007b13440
      !DevObj           !DrvObj            !DevExt           ObjectName
      fffffa800783f060  \Driver\HidUsb     fffffa800783f1b0  InfoMask field not found for _OBJECT_HEADER at fffffa800783f030

    > fffffa8007b13440  \Driver\usbhub     fffffa8007b13590  Cannot read info offset from nt!ObpInfoMaskToOffset

    !DevNode fffffa8007ac8a00 :
      DeviceInst is "USB\VID_04D8&PID_0033\5&46fa7b7&0&1"
      ServiceName is "HidUsb"
  • Use o comando !poaction para exibir os threads que manipulam as operações de energia e quaisquer IRPs de energia alocados.
    3: kd> !poaction
    PopAction: fffff801332f3fe0
      State..........: 0 - Idle
      Updates........: 0 
      Action.........: None
      Lightest State.: Unspecified
      Flags..........: 10000003 QueryApps|UIAllowed
      Irp minor......: ??
      System State...: Unspecified
      Hiber Context..: 0000000000000000

    Allocated power irps (PopIrpList - fffff801332f44f0)
      IRP: ffffe0001d53d8f0 (wait-wake/S0), PDO: ffffe00013cae060
      IRP: ffffe0001049a5d0 (wait-wake/S0), PDO: ffffe00012d42050
      IRP: ffffe00013d07420 (set/D3,), PDO: ffffe00012daf840, CURRENT: ffffe00012dd5040
      IRP: ffffe0001e5ac5d0 (wait-wake/S0), PDO: ffffe00013d33060
      IRP: ffffe0001ed3e420 (wait-wake/S0), PDO: ffffe00013c96060
      IRP: ffffe000195fe010 (wait-wake/S0), PDO: ffffe00012d32050

    Irp worker threads (PopIrpThreadList - fffff801332f3100)
      THREAD: ffffe0000ef5d040 (static)
      THREAD: ffffe0000ef5e040 (static), IRP: ffffe00013d07420, DEVICE: ffffe00012dd5040

    PopAction: fffff801332f3fe0
      State..........: 0 - Idle
      Updates........: 0 
      Action.........: None
      Lightest State.: Unspecified
      Flags..........: 10000003 QueryApps|UIAllowed
      Irp minor......: ??
      System State...: Unspecified
      Hiber Context..: 0000000000000000

    Allocated power irps (PopIrpList - fffff801332f44f0)
      IRP: ffffe0001d53d8f0 (wait-wake/S0), PDO: ffffe00013cae060
      IRP: ffffe0001049a5d0 (wait-wake/S0), PDO: ffffe00012d42050
      IRP: ffffe00013d07420 (set/D3,), PDO: ffffe00012daf840, CURRENT: ffffe00012dd5040
      IRP: ffffe0001e5ac5d0 (wait-wake/S0), PDO: ffffe00013d33060
      IRP: ffffe0001ed3e420 (wait-wake/S0), PDO: ffffe00013c96060
      IRP: ffffe000195fe010 (wait-wake/S0), PDO: ffffe00012d32050

    Irp worker threads (PopIrpThreadList - fffff801332f3100)
      THREAD: ffffe0000ef5d040 (static)
      THREAD: ffffe0000ef5e040 (static), IRP: ffffe00013d07420, DEVICE: ffffe00012dd5040
  • Se você estiver trabalhando com um driver KMDF, use as Extensões da Estrutura do Driver do Windows (!wdfkd) para coletar informações adicionais.

    Use !wdfkd.wdflogdump<seu nome> de driver para ver se o KMDF está esperando por você para ACK quaisquer solicitações pendentes.

    Use !wdfkd.wdfdevicequeuesseu WDFDEVICE> para examinar todas as solicitações pendentes <e em que estado elas estão.

  • Use a extensão !stacks para examinar o estado de cada thread e procure um thread que possa estar atrasando a transição do estado de energia.

  • Para ajudá-lo a determinar a causa do erro, considere as seguintes perguntas:

    • Quais são as características do driver de objeto de dispositivo físico (PDO) (Arg2)?
    • Você consegue encontrar o tópico bloqueado? Quando você examina o thread com o comando !thread debugger, em que consiste o thread?
    • Existe IO associado ao thread que o está bloqueando? Que símbolos estão na pilha?
    • Quando você examina o IRP de energia bloqueado, o que você nota?
    • Qual é o código de função secundária PnP do IRP de potência?

A verificação de bugs de depuração 0x9F quando o parâmetro 1 é igual a 0x4

  • Em um depurador do kernel, use o comando !analyze -v para executar a análise inicial de verificação de bugs. A análise detalhada exibe o endereço do nt! TRIAGE_9F_PNP estrutura, que está no parâmetro 4 (arg4).
    kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_POWER_STATE_FAILURE (9f)
    A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
    Arguments:
    Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp
            subsystem.
    Arg2: 00000258, Timeout in seconds.
    Arg3: 84e01a70, The thread currently holding on to the Pnp lock.
    Arg4: 82931b24, nt!TRIAGE_9F_PNP on Win7

O nt! TRIAGE_9F_PNP estrutura fornece informações adicionais de verificação de bugs que podem ajudá-lo a determinar a causa do erro. O nt! TRIAGE_9F_PNP estrutura fornece um ponteiro para uma estrutura que contém a lista de IRPs PnP despachados (mas não concluídos) e fornece um ponteiro para a fila de trabalhadores do sistema atrasados.

  • Use o comando dt (Display Type) e especifique a nt!_TRIAGE_9F_PNP estrutura e o endereço que você encontrou no Arg4.
    kd> dt nt!_TRIAGE_9F_PNP 82931b24
       +0x000 Signature        : 0x8001
       +0x002 Revision         : 1
       +0x004 CompletionQueue  : 0x82970e20 _TRIAGE_PNP_DEVICE_COMPLETION_QUEUE
       +0x008 DelayedWorkQueue : 0x829455bc _TRIAGE_EX_WORK_QUEUE

O comando dt (Display Type) exibe a estrutura. Você pode usar comandos do depurador para seguir os campos LIST_ENTRY para examinar a lista de IRPs PnP pendentes.

Para ajudá-lo a determinar a causa do erro, considere as seguintes perguntas:

  • Existe um IRP associado ao thread?

  • Existe algum IO na CompletionQueue?

  • Que símbolos estão na pilha?

  • Consulte as técnicas adicionais descritas acima no parâmetro 0x3.

Observações

Se você não estiver equipado para depurar esse problema usando as técnicas descritas acima, você pode usar algumas técnicas básicas de solução de problemas.

  • Se novos drivers de dispositivo ou serviços do sistema tiverem sido adicionados recentemente, tente removê-los ou atualizá-los. Tente determinar o que mudou no sistema que fez com que o novo código de verificação de bug aparecesse.

  • Procure no Gestor de Dispositivos para ver se algum dispositivo está marcado com o ponto de exclamação (!). Revise o log de eventos exibido nas propriedades do driver para verificar se há um driver com falha. Tente atualizar o driver relacionado.

  • Verifique o Log do Sistema no Visualizador de Eventos para obter mensagens de erro adicionais que possam ajudar a identificar o dispositivo ou driver que está causando o erro. Procure erros críticos no log do sistema que ocorreram na mesma janela de tempo da tela azul.

  • Para tentar isolar a causa, desative temporariamente a economia de energia usando o painel de controle, opções de energia. Alguns problemas de driver estão relacionados com os vários estados de hibernação do sistema e a suspensão e retomada de energia.

  • Se adicionou recentemente hardware ao sistema, tente removê-lo ou substituí-lo. Ou verifique com o fabricante se existem patches disponíveis.

  • Você pode tentar executar o diagnóstico de hardware fornecido pelo fabricante do sistema.

  • Verifique com o fabricante se um sistema ACPI/BIOS atualizado ou outro firmware está disponível.

Ver também

Análise de despejo de memória usando os depuradores do Windows (WinDbg)

Analisando um arquivo de despejo de Kernel-Mode com o WinDbg

Referência de Código da Verificação de Erros