MENU
  1. Accueil
  2. Windows
  3. troubleshooting
  4. BSOD 0x0000000A, Secure Boot et dxgmms2.sys : réparer la boucle d’écrans noirs (RX 580/Ryzen 5 3600)

BSOD 0x0000000A, Secure Boot et dxgmms2.sys : réparer la boucle d’écrans noirs (RX 580/Ryzen 5 3600)

troubleshooting

Écrans noirs ou BSOD 0x0000000A dès qu’un jeu démarre ? Voici une méthode éprouvée pour stabiliser un PC CyberPowerPC (Ryzen 5 3600 / Radeon RX 580 / 16 Go) où les journaux citent « Secure Boot update failed », dxgmms2.sys et parfois ntoskrnl.exe.

Sommaire

Vue d’ensemble du problème

Plusieurs utilisateurs d’un PC CyberPower PC (Ryzen 5 3600, Radeon RX 580, 16 Go RAM) observent :

  • des redémarrages inopinés avec écran noir ou BSOD (code 0x0000000A — IRQL_NOT_LESS_OR_EQUAL) ;
  • des entrées dans l’Event Viewer mentionnant :
    • « Secure Boot update failed – Secure Boot is not enabled on this machine » ;
    • un crash du module dxgmms2.sys (pilote graphique DirectX) ;
    • et parfois un bugcheck ntoskrnl.exe.
  • le symptôme réapparaît après une réinitialisation d’usine ou au lancement de jeux, avec des températures qui restent pourtant correctes.

Pourquoi cela arrive-t-il ? (mécanisme technique)

dxgmms2.sys est le gestionnaire mémoire du sous‑système graphique DirectX. Il orchestre la file d’attente GPU, la pagination et la reprise après timeout (TDR). Quand un pilote vidéo (amdkmdag.sys côté AMD) se bloque, répond trop tard ou renvoie des données corrompues, Windows peut :

  • tenter une réinitialisation du périphérique graphique ;
  • ou déclencher un BSOD 0x0000000A si l’accès mémoire survient à un niveau d’IRQL inapproprié.

En parallèle, l’évènement « Secure Boot update failed… » signifie seulement que Windows a voulu écrire une variable UEFI liée à Secure Boot mais que le firmware, configuré sans Secure Boot actif, a refusé l’opération. Ce n’est pas la cause directe des écrans noirs, mais un bruit de fond révélateur d’une configuration UEFI perfectible.

Dans ce scénario (RX 580 + jeux), la cause première est quasi toujours un pilote GPU instable ou une marge électrique trop serrée (carte graphique vieillissante, alimentation faiblissante, paramètres d’overclock/undervolt agressifs, utilitaires OEM intrusifs). D’où la logique d’action : pilote → UEFI → charge GPU → matériel.

Réponse & solutions proposées

ObjectifÉtapes détailléesNotes importantes
1. Stabiliser le pilote graphique1. Démarrer en Mode sans échec.
2. Supprimer complètement les pilotes AMD via Display Driver Uninstaller (DDU).
3. Redémarrer, puis installer la dernière version stable (ou une version un peu plus ancienne réputée stable) depuis le site AMD/Gigabyte.		Le fichier dxgmms2.sys défectueux indique souvent un pilote corrompu. Cette opération règle la majorité des BSOD liés au GPU.
2. Vérifier/activer Secure Boot (facultatif mais conseillé)1. Mettre à jour le BIOS/UEFI vers la version la plus récente.
2. Dans l’UEFI : passer en mode UEFI only, initialiser les clés de plateforme (PK/KEK/DB) si demandé, puis activer Secure Boot.
3. Sauvegarder et redémarrer.		L’erreur « Secure Boot variable » n’est pas fatale ; elle signale seulement que Windows n’a pas pu écrire une variable UEFI. Activer correctement Secure Boot supprime ces entrées de journal mais ne répare pas, à lui seul, un pilote défectueux.
3. Réduire la charge GPU– Dans Radeon Software ou MSI Afterburner : sous‑volter légèrement le GPU (≈ −30 mV) et/ou baisser la fréquence de 50–100 MHz.
– Tester la stabilité avec un benchmark léger (Heaven, 3DMark Time Spy).		Plusieurs rapports montrent un retour à la stabilité après un léger underclock/undervolt de la RX 580.
4. Écarter les causes matérielles– Désinstaller/neutraliser les utilitaires OEM lourds (Armoury Crate, RGB Fusion, etc.).
– Vérifier l’alimentation (tests OCCT Power).
– Tester la RAM (Windows Memory Diagnostic ou MemTest86).
– Observer si le bouton Reset reste inopérant lors d’un écran noir : si oui, suspecter la carte‑mère.		Une carte‑mère instable peut bloquer totalement le système (absence de réponse au bouton Reset) avant même que Windows n’écrive un minidump.

