0x9F de vérification des bogues : DRIVER_POWER_STATE_FAILURE
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)
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour