Corriger DRIVER_POWER_STATE_FAILURE Windows 11

Téléchargez BlueScreenView depuis nirsoft.net — gratuit, pas d’installation, lit les fichiers minidump que Windows crée après chaque crash. Ouvrez-le, cliquez sur votre entrée BSOD la plus récente, regardez la colonne « Caused By Driver » dans le volet inférieur. C’est le fichier .sys exact responsable. Trente secondes, pas de conjecture.

Le Dell XPS 15 d’une cliente faisait un écran bleu chaque fois qu’elle fermait le couvercle. Marchait bien quand elle l’utilisait, mais dès qu’elle le mettait en veille et le rouvrait — DRIVER_POWER_STATE_FAILURE, crash, redémarrage. Elle avait déjà remplacé son pilote GPU et lancé tous les scans qu’elle pouvait trouver. Rien ne marchait parce qu’elle devinait la cause. On a ouvert son minidump dans BlueScreenView et la colonne Caused By Driver disait nvlddmkm.sys — le pilote d’affichage NVIDIA. Spécifiquement la version 572.16 échouait la transition d’alimentation D3-vers-D0 quand le GPU se réveillait de la veille. Rollback vers 566.36 avec DDU en Mode sans échec, les crashes se sont complètement arrêtés. Douze minutes.

Le stop code 0x9F signifie qu’un pilote a envoyé une demande d’état d’alimentation à un périphérique matériel et que le périphérique n’a jamais répondu. Windows attend quelques secondes, abandonne, et crashe parce qu’il ne peut pas laisser du matériel bloqué entre des états d’alimentation. Ça arrive pendant la veille, le réveil, l’hibernation, ou l’arrêt — tout moment où Windows dit à un périphérique de changer son niveau de consommation. Dans environ 65% des cas qu’on diagnostique à distance, c’est le pilote GPU. Les adaptateurs réseau sont en deuxième.

Paramètres d’alimentation

Si vous avez besoin que les crashes s’arrêtent maintenant pendant que vous investiguez, changez le plan d’alimentation. Ouvrez le Panneau de configuration (pas l’app Paramètres moderne), Options d’alimentation, passez sur Hautes performances — vous devrez peut-être cliquer « Afficher les plans supplémentaires. » Le plan Équilibré fait constamment transitionner les périphériques entre états d’alimentation pour économiser l’énergie, et si un pilote a un bug d’état d’alimentation, Équilibré le sollicite toutes les quelques minutes. Hautes performances garde les périphériques éveillés. Ça corrige peut-être 25% des cas directement, bien que ce soit plus un pansement qu’un remède.

Le paramètre qui cause plus de ces crashes qu’aucun bug de pilote individuel : PCI Express Link State Power Management. Dans Options d’alimentation, cliquez « Modifier les paramètres du mode » à côté de votre plan actif, puis « Modifier les paramètres d’alimentation avancés », développez PCI Express, mettez Link State Power Management sur Désactivé. L’ASPM met les périphériques PCIe — GPU, SSD NVMe, parfois WiFi — en états basse consommation entre les opérations. Certains contrôleurs NVMe et GPU ne se réveillent pas proprement des états ASPM L1, surtout sur les cartes AMD avec chipsets B550 et B650. Le périphérique dort, Windows envoie la commande de réveil, le périphérique ne répond pas, le noyau crashe avec 0x9F.

Le Démarrage rapide est l’autre. Il sauvegarde une image d’hibernation partielle à l’arrêt pour que le prochain démarrage charge plus vite, mais il ne réinitialise pas complètement les pilotes au démarrage — il les restaure depuis l’image. Si l’état d’alimentation d’un pilote était corrompu quand l’image a été sauvegardée, le Démarrage rapide recrée cette corruption à chaque boot. Désactivez-le via Panneau de configuration, Options d’alimentation, « Choisir l’action des boutons d’alimentation », « Modifier les paramètres actuellement non disponibles », décochez « Activer le démarrage rapide. »

Corriger le pilote spécifique

Une fois que BlueScreenView vous dit quel fichier .sys crashe, le correctif dépend du matériel.

Pour les pilotes GPU — nvlddmkm.sys sur NVIDIA, atikmpag.sys sur AMD — une réinstallation standard via le Gestionnaire de périphériques ne marche presque jamais parce qu’elle ne nettoie pas les entrées de registre de gestion d’alimentation de l’ancien pilote. Ces mêmes pilotes causent aussi des crashes SYSTEM_SERVICE_EXCEPTION en charge, code d’arrêt différent mais même cause racine. Téléchargez DDU (Display Driver Uninstaller), démarrez en Mode sans échec (Paramètres, Système, Récupération, Redémarrer maintenant, Dépannage, Paramètres de démarrage, appuyez sur 4), lancez DDU, sélectionnez « Clean and restart. » Ça arrache toute trace y compris les clés de registre, caches de shaders, et les profils d’alimentation qui sont presque certainement la source du crash. Après redémarrage, installez un pilote propre depuis nvidia.com. Avant d’installer, cherchez « nvidia [numéro de version] BSOD » pour vérifier si la version actuelle a des problèmes connus — le Studio Driver est parfois le choix plus sûr que Game Ready. Sur NVIDIA, la série 566.x est significativement plus stable pour la veille/réveil que 570.x-572.x sur la plupart des cartes RTX.

AMD utilise leur propre Cleanup Utility au lieu de DDU — téléchargeable depuis amd.com. Supprime tous les composants Radeon y compris Adrenalin et les profils d’alimentation. Leurs cartes RDNA 3 touchent encore occasionnellement des problèmes d’état d’alimentation avec des versions firmware AGESA spécifiques, donc vérifiez une mise à jour BIOS en même temps.

Pour les adaptateurs réseau — e1d65x64.sys c’est Intel Ethernet, rt640x64.sys c’est Realtek — le correctif est différent. Gestionnaire de périphériques, trouvez votre adaptateur sous Cartes réseau, double-cliquez, onglet Gestion de l’alimentation, décochez « Autoriser l’ordinateur à éteindre ce périphérique pour économiser l’énergie. » Onglet Avancé, désactivez Wake on Magic Packet, Wake on Pattern Match, et Energy Efficient Ethernet. L’Intel I225-V 2,5 Gb sur les cartes Z590/Z690/B660 et le Realtek RTL8125B sur les cartes budget B550/B650 sont les deux qu’on voit le plus souvent — les deux ont des bugs firmware connus dans la gestion des transitions d’état d’alimentation.

Si BlueScreenView pointe vers ntoskrnl.exe au lieu d’un pilote spécifique, le crash est à un niveau plus profond qu’un seul pilote. Lancez DISM /Online /Cleanup-Image /RestoreHealth puis sfc /scannow pour corriger les composants système corrompus. Vérifiez aussi une mise à jour BIOS — votre BIOS contient les tables de gestion d’alimentation ACPI qui définissent comment chaque périphérique gère les transitions d’alimentation, et un BIOS obsolète avec des tables buggées cause des pannes d’état d’alimentation même si chaque pilote est parfait. AMD Ryzen 7000 et Intel 12e-14e Gen ont tous deux eu une demi-douzaine de patchs AGESA et microcode en 2025-2026 spécifiquement pour la gestion d’état d’alimentation. Vérifiez la page support du fabricant de votre carte mère, pas Windows Update.

Un dernier truc qui piège les gens — vous corrigez le pilote, tout marche deux semaines, puis Windows Update installe silencieusement une version plus récente du pilote exact que vous avez remplacé et les crashes reviennent. Empêchez ça en allant dans Paramètres, Système, À propos, Paramètres système avancés, onglet Matériel, Paramètres d’installation des périphériques, choisissez « Non. » Notre guide complet de mise à jour des pilotes couvre comment gérer ça en toute sécurité. Pour une analyse d’écran bleu plus approfondie incluant CRITICAL_PROCESS_DIED, DPC_WATCHDOG_VIOLATION, et KERNEL_DATA_INPAGE_ERROR, ou si votre machine se fige sans écran bleu, nous pouvons tirer les fichiers minidump et lancer une analyse WinDbg complète à distance en une vingtaine de minutes.