Bug Check 0x9F : DRIVER_POWER_STATE_FAILURE

La DRIVER_POWER_STATE_FAILURE vérification de bogue a la valeur 0x0000009F. Cette vérification de bogue 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.

DRIVER_POWER_STATE_FAILURE Paramètres

Le paramètre 1 indique le type de violation.

Paramètre 1	Paramètre 2	Paramètre 3	Paramètre 4	La cause
0x1	L’objet appareil	Réservé	Réservé	L’objet appareil en cours de libération a toujours une demande d’alimentation en attente qu’il n’a pas traitée.
0x2	L’objet appareil de l’appareil cible, s’il est disponible	L’objet appareil	L’objet driver, s’il est disponible	L’objet device a complété 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	L’objet de dispositif physique (PDO) de la pile	`nt!_TRIAGE_9F_POWER`.	L’IRP bloqué	Un objet de périphérique bloque un IRP depuis trop longtemps.
0x4	Valeur du délai d’expiration, en secondes.	Le thread qui maintient actuellement le verrou Plug-and-Play (PnP).	`nt!_TRIAGE_9F_PNP`.	La transition d’état d’alimentation a expiré en attendant la synchronisation avec le sous-système PnP.
0x5	Objet de périphérique physique de la pile	L’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 requis.
0x6	L’objet POP_FX_DEVICE	Indique s’il s’agit d’une mise hors tension dirigée(1) ou d’une mise sous tension(0).	Réservé - 0	L’appareil n’a pas réussi à effectuer son rappel de transition d’alimentation dirigée.
0x500	Réservé	Objet appareil de l’appareil cible, le cas échéant	Objet Device	L’objet appareil a terminé l’IRP pour la demande d’état d’alimentation du système, mais il n’a pas appelé PoStartNextPowerIrp.

La cause

Pour 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 incomplète en attente
Délai de transition de l’état de l’alimentation expiré
Objet d’appareil bloquant un IRP
Terminé l’IRP mais n’a pas appelé PoStartNextPowerIrp

Résolution

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

Vérification des bogues de débogage 0x9F lorsque le paramètre 1 est égal à 0x3

Dans un débogueur de noyau, utilisez la commande !analyze -v pour effectuer l’analyse initiale de vérification des bogues. L’analyse verbeuse affiche l’adresse du nt ! TRIAGE_9F_POWER structure, qui est en 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 (display debugger object model expression), une commande de débogueur, pour afficher ceci : 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 des bogues. La structure peut fournir une liste de tous les IRP d’alimentation en attente, une liste de tous les threads de travail IRP d’alimentation et un pointeur vers la file d’attente de travail système retardé.

Utilisez la commande dt (Display Type) et spécifiez le 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 (Display Type) affiche la structure. Vous pouvez utiliser diverses commandes du débogueur pour suivre les champs LIST_ENTRY afin d’examiner la liste des IRP en attente 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 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éfectueux.

    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 Windows Driver Framework ( !wdfkd) pour recueillir des informations supplémentaires.

Utilisez !wdfkd.wdflogdump<le nom> de votre pilote, pour voir si KMDF attend que vous accusiez réception des demandes en attente.

Utilisez !wdfkd.wdfdevicemet en file d’attente<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 susceptible de retarder la transition d’é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 fil bloqué ? Lorsque vous examinez le thread à l’aide de la commande !thread debugger, en quoi consiste le thread ?
- Y a-t-il des E/S associées au thread qui le bloque ? Quels symboles se trouvent sur la pile ?
- Lorsque vous examinez l’IRP de puissance bloquée, que remarquez-vous ?
- Qu’est-ce que le code de fonction mineure PnP de l’IRP de puissance ?

La vérification des bogues de débogage 0x9F lorsque le paramètre 1 est égal à 0x4

Dans un débogueur de noyau, utilisez la commande !analyze -v pour effectuer l’analyse initiale de vérification des bogues. L’analyse verbeuse 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 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 IRP 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 (Display Type) et spécifiez la structure et l’adresse nt!_TRIAGE_9F_PNP que vous avez trouvées 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 (Display Type) 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 attente.

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

Y a-t-il un IRP associé au fil de discussion ?
Y a-t-il des E/S dans la file d’attente d’achèvement ?
Quels symboles se trouvent 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 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 qui a provoqué l’affichage du nouveau code de vérification des bogues.
Regardez dans le Gestionnaire de périphériques pour voir si des périphériques sont marqués d’un point d’exclamation ( !). Examinez le journal des événements affiché dans les propriétés du pilote pour tout pilote défectueux. Essayez de mettre à jour le pilote associé.
Consultez le journal système dans l’Observateur d’événements pour obtenir des messages d’erreur supplémentaires qui peuvent aider à identifier le périphérique ou le pilote à l’origine de l’erreur. 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 temporairement l’économie d’énergie à 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.
Vérifiez auprès du fabricant si un système ACPI/BIOS mis à jour ou un autre micrologiciel est disponible.

Voir aussi

Analyse du 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

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-05-10