Vérification de bogue 0x9F : DRIVER_POWER_STATE_FAILURE

  • Article

Le contrôle de bogue DRIVER_POWER_STATE_FAILURE a la valeur 0x0000009F. Ce contrôle de bogue indique que le pilote est dans un état d’alimentation incohérent ou non valide.

Important

Cette rubrique s’adresse aux développeurs. Si vous êtes un client qui a reçu un code d’erreur d’écran bleu lors de l’utilisation de votre ordinateur, consultez résoudre les erreurs d’écran bleu.

Paramètres DRIVER_POWER_STATE_FAILURE

Le paramètre 1 indique le type de violation.

Paramètre 1 Paramètre 2 Paramètre 3 Paramètre 4 Cause
0x1 Objet Device Réservé Réservé L’objet appareil qui est libéré a toujours une demande d’alimentation non terminée.
0x2 L’objet d’appareil de l’appareil cible, s’il est disponible Objet Device Objet Driver, s’il est disponible L’objet périphérique a terminé le paquet de demande d’e/s (IRP) pour la demande d’état d’alimentation du système, mais il n’a pas appelé PoStartNextPowerIrp.
0x3 Objet d’appareil physique (PDO) de la pile ®! TRIAGE_9F_POWER. IRP bloqué Un objet appareil a bloqué un IRP trop longtemps.
0x4 Valeur du délai d’attente, en secondes. Thread qui détient actuellement le verrou plug-and-Play (PnP). ®! TRIAGE_9F_PNP. La transition de l’état d’alimentation a expiré en attendant la synchronisation avec le sous-système PnP.
0x5 Objet d’appareil physique de la pile Objet POP_FX_DEVICE Réservé-0 L’appareil n’a pas réussi à effectuer une transition d’alimentation dirigée dans le délai imparti.
0x6 Objet POP_FX_DEVICE Indique s’il s’agit d’une mise hors tension (1) ou d’une mise sous tension (0) dirigée. Réservé-0 L’appareil n’a pas réussi à terminer le rappel de transition de l’alimentation.
0x500 Réservé L’objet d’appareil de l’appareil cible, s’il est disponible Objet d’appareil L’objet appareil a terminé l’IRP pour la demande d’état d’alimentation du système, mais il n’a pas appelé PoStartNextPowerIrp.

Cause

Pour obtenir une description des causes possibles, consultez la description de chaque code dans la section paramètres. Les causes courantes sont les suivantes :

  • Objet appareil libéré avec une demande d’alimentation non terminée en suspens
  • La transition de l’état d’alimentation a expiré
  • Objet périphérique bloquant un IRP
  • IRP terminée mais n’a pas appelé PoStartNextPowerIrp

Résolution

Pour déterminer la cause spécifique et créer un correctif de code, l’expérience de programmation et l’accès au code source du module Faulted sont requis.

Débogage de la vérification de bogue 0x9F lorsque le paramètre 1 est égal à 0x3

  • Dans un débogueur de noyau, utilisez la commande ! analyze-v pour effectuer l’analyse de la vérification de bogue initiale. L’analyse détaillée affiche l’adresse de l' NT ! TRIAGE_9F_POWER structure, qui se trouve dans 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

Si un pilote responsable de l’erreur peut être identifié, son nom est imprimé sur l’écran bleu et stocké en mémoire à l’emplacement (PUNICODE_STRING) KiBugCheckDriver. Vous pouvez utiliser DX (afficher l’expression du modèle objet du débogueur), une commande du débogueur pour afficher ce qui suit : dx KiBugCheckDriver .

Le NT ! TRIAGE_9F_POWER structure fournit des informations supplémentaires sur la vérification des bogues qui peuvent vous aider à déterminer la cause de cette vérification de bogue. La structure peut fournir une liste de tous les IRP d’alimentation en suspens, une liste de tous les threads de travail IRP Power et un pointeur vers la file d’attente de travail système retardée.

  • Utilisez la commande DT (type d’affichage) et spécifiez l’option NT ! TRIAGE_9F_POWER structure à l’aide de l’adresse 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

La commande DT (type d’affichage) affiche la structure. Vous pouvez utiliser différentes commandes du débogueur pour suivre les LIST_ENTRY champs afin d’examiner la liste des paquets IRP et des threads de travail IRP en attente.

  • Utilisez la commande ! IRP pour examiner l’IRP qui a été bloquée. L’adresse de cette IRP est en 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
  • Utilisez la commande ! devstack avec l’adresse PDO dans Arg2 pour afficher les informations associées au pilote défaillant.
    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"
  • Utilisez la commande ! poaction pour afficher les threads qui gèrent les opérations d’alimentation et les IRP d’alimentation alloués.
    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

  • si vous utilisez un pilote KMDF, utilisez les Extensions de l' infrastructure du pilote Windows ( ! wdfkd) pour recueillir des informations supplémentaires.

    Utilisez ! wdfkd. wdflogdump< le nom > de votre pilote, pour voir si KMDF attend que vous ACK les demandes en attente.

    Utilisez ! wdfkd. wdfdevicequeues< votre WDFDEVICE > pour examiner toutes les demandes en suspens et l’État dans lequel elles se trouvent.

  • Utilisez l’extension ! Stacks pour examiner l’état de chaque thread et Rechercher un thread qui peut conserver la transition de l’état d’alimentation.

  • Pour vous aider à déterminer la cause de l’erreur, posez-vous les questions suivantes :

    • Quelles sont les caractéristiques du pilote PDO (Physical Device Object) (Arg2) ?
    • Pouvez-vous trouver le thread bloqué ? Quand vous examinez le thread à l’aide de la commande ! thread Debugger, qu’est-ce que le thread est constitué ?
    • Existe-t-il des e/s associées au thread qui les bloque ? Quels sont les symboles sur la pile ?
    • Quand vous examinez l’IRP de l’alimentation bloquée, que remarquez-vous ?
    • Quel est le code de fonction secondaire PnP de l’IRP d’alimentation ?

Débogage de la vérification de bogue 0x9F lorsque le paramètre 1 est égal à 0x4

  • Dans un débogueur de noyau, utilisez la commande ! analyze-v pour effectuer l’analyse de la vérification de bogue initiale. L’analyse détaillée affiche l’adresse de l' NT ! TRIAGE_9F_PNP structure, qui est dans le paramètre 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

Le NT ! TRIAGE_9F_PNP structure fournit des informations supplémentaires sur la vérification des bogues qui peuvent vous aider à déterminer la cause de l’erreur. Le NT ! TRIAGE_9F_PNP structure fournit un pointeur vers une structure qui contient la liste des paquets IRP PnP (mais pas terminés) et fournit un pointeur vers la file d’attente de travail système retardée.

  • Utilisez la commande DT (type d’affichage) et spécifiez l’option NT ! TRIAGE_9F_PNP structure et l’adresse que vous avez trouvée dans 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

La commande DT (type d’affichage) affiche la structure. Vous pouvez utiliser les commandes du débogueur pour suivre les LIST_ENTRY champs afin d’examiner la liste des IRP PnP en suspens.

Pour vous aider à déterminer la cause de l’erreur, posez-vous les questions suivantes :

  • Une IRP est-elle associée au thread ?

  • Existe-t-il des e/s dans le CompletionQueue ?

  • Quels sont les symboles sur la pile ?

  • Reportez-vous aux techniques supplémentaires décrites ci-dessus sous le paramètre 0x3.

Remarques

Si vous n’êtes pas équipé pour déboguer ce problème à l’aide des techniques décrites ci-dessus, vous pouvez utiliser des techniques de dépannage de base.

  • Si de nouveaux pilotes de périphériques ou services système ont été ajoutés récemment, essayez de les supprimer ou de les mettre à jour. Essayez de déterminer ce qui a changé dans le système qui a provoqué l’affichage du nouveau code de vérification des bogues.

  • regardez dans Gestionnaire de périphériques pour voir si des appareils sont marqués avec le point d’exclamation ( !). Examinez le journal des événements affiché dans les propriétés du pilote pour tout pilote défaillant. Essayez de mettre à jour le pilote associé.

  • recherchez dans le journal système observateur d’événements des messages d’erreur supplémentaires susceptibles de vous aider à identifier l’appareil ou le pilote à l’origine de l’erreur. pour plus d’informations, consultez Open observateur d’événements. Recherchez dans le journal système des erreurs critiques qui se sont produites dans la même fenêtre temporelle que l’écran bleu.

  • Pour essayer d’isoler la cause, désactivez temporellement Power Save à l’aide du panneau de configuration, options d’alimentation. Certains problèmes de pilotes sont liés aux différents états de mise en veille prolongée du système ainsi qu’à l’interruption et à la reprise de l’alimentation.

  • Si vous avez récemment ajouté du matériel au système, essayez de le supprimer ou de le remplacer. Sinon, contactez le fabricant pour savoir si des correctifs sont disponibles.

  • Vous pouvez essayer d’exécuter les diagnostics matériels fournis par le fabricant du système.

  • Contactez le fabricant pour savoir si une version mise à jour de l’ACPI/BIOS ou d’un autre microprogramme est disponible.

Voir aussi

analyse des vidages sur incident à l’aide des débogueurs Windows (WinDbg)

Analyse d’un fichier de vidage Kernel-Mode avec WinDbg

Référence du Code de vérification de bogue