Lire en anglais

Partager via

0x9F de vérification des bogues : DRIVER_POWER_STATE_FAILURE

  • Article

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

Important

Cet article est destiné aux programmeurs. 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 de 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 d’appareil en cours de libération a toujours une demande d’alimentation en attente qu’il n’a pas terminée.
0x2 Objet d’appareil de l’appareil cible, s’il est disponible Objet device Objet driver, s’il est disponible L’objet d’appareil 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 nt !_TRIAGE_9F_POWER. IRP bloqué Un objet d’appareil bloque un IRP depuis trop longtemps.
0x4 Valeur de délai d’attente, en secondes. Thread qui maintient actuellement le verrou Plug-and-Play (PnP). Nt! TRIAGE_9F_PNP. La transition de l’état d’alimentation a expiré en attente de 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 pu effectuer une transition d’alimentation dirigée dans le délai requis.
0x6 Objet POP_FX_DEVICE Indique s’il s’agissait d’une mise hors tension dirigée(1) ou d’une mise sous tension(0). Réservé - 0 L’appareil n’a pas terminé son rappel de transition d’alimentation dirigée avec succès.
0x500 Réservé Objet d’appareil de l’appareil cible, s’il est disponible Objet d’appareil L’objet d’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 de l’appareil libéré avec demande d’alimentation non supprimée en attente
  • La transition de l’état d’alimentation a expiré
  • Objet d’appareil bloquant un IRP
  • IRP terminé, 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 défaillant sont nécessaires.

Débogage des case activée 0x9F de bogues lorsque le paramètre 1 est égal à 0x3

  • Dans un débogueur de noyau, utilisez la commande !analyze -v pour effectuer l’analyse initiale du bogue case activée. L’analyse détaillée affiche l’adresse du 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 (expression de modèle objet du débogueur d’affichage), une commande de débogueur, pour afficher ceci : dx KiBugCheckDriver.

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

  • Utilisez la commande dt (Type d’affichage) et spécifiez la valeur nt ! TRIAGE_9F_POWER structure à l’aide de l’adresse d’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 de débogueur pour suivre les champs LIST_ENTRY afin d’examiner la liste des irP en suspens et les threads de travail IRP d’alimentation.

  • Utilisez la commande !irp pour examiner l’IRP qui a été bloqué. L’adresse de cet IRP se trouve dans 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 tous 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 d’infrastructure du pilote Windows ( !wdfkd) pour collecter des informations supplémentaires.

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

    Utilisez !wdfkd.wdfdevicequeues<votre WDFDEVICE> pour examiner toutes les demandes en attente et leur état.

  • Utilisez l’extension !stacks pour examiner l’état de chaque thread et rechercher un thread qui peut contenir la transition de l’état d’alimentation.

  • Pour vous aider à déterminer la cause de l’erreur, tenez compte des questions suivantes :

    • Quelles sont les caractéristiques du pilote DOP (Arg2) ?
    • Pouvez-vous trouver le thread bloqué ? Quand vous examinez le thread avec la commande !thread débogueur, en quoi consiste le thread ?
    • Y a-t-il des E/S associées au thread qui le bloque ? Quels sont les symboles sur la pile ?
    • Quand vous examinez l’IRP d’alimentation bloquée, que remarquez-vous ?
    • Qu’est-ce que le code de fonction secondaire PnP de l’IRP d’alimentation ?

Débogage des case activée 0x9F de bogue lorsque le paramètre 1 est égal à 0x4

  • Dans un débogueur de noyau, utilisez la commande !analyze -v pour effectuer l’analyse initiale du bogue case activée. L’analyse détaillée affiche l’adresse du nt ! TRIAGE_9F_PNP structure, qui se trouve 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 de case activée de bogue supplémentaires 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 runtimes d’intégration pnP distribués (mais non 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 la valeur 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 champs LIST_ENTRY afin d’examiner la liste des irp PnP en suspens.

Pour vous aider à déterminer la cause de l’erreur, tenez compte des questions suivantes :

  • Un IRP est-il associé au thread ?

  • Y a-t-il des E/S dans la CompletionQueue ?

  • Quels sont les symboles sur la pile ?

  • Reportez-vous aux techniques supplémentaires décrites ci-dessus sous 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 certaines 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 à l’origine de l’apparition du nouveau code case activée bogue.

  • Regardez dans Gestionnaire de périphériques pour voir si des appareils sont marqués avec le point d’exclamation ( !). Passez en revue 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é.

  • Vérifiez le journal système observateur d'événements pour obtenir des messages d’erreur supplémentaires susceptibles d’aider à identifier le périphérique ou le pilote à l’origine de l’erreur. Pour plus d’informations, consultez Ouvrir 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 l’économie d’énergie à l’aide du panneau de configuration, des 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.

  • Vérifiez auprès du fabricant si un système ACPI/BIOS mis à jour ou un autre microprogramme est disponible.

Voir aussi

Analyse de vidage 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