Procédure complète conseillée

  1. Sauvegardez vos données avant toute manipulation.
  2. Mettez à jour le BIOS, chargez les Optimized Defaults puis, si vous le souhaitez, activez Secure Boot.
  3. Nettoyez et réinstallez le pilote GPU avec DDU.
  4. Testez ; si les plantages persistent, appliquez un undervolt léger.
  5. Si le problème continue : testez la RAM et l’alimentation, puis inspectez la carte‑mère (condensateurs, Dual BIOS).

Check‑list express (10 minutes)

  • Windows crée‑t‑il des minidumps ? (Paramètres système avancés → Démarrage et récupération → « Écriture des informations de débogage : Décharge mémoire automatique », et veillez à ne pas avoir désactivé le fichier d’échange.)
  • Dans l’Observateur d’évènements : cherchez Display (ID 4101), BugCheck, Kernel‑Power 41, messages Secure Boot, et les références à dxgmms2.sys.
  • Fermez et désactivez toutes les surcouches (Discord overlay, Steam, Radeon Overlay, OSD Afterburner, GeForce Experience si présent, enregistreurs/streamers).
  • Mettez votre RAM non‑XMP (profil JEDEC) pour tester sans overclock mémoire.
  • Débranchez/rebranchez deux câbles PCIe séparés vers la RX 580, si votre alimentation le permet.

Étapes détaillées et bonnes pratiques

1) Remise à zéro propre du pilote AMD (méthode DDU)

  1. Déconnectez Internet (pour empêcher Windows Update de réinstaller un pilote générique pendant l’opération).
  2. Dans Paramètres > Système > Récupération, redémarrez en mode sans échec.
  3. Lancez DDU et cochez l’option empêchant Windows Update de télécharger les pilotes d’affichage.
  4. Sélectionnez GPU > AMD et cliquez sur Nettoyer et redémarrer.
  5. De retour sur Windows, installez la version stable d’Adrenalin (évitez les « Optional » si vous recherchez la stabilité) ou, si nécessaire, une version un cran plus ancienne reconnue pour sa stabilité sur RX 580.
  6. Activez uniquement les fonctions nécessaires ; désactivez Enhanced Sync, Instant Replay/Record & Stream dans Radeon pour les premiers tests.

Astuce : pendant 48 h, suspendez Windows Update (pause des mises à jour) afin d’éviter qu’un pilote ne soit remplacé en arrière‑plan.

2) BIOS/UEFI propre + Secure Boot (optionnel mais sain)

  1. Flashez le BIOS de la carte‑mère vers la révision la plus récente proposée par le constructeur.
  2. Au premier démarrage, chargez les Optimized Defaults puis UEFI Only pour le boot (désactivez CSM pour un Secure Boot fonctionnel), conservez SATA en AHCI.
  3. Dans le menu Secure Boot : Install/Initialize Factory Keys (PK/KEK/DB), puis passez Secure Boot sur Enabled.
  4. Si vous avez activé un profil XMP/DOCP, laissez‑le temporairement désactivé le temps de valider la stabilité.

Important : l’évènement « Secure Boot update failed – Secure Boot is not enabled on this machine » disparaîtra si le firmware autorise désormais les écritures de variables Secure Boot. Mais ce réglage ne règle pas à lui seul un pilote qui plante.

3) Réduire la charge et augmenter les marges

  • Dans Radeon Software > Performance > Tuning, passez en mode manuel et baissez la tension GPU d’environ −30 mV et/ou la fréquence max de 50–100 MHz. Sur bien des RX 580, viser 1300–1350 MHz stabilise un silicium fatigué.
  • Activez Radeon Chill ou un limiteur de FPS (FRTC, V‑Sync) pour rester sous le plafond de consommation.
  • Faites un test de 10 min avec Unigine Heaven ou Time Spy ; si stable, augmentez la durée et essayez votre jeu critique.

4) Écarter les causes matérielles

  • Alimentation (PSU) : la RX 580 peut tirer ~185 W en pic. Avec un Ryzen 5 3600 et le reste, visez une PSU de 500–550 W minimum, en bon état, câblée avec deux connecteurs PCIe séparés. Surveillez dans HWInfo64 les 12 V sous charge (variations < 3 %).
  • RAM : faites un Windows Memory Diagnostic puis, si nécessaire, MemTest86 plusieurs passes. Testez également en JEDEC (sans XMP/DOCP).
  • Carte‑mère : si, lors d’un écran noir, le bouton Reset ne répond plus, suspectez un lock matériel (VRM, chipset). Vérifiez l’absence de condensateurs bombés, mettez à jour le BIOS et testez avec le minimum vital (1 barrette RAM, GPU, SSD, pas d’USB superflu).
  • GPU : certaines RX 580 ont un switch dual‑BIOS. Testez l’autre position si disponible. Évitez tout VBIOS « mining » non officiel.

