Vorhin hatte dieser Rechner einen ziemlich amüsanten Windows-Fehler – ich halte den Troubleshooting-Prozess mal fest.
Erst mal die „in normalen Worten“-Version des Phänomens:
Der PC hat kurz geruckelt, danach erschien in der Bildschirmmitte ein riesiges schwarzes Rechteck. Am absurdesten: Es überdeckt andere Fenster, aber ausgerechnet den Task-Manager überdeckt es nicht.
Das fühlt sich ziemlich unheimlich an, weil es weder wie ein Freeze aussieht noch wie ein kaputter Monitor – eher so, als wäre aus dem Nichts ein „Geisterfenster“ auf dem Bildschirm aufgetaucht.
Mein erster Instinkt ging tatsächlich in mehrere Richtungen:
- Monitorpanel kaputt
- Chrome oder ein Browserfenster hat ein Rendering-Problem
- Der GPU-Treiber hat sich gerade zurückgesetzt
- Ein dauerhaft laufendes Floating-/Overlay-Programm ist abgestürzt, aber die Fensterleiche hängt noch auf dem Desktop
Später habe ich das Punkt für Punkt abgeklopft und die Antwort im Grunde herausdestilliert.
Erst bestätigen, dass es kein Monitordefekt ist
Das entscheidende kleine Detail war: Dieser schwarze Block lässt sich mit in einen Screenshot aufnehmen.
Das ist wichtig, denn wenn es ein Paneldefekt ist (tote Pixel, Flüssigkristall-Leck, Druckschaden), taucht das in Screenshots normalerweise nicht auf.
Wenn man es im Screenshot sieht, heißt das: Es ist etwas im Windows-Grafik-Stack – ein „Fenster auf Software-Ebene“, kein physischer Displayschaden.
Dann in die Systemlogs schauen
Ich habe die Logs rund um 2026-04-06 01:27 geprüft; die Timeline war ziemlich interessant:
01:27:12:alttab_windows.exehängt01:27:19:DWM(Desktop Window Manager) beendet sich und startet neu01:27:20:CPALauncher.exestürzt ab- Danach sieht man noch eine Reihe
LiveKernelEvent 117 / 141 / 1a8 / 1b8 - Außerdem taucht
WindowsBlackScreenDiagnosticsV1auf
Der wertvollste Hinweis ist hier nicht, wer abgestürzt ist, sondern dass in der .NET-Ausnahme von CPALauncher direkt steht:
Desktopkomposition wurde deaktiviert,
DwmExtendFrameIntoClientAreakann nicht abgeschlossen werden
Die Bedeutung ist sehr direkt:
Nicht CPALauncher hat zuerst das System „kaputtgemacht“, sondern Desktopkomposition/DWM ist zu dem Zeitpunkt erst mal kurz weggebrochen. Es hat nur zufällig genau in diesem Moment auf eine DWM-Schnittstelle zugegriffen und ist deshalb mit explodiert.
Damit ist die grobe Richtung schon klar:
Zuerst gab es eine Anzeige-/Grafik-Ketten-Anomalie, danach kamen diverse Anwendungen mit Kettenfehlern hinterher.
Warum ich später eher die gesamte Grafik-Kette verdächtigte statt nur eine einzelne App
Weil das spätere „Rauschen“ auffällig sauber war:
- In den Sentry-Logs von
Typelesstaucht wiederholtscreen.display-removed / added / metrics-changedauf PixPin.exeist später zweimal ind3d11.dllabgestürztNVIDIA Overlayhat in diesem Zeitraum ebenfalls wiederholt den Overlay-Prozess neu aufgebaut
Wenn man diese Phänomene zusammenlegt, wirkt es weniger wie „eine App ist einfach doof“, sondern eher so:
Das System glaubt, das Display-Gerät wurde entfernt und wieder hinzugefügt, oder der Grafiktreiber/Kompositionspfad führt gerade eine Recovery durch.
Sobald der Windows-Grafikpfad einmal zuckt, sind die Programme, die am liebsten am Desktop herumfummeln, als Erstes betroffen:
- Floating-Fenster
- Overlays
- Screenshot-Tools
- Fensterwechsel-Erweiterungen
- transparente Fenster
- globale Hotkeys
- Electron-Minitools
Und auf dieser Kiste habe ich davon zufällig wirklich nicht wenige.
Der Moment, in dem ich den schwarzen Block wirklich lokalisiert habe
Danach habe ich nicht weiter geraten, sondern direkt die Top-Level-Fenster oberhalb dieser Region in der Bildschirmmitte enumeriert.
Der Treffer war schön eindeutig:
- Prozess:
Typeless - Fenstertitel:
Status - Koordinaten und Größe passen praktisch komplett zum schwarzen Block
Heißt: Dieses schwarze Ding ist nicht der Browser, nicht der Desktop, nicht das GPU-OSD selbst, sondern ein Status-Floating-Window von Typeless.
Dann habe ich in den lokalen Ressourcen von Typeless nachgeschaut, und dort konnte man sogar direkt sehen:
floating_bar__window__title = "Status"
Damit ist es im Grunde bestätigt:
Der schwarze Block ist im Kern das Status-Floating-Window von Typeless, das nach einer Anomalie in der Grafik-Kette nicht korrekt neu gezeichnet/geschlossen wurde und deshalb zu einem rein schwarzen Top-Level-Geisterfenster geworden ist.
Warum das Detail „Task-Manager wird nicht überdeckt“ so nützlich ist
Dieses Verhalten sieht stark nach einem Overlay mit hoher Ebene aus.
Wenn ein normales Anwendungsfenster schwarz wird, wird der Task-Manager genauso überdeckt.
Wenn es aber ein spezielles Top-Level-Floating-/Always-on-Top-/Tool-/Layered-Window ist, kann der Task-Manager es manchmal über seine eigene Anzeigepriorität überstimmen.
Das Detail „andere Fenster werden überdeckt, Task-Manager nicht“ ist also im Grunde ein Hinweis:
Suche nach Top-Level-Overlay-Fenstern, nicht nur nach Browser-Tabs.
Die finale Lösung war ziemlich unspektakulär
Keine Esoterik-Reparatur.
Die Aktion, die den schwarzen Block wirklich verschwinden ließ, war nur eine:
Den Prozess Typeless direkt beenden.
Zack – der Block war sofort weg.
Das zeigt auch: Es war nicht so ein Zustand „System ist kaputt, man muss neu starten“, sondern ein Fensterobjekt, das noch lebt, dessen Inhalt aber bereits kaputt ist.
Mein aktuelles Verständnis von „Root Cause“ und „Proximate Cause“
Ich würde es in zwei Ebenen aufteilen:
Nahe Ursache
Das Status-Floating-Window von Typeless ist nach einer Anomalie in der Display-Kette beim Wiederherstellen gescheitert und hat ein schwarzes Top-Level-Fenster hinterlassen.
Tiefer liegende Root Cause
Der Windows-Grafik-Stack hatte in diesem Zeitraum zuerst ein Problem, etwa:
- DWM wurde unterbrochen/neu aufgebaut
- GPU-Watchdog-Event wurde ausgelöst
- Grafiktreiber oder Display-Topologie war kurzzeitig instabil
Typeless ist also nicht die einzige Problemquelle, eher einer der auffälligsten „Opfer“ dieser Episode.
Rückblickend: Was ist am verdächtigsten?
Nach meiner eigenen Priorisierung:
- GPU-Treiber / kurzfristige Instabilität des Grafik-Stacks
- Zu viele resident laufende Window-Enhancer/Overlay-Programme übereinander
- Typeless selbst behandelt Topologieänderungen des Displays nicht stabil genug
Zu den „High-Risk“-Programmen, die damals gleichzeitig aktiv waren, gehörten:
TypelessPixPinalttab_windowsNVIDIA Overlay- sowie der von mir bereits entfernte
CPALauncher
Einzeln betrachtet muss davon nichts zwingend ein Problem sein – aber zusammen wirkt es wie ein Stresstest für DWM und D3D11.
Wenn ich so etwas das nächste Mal wieder habe: Wie ich schneller vorgehen würde
Meine Reihenfolge für die Diagnose würde ich jetzt so anpassen:
- Prüfen, ob sich der schwarze Block in einen Screenshot aufnehmen lässt
- Wenn ja: sofort als Software-Fenster einstufen, kein Panelschaden
- Task-Manager öffnen und nach Floating-/Overlay-/Screenshot-/Window-Enhancer-Prozessen suchen
- Enumerieren oder visuell festnageln, zu welchem Fenster der Block gehört
- Erst den Prozess beenden, danach in Ruhe die Systemlogs prüfen
- Zum Schluss entscheiden, ob man noch tiefer am GPU-Treiber ansetzen muss
Vorläufiges Fazit
Das war diesmal weder „Monitor kaputt“ noch einfach „Chrome schwarzer Bildschirm“.
Genauer gesagt:
Eine Anomalie auf Grafik-Ketten-/DWM-Ebene hat eine Reihe von Programmen, die von Desktopkomposition abhängen, mitgerissen; und das Status-Floating-Window von Typeless ist unglücklicherweise als riesiges schwarzes Geisterfenster in der Bildschirmmitte stehen geblieben.
Das ist wirklich sehr Windows – und auch irgendwie interessant:
Nicht so ein Fehler, den man auf den ersten Blick erkennt, sondern man muss erst akzeptieren, dass „der schwarze Block auch ein Fensterobjekt ist“ – dann wird der Rest der Fehlersuche plötzlich viel geradliniger.
Wenn ich später noch Treiberversion, Repro-Bedingungen oder die konkrete Typeless-Funktion, die diesen Zustand triggert, weiter eingrenzen kann, poste ich noch ein Update.