Je viens de tomber sur un bug Windows assez amusant sur cette machine, je note le processus de diagnostic.
D’abord, la version « en langage humain » du symptôme :
L’ordinateur a d’abord brièvement figé, puis un énorme rectangle noir est apparu au centre de l’écran. Le plus absurde, c’est qu’il masque les autres fenêtres, mais que le Gestionnaire des tâches, lui, n’est justement pas masqué.
La sensation est très étrange, parce que ce n’est ni un plantage complet, ni un écran défectueux ; ça ressemble davantage à une « fenêtre fantôme » apparue de nulle part sur l’écran.
Au début, mon intuition partait dans plusieurs directions :
- La dalle de l’écran est morte
- Chrome ou une fenêtre de navigateur a explosé au niveau du rendu
- Le pilote graphique vient de se réinitialiser
- Un programme résident de fenêtre flottante/overlay a planté, mais les « débris » de la fenêtre sont restés sur le bureau
Ensuite j’ai éliminé point par point, et ça a fini par faire ressortir la réponse.
D’abord confirmer que ce n’est pas l’écran qui est HS
Le détail clé : ce bloc noir apparaît dans une capture d’écran.
C’est très important, parce que s’il s’agissait d’un défaut de dalle (pixel mort, fuite de liquide, choc), en général il n’apparaîtrait pas dans la capture.
S’il est visible dans la capture, ça veut dire que c’est quelque chose dans la pile graphique de Windows, une « fenêtre au niveau logiciel », pas un problème physique de l’écran.
Puis aller fouiller les journaux système
J’ai regardé les logs autour de 2026-04-06 01:27, la timeline est assez intéressante :
01:27:12:alttab_windows.exese bloque01:27:19:DWM(Desktop Window Manager / gestionnaire de fenêtres du bureau) se ferme puis redémarre01:27:20:CPALauncher.exeplante- Ensuite on voit une série de
LiveKernelEvent 117 / 141 / 1a8 / 1b8 - Et il y a aussi
WindowsBlackScreenDiagnosticsV1
La ligne la plus utile ici n’est pas « qui a planté », mais le fait que dans l’exception .NET de CPALauncher, il est écrit noir sur blanc :
La composition du bureau est désactivée,
DwmExtendFrameIntoClientArean’a pas pu se terminer
Le sens est très direct :
ce n’est pas CPALauncher qui a d’abord fait planter le système ; c’est la composition du bureau / DWM qui a d’abord décroché un instant. Il se trouve juste qu’au même moment, il accédait à l’API DWM, et a donc explosé à son tour.
Du coup, la direction générale est déjà très claire :
Ce qui se produit en premier, c’est une anomalie de la chaîne d’affichage/graphique ; ensuite seulement, diverses applis enchaînent des erreurs en cascade.
Pourquoi j’ai ensuite soupçonné non pas une appli unique, mais toute la chaîne graphique
Parce que le « bruit » derrière est très cohérent :
- Dans les logs Sentry de
Typeless, on voit en bouclescreen.display-removed / added / metrics-changed PixPin.exea ensuite planté deux fois surd3d11.dllNVIDIA Overlayreconstruisait aussi son processus d’overlay à répétition sur cette période
Mis ensemble, ça ressemble moins à « une appli débile » qu’à :
le système pense que le périphérique d’affichage a été retiré puis réajouté, ou bien le pilote graphique / la chaîne de composition est en train de se rétablir.
Dès que la chaîne graphique de Windows tremble un peu, les programmes qui bidouillent le bureau sont les premiers à partir en vrille :
- fenêtres flottantes
- overlays
- outils de capture
- amélioration du changement de fenêtres
- fenêtres transparentes
- raccourcis globaux
- petits outils Electron
Et sur cette machine, justement, ce genre de choses, j’en ai pas mal.
Le moment où j’ai vraiment identifié l’origine du bloc noir
Ensuite j’ai arrêté de deviner : j’ai directement énuméré les fenêtres de premier niveau au-dessus de la zone centrale où se trouvait ce bloc.
Le résultat était impeccable :
- Processus :
Typeless - Titre de la fenêtre :
Status - Coordonnées et taille : ça correspondait quasiment parfaitement au bloc noir
Autrement dit, ce truc noir n’était ni le navigateur, ni le bureau, ni l’OSD de la carte graphique, mais une fenêtre flottante de statut de Typeless.
Puis je suis allé fouiller les ressources locales de Typeless, et on peut même y voir directement :
floating_bar__window__title = "Status"
Là, c’était pratiquement acté :
Ce bloc noir est, au fond, la fenêtre flottante de statut de Typeless ; mais après l’anomalie de la chaîne graphique, elle n’a pas été correctement redessinée/fermée, et s’est transformée en une fenêtre fantôme de premier plan, entièrement noire.
Pourquoi le détail « le Gestionnaire des tâches n’est pas masqué » est si utile
Ce phénomène ressemble énormément à une overlay de très haut niveau.
Si une fenêtre d’appli normale devient noire, le Gestionnaire des tâches sera masqué lui aussi.
Mais s’il s’agit d’une fenêtre flottante spéciale, d’une fenêtre toujours-au-dessus, d’une fenêtre outil, d’une fenêtre en couches (layered window), le Gestionnaire des tâches peut parfois la dépasser grâce à sa propre priorité d’affichage.
Donc le détail « toutes les autres fenêtres sont masquées, sauf le Gestionnaire des tâches » te souffle en réalité :
va chercher du côté des overlays de premier niveau, ne fixe pas uniquement les onglets du navigateur.
La façon de régler le problème est en fait très simple
Aucune réparation mystique.
Au final, l’action qui a vraiment fait disparaître le bloc noir, il n’y en a eu qu’une :
tuer directement le processus Typeless.
À la fermeture, le bloc noir a disparu immédiatement.
Ça montre aussi que ce n’était pas un état « système cassé, il faut redémarrer pour récupérer », mais une entité de fenêtre encore vivante, dont le contenu était simplement corrompu.
Ma compréhension actuelle de la « cause racine » et de la « cause immédiate »
Je le découpe en deux niveaux :
Cause immédiate
La fenêtre flottante Status de Typeless n’a pas réussi à se rétablir après l’anomalie de la chaîne d’affichage, laissant une fenêtre noire de premier plan.
Cause racine plus profonde
La pile graphique de Windows a eu un problème à ce moment-là, du type :
- DWM interrompu / reconstruit
- déclenchement d’un événement du watchdog GPU
- instabilité instantanée du pilote graphique ou de la topologie d’affichage
Donc Typeless n’est pas l’unique source du problème : c’est plutôt l’une des victimes les plus visibles de cet incident.
Avec le recul, qu’est-ce qui est le plus suspect
Par ordre de priorité, selon moi :
- Pilote graphique / instabilité instantanée de la pile graphique
- Trop de programmes résidents d’amélioration de fenêtres / overlays empilés
- Typeless lui-même pas assez robuste face aux changements de topologie d’affichage
Les « programmes à haut risque » présents à ce moment-là incluaient :
TypelessPixPinalttab_windowsNVIDIA Overlay- et
CPALauncherque j’ai déjà supprimé
Pris séparément, ils ne posent pas forcément problème ; empilés, ça ressemble fortement à un test de charge pour DWM et D3D11.
Si je retombe sur un bug similaire, comment je le traiterai plus vite
Mon ordre de diagnostic va devenir :
- D’abord voir si le bloc noir apparaît dans une capture d’écran
- Si oui, conclure immédiatement que c’est une fenêtre logicielle, pas un écran abîmé
- Ouvrir d’abord le Gestionnaire des tâches, chercher les processus de fenêtre flottante/overlay/capture/amélioration de fenêtres
- Énumérer ou identifier à l’œil à quelle fenêtre appartient le bloc
- Tuer d’abord le processus, puis seulement ensuite regarder les journaux système
- Et enfin décider s’il faut traiter le problème de pilote graphique en profondeur
Conclusion provisoire
Cette fois, ce n’était ni « l’écran est mort », ni un simple « écran noir de Chrome ».
Plus exactement :
une anomalie au niveau de la chaîne graphique/DWM a fait tomber en cascade un tas de programmes dépendants de la composition du bureau ; et la fenêtre flottante Status de Typeless a eu la malchance de rester au centre de l’écran sous la forme d’une énorme fenêtre fantôme noire.
Ce genre de problème est vraiment très Windows, et assez amusant :
ce n’est pas un bug qu’on comprend d’un coup d’œil ; il faut d’abord accepter le fait que « le bloc noir est aussi un objet fenêtre », et ensuite tout s’enchaîne soudainement.
Si ensuite j’arrive à réduire un peu la version du pilote, les conditions de reproduction, ou la fonction exacte de Typeless qui déclenche cet état, je ferai un post de suivi.