Journalisation, diagnostics et commandes utiles

Où regarder dans l’Observateur d’évènements

  • Journaux Windows > Système : BugCheck, Kernel‑Power 41, WHEA‑Logger.
  • Journaux Windows > Application : erreurs d’applications 1000 liées aux jeux.
  • Applications et services > Microsoft > Windows :
    • Display‑Driver (événements 4101 « le pilote d’affichage ne répondait plus… »),
    • CodeIntegrity & Secure‑Boot‑Platform pour les entrées Secure Boot.

Activer/minimiser les minidumps

  1. Ouvrez sysdm.cpl → Avancé → Démarrage et récupération → Écriture des informations de débogage : Décharge mémoire automatique.
  2. Assurez‑vous que le fichier d’échange (pagefile) n’est pas désactivé.
  3. Les minidumps se trouvent dans C:\Windows\Minidump. Analyse rapide : WhoCrashed ou BlueScreenView.

Réparer l’image et les fichiers système

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Relancez sfc après DISM si des fichiers ont été réparés.

Vérifications complémentaires (Windows)

  • Alimentation > Options d’alimentation : testez le plan Équilibré puis Performances élevées.
  • Désactivez le Démarrage rapide (Windows) et Fast Boot (UEFI) pendant les tests.
  • Dans l’UEFI, forcez PCIe Gen3 sur le slot x16 si réglé sur Auto.

Arbre de décision rapide

SymptômePiste prioritaireAction concrète
BSOD 0x0000000A citant dxgmms2.sysPilote GPUDDU en mode sans échec → installer version stable Adrenalin
Aucun minidump, écran noir dur, Reset inopérantCarte‑mère / PSUTest alimentation, inspection CM, boot minimal
« Secure Boot update failed… » dans les logsUEFI non configuréPasser en UEFI only, initialiser PK/KEK/DB, activer Secure Boot
Crash uniquement en jeu, températures OKMarge GPUUndervolt −30 mV et −100 MHz, limiter FPS
Freeze + son en boucleDPC/TDRDésactiver overlays, tester TDRDelay (avancé)

Option avancée : TDRDelay (à n’utiliser qu’en dernier recours)

La stratégie TDR (Timeout Detection and Recovery) évite les écrans noirs prolongés en réinitialisant le GPU s’il ne répond pas à temps. Allonger le délai peut masquer un problème mais ne le corrige pas. À réserver aux cas où l’undervolt/driver propre améliore mais n’élimine pas 100 % des crashs.

  1. Ouvrez regedit.
  2. Allez dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers.
  3. Créez une valeur DWORD TdrDelay à 8 (valeur par défaut 2).
  4. Redémarrez et testez. Si rien ne change, supprimez la clé au lieu d’empiler les « patchs ».

Attention : si l’instabilité est matérielle (PSU/CM/GPU), ajuster TDRDelay ne fera que retarder l’inévitable.

Cas particuliers et pièges fréquents

  • Windows Update réinstalle un pilote pendant vos tests : déconnectez le réseau ou mettez en pause les mises à jour. Dans DDU, activez l’option « Empêcher Windows de télécharger les pilotes ».
  • Overlays (Discord, Steam, Radeon, RivaTuner) : sources classiques de conflits D3D11/D3D12. Désactivez‑les entièrement pour valider la base.
  • Câbles vidéo : un HDMI/DP défectueux peut provoquer des écrans noirs intermittents. Testez un autre câble/port (DP ↔ HDMI) et un seul écran au début.
  • Profil RAM XMP/DOCP trop agressif : repassez en Auto/JEDEC. Une seule barrette à la fois permet d’isoler une barrette instable.
  • RX 580 avec VBIOS non standard : si la carte a servi au minage, rétablissez un VBIOS d’origine (ne flashez pas tant que la plateforme n’est pas stable).

Exemple de plan de test progressif (1 à 2 heures)

  1. 10 min : DDU → pilote propre → Heaven en boucle. Observe‑t‑on encore des erreurs Display 4101 ?
  2. 20 min : Undervolt −30 mV / −100 MHz → Heaven + jeu cible (scène exigeante) avec FPS limités.
  3. 20 min : OCCT Power test (surveillance 12 V, températures CPU/GPU, VRM).
  4. 30 min : MemTest (rapide) ou Windows Memory Diagnostic, puis test avec une autre barrette si doute.
  5. Répétition : si stable, réactivez une fonctionnalité à la fois (XMP, overlay, enregistreur). Dès qu’un retour du bug survient, vous avez l’élément déclencheur.

FAQ éclair

« Le message Secure Boot dans l’Event Viewer cause‑t‑il mes BSOD ? »

Non. Il révèle une configuration où Windows tente d’écrire une variable UEFI alors que Secure Boot n’est pas actif. Utile à corriger, mais ce n’est pas le déclencheur de dxgmms2.sys.

« Faut‑il formater Windows ? »

Inutile dans l’immense majorité des cas. Un DDU + pilote stable suffit. Formater ne règle pas une alimentation chancelante ou un overclock trop serré.

« L’undervolt n’est‑il pas dangereux ? »

Un léger undervolt (−30 mV) diminue la consommation et la chauffe ; si la marge est trop courte, vous verrez un crash immédiat et pourrez revenir au réglage précédent. C’est bien moins risqué qu’un overclock.

« Je n’ai pas de minidump, comment diagnostiquer ? »

Quand tout se fige au niveau matériel, Windows n’a pas le temps d’écrire un dump. Focalisez‑vous alors sur PSU/CM, câblage PCIe, reset inopérant, et test minimal sans périphériques.

Synthèse des informations techniques utiles

  • dxgmms2.sys : pilote du sous‑système graphique DirectX. Les crashs sont quasi toujours liés à un pilote vidéo ou un GPU instable.
  • 0x0000000A (IRQL_NOT_LESS_OR_EQUAL) : interruption provoquée par un pilote/composant touchant la mémoire système à un niveau de priorité incorrect.
  • Outils pratiques :
    • WhoCrashed ou BlueScreenView pour lire rapidement les minidumps.
    • sfc /scannow et DISM /Online /Cleanup-Image /RestoreHealth pour réparer les fichiers système.
    • Courbes de température et tensions dans HWInfo64 pour déceler un défaut PSU ou VRM.

Modèle de rapport (utile si vous demandez de l’aide)

Copiez/complétez ce bloc après vos tests :

Matériel : Ryzen 5 3600 / RX 580 8 Go / 16 Go DDR4 3200 / Alim XXX W (modèle)
OS : Windows 10/11 22H2 – Secure Boot [activé/désactivé], CSM [off/on]
Pilote AMD : Adrenalin [version] (WHQL) – install propre via DDU [oui/non]
Symptômes : BSOD 0x0000000A / écran noir / freeze audio
Jeux affectés : [liste]
Logs : Event 4101 Display [oui/non], Kernel-Power 41 [oui/non], BugCheck [oui/non]
Minidumps : [oui/non] (chemin C:\Windows\Minidump\[date].dmp)
Tests : Heaven [durée], Time Spy [score], OCCT Power [durée], MemTest [passes]
Actions tentées : undervolt −30 mV / −100 MHz [oui/non], désactivation overlays [oui/non]
Résultat : [stable/instable], déclencheur identifié : [élément]

Conclusion

La combinaison DDU → pilote stable → UEFI propre (UEFI only + Secure Boot) → léger undervolt/limiteur de FPS suffit à éliminer la boucle d’écrans noirs/BSOD dans la majorité des configurations RX 580/Ryzen 5 3600. Si l’instabilité persiste, un diagnostic matériel s’impose : vérifiez l’alimentation, testez la RAM, examinez la carte‑mère et, si possible, essayez un autre GPU/PSU. En procédant par étapes et en collectant des preuves (minidumps, évènements, graphiques de tension/températures), vous réduisez drastiquement le temps de résolution et évitez les réinstallations inutiles.

Récapitulatif d’action conseillé (ordre logique)

  1. Sauvegarde de vos données.
  2. Mise à jour BIOS, Optimized Defaults, UEFI only, Secure Boot (optionnel mais propre).
  3. DDU en mode sans échec → installation Adrenalin stable (WHQL).
  4. Tests courts en jeu/bench → si besoin, undervolt −30 mV et −50 à −100 MHz.
  5. Si toujours instable : RAM/PSU/CM, câbles PCIe distincts, désactivation des overlays, vérification minidumps/logs.
troubleshooting
Secure Boot Windows 11 Windows 10 DDU BSOD 0x0000000A dxgmms2.sys Radeon RX 580 Ryzen 5 3600
Sommaire