BAD_POOL_HEADER (0x19) beheben: RAM oder Treiber?

BAD_POOL_HEADER beheben heißt bei Windows 11 und Windows 10: Der Stopcode 0x00000019 meldet, dass ein Verwaltungsblock im Kernel-Speicher – dem sogenannten „Pool“ – beschädigt ist. Laut Microsoft steckt fast immer ein fehlerhafter Gerätetreiber oder defekter Arbeitsspeicher dahinter, seltener eine kaputte Systemdatei. Der schnellste Weg: zuletzt installierte Treiber und Programme entfernen, den RAM mit der Windows-Speicherdiagnose testen und die Systemdateien mit sfc /scannow prüfen.

Der Pool ist der Speicherbereich, aus dem der Windows-Kernel und die Treiber ständig kleine Speicherhäppchen anfordern und wieder freigeben. Jeder Block hat einen „Header“ mit Verwaltungsdaten. Stimmt dieser Header nicht mehr – weil ein Treiber über seinen Bereich hinausgeschrieben hat oder ein RAM-Bit gekippt ist – zieht Windows die Notbremse und zeigt den Bluescreen, statt mit beschädigtem Speicher weiterzuarbeiten.

Ist das wirklich mein Fehler? Symptome und Abgrenzung

Der Bluescreen nennt unten den Stopcode. Für diese Anleitung passt es, wenn dort BAD_POOL_HEADER oder der Wert 0x00000019 steht. Häufig folgt in Klammern noch ein Zusatzwert (etwa 0x00000003 oder 0x00000021): Das ist der erste Parameter des Stopcodes, und er sagt, welche Art von Beschädigung Windows gefunden hat.

Typische Muster, die auf die Ursache deuten:

• Der Absturz kam nach einem Update oder einer neuen Installation: Ein frischer Treiber, ein neues Programm oder ein zusätzliches Antivirus-Tool ist der wahrscheinlichste Auslöser.
• Die Bluescreens kommen unregelmäßig und mit wechselnden Stopcodes: Microsoft nennt genau dieses Muster als Hinweis auf fehlerhaften physischen Arbeitsspeicher und empfiehlt dann die Windows-Speicherdiagnose.
• Der Fehler tritt schon beim Hochfahren auf: Dann brauchst du den abgesicherten Modus (weiter unten), um überhaupt an die Reparaturschritte zu kommen.
• Der Absturz kommt reproduzierbar bei einer bestimmten Aktion – beim Drucken, beim Verbinden mit dem WLAN, beim Start eines Spiels: Dann gehört der Treiber des beteiligten Geräts ganz nach oben auf die Verdächtigenliste.

Was der Zusatzwert in Klammern verrät

Der erste Parameter ist kein Zufallswert. Die Treiber-Dokumentation von Microsoft ordnet ihm eine feste Bedeutung zu – das hilft, Treiber-Fehler von Speicher-Fehlern zu trennen:

0x2	Die Prüfung im Special Pool ist fehlgeschlagen – typisch, wenn Driver Verifier bereits läuft und einen Treiber beim Überschreiben erwischt.
0x3	Die Freispeicher-Liste ist beschädigt. In einer gesunden Liste wären die Parameter 2, 3 und 4 identisch.
0x7 / 0x8 / 0x9 / 0xA / 0x20	Die Größenangabe im Blockkopf ist kaputt, zu groß oder null.
0x21	Die Daten hinter dem freigegebenen Block sind beschädigt – der Aufrufer hat über den Block hinausgeschrieben.
0x22	Es wird eine Adresse freigegeben, zu der es keinen Eintrag gibt: Der Speicher wurde bereits freigegeben oder nie angefordert (klassischer Double-Free).

Für die Reparatur zu Hause ändert der Wert wenig – er ist aber ein guter Hinweis für die spätere Dump-Analyse und gehört in jede Support-Anfrage. Nicht verwechseln: BAD_POOL_CALLER (Stopcode 0x000000C2) ist ein eigener Fehler. Er zeigt in dieselbe Richtung, die Diagnose unten passt dort genauso.

BAD_POOL_HEADER beheben – Schritt für Schritt

Arbeite die Schritte der Reihe nach ab – von harmlos nach tiefgreifend. Nach jedem Schritt neu starten und schauen, ob der Bluescreen wiederkommt. Nur so weißt du am Ende, welche Maßnahme wirklich gewirkt hat.

1. Zuletzt installierte Software oder Treiber entfernen. Denk zurück: Was kam kurz vor dem ersten Absturz dazu? Deinstalliere neue Programme über Einstellungen → Apps → Installierte Apps. Ein zusätzlich installiertes Antivirus-Programm ist ein Klassiker – teste probeweise ohne, der Windows-eigene Defender schützt in der Zwischenzeit weiter.
2. Neu angeschlossene Hardware abziehen. Microsoft nennt frisch eingebaute oder angesteckte Geräte als ersten Prüfpunkt bei Stoppcode-Fehlern. Externe Dockingstations, USB-Hubs, DVB-Sticks und Zusatz-Netzwerkkarten bringen eigene Kernel-Treiber mit – erst einmal abziehen und beobachten.
3. Grafik-, Chipsatz- und Netzwerktreiber prüfen. Öffne den Geräte-Manager (Rechtsklick auf das Startmenü). Ein Gerät mit gelbem Warndreieck ist der erste Verdächtige. Über Rechtsklick → Eigenschaften → Treiber setzt du einen kürzlich aktualisierten Treiber per Vorheriger Treiber zurück. Neue Treiber holst du dir beim Hersteller des Geräts oder des Notebooks, nicht bei Treiber-Sammelseiten.
4. Windows-Updates einspielen. Unter Einstellungen → Windows Update prüfen und auch die optionalen Treiberupdates ansehen. Ersetzt ein Update einen fehlerhaften Systemtreiber, ist der Fehler damit erledigt – kam der Bluescreen dagegen direkt nach einem Update, ist Schritt 3 (Rollback) der richtigere Weg.
5. Systemdateien reparieren. Öffne die Eingabeaufforderung als Administrator (Startmenü → „cmd“ tippen → Als Administrator ausführen) und führe nacheinander aus:
   sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
   Der erste Befehl repariert beschädigte Systemdateien, der zweite setzt das Windows-Abbild instand, aus dem sfc seine Kopien zieht.
6. Arbeitsspeicher testen. Tippe im Startmenü Speicher und wähle Speicherprobleme Ihres Computers diagnostizieren (alternativ mdsched.exe ausführen). Der PC startet neu und prüft den RAM. Das Ergebnis steht danach in der Ereignisanzeige unter Windows-Protokolle → System beim Eintrag MemoryDiagnostics-Results – genau diesen Weg beschreibt auch Microsofts Doku zum Stopcode 0x19.
7. Datenträger und freien Speicherplatz prüfen. In der Administrator-Eingabeaufforderung chkdsk /f /r ausführen und mit J für den Neustart bestätigen. Microsoft empfiehlt außerdem, dauerhaft rund 10 bis 15 Prozent der Systempartition frei zu lassen – ohne freien Platz kann Windows weder Auslagerungsdatei noch Absturzprotokoll sauber schreiben.

Vorher sichern: Bevor du an Treibern, Datenträger-Tools oder tieferen Einstellungen schraubst, kopiere wichtige Dateien auf ein externes Medium. Bei einem RAM- oder Festplattendefekt kann das System jederzeit erneut abstürzen – und dann mitten im Schreibvorgang.

Wenn das nicht hilft

Bleibt der Bluescreen, grenzt du die Ursache härter ein:

• Sauberer Neustart (Clean Boot). Tippe msconfig ins Startmenü. Im Reiter Dienste unten Alle Microsoft-Dienste ausblenden anhaken und die restlichen deaktivieren; im Task-Manager unter Autostart alle Einträge abschalten. Läuft der PC danach stabil, war es ein Hintergrundprogramm – die Dienste einzeln wieder aktivieren, bis der Übeltäter auffliegt.
• RAM-Riegel einzeln testen. Zeigt die Speicherdiagnose Fehler oder bleibt der Verdacht: Bei einem Desktop-PC die Riegel nacheinander einzeln einbauen und beobachten, welcher die Abstürze auslöst. Vorher Netzstecker ziehen. Läuft der Rechner mit einem Riegel wochenlang stabil und mit dem anderen nicht, hast du deinen Defekt gefunden.
• Windows kommt nicht mehr hoch? Erzwinge zweimal beim Booten einen Abbruch (Power-Taste), beim dritten Mal startet die automatische Reparatur. Unter Erweiterte Optionen → Starteinstellungen lässt sich der abgesicherte Modus starten, in dem nur die nötigsten Treiber laufen – dort greifen die Schritte oben ebenfalls. Auch ein Systemwiederherstellungspunkt lässt sich von hier aus einspielen.

Driver Verifier: das schwere Gerät, mit Sicherheitsnetz

Findest du den schuldigen Treiber nicht, setzt Driver Verifier ihn unter Stress, bis er sich verrät. Das Werkzeug steckt in jedem Windows und wird mit verifier in der Administrator-Eingabeaufforderung gestartet. Wichtig: Es provoziert absichtlich Bluescreens. Microsoft empfiehlt in der Befehlsreferenz zu Driver Verifier ausdrücklich, so wenige Treiber wie möglich zu prüfen, weil die Prüfung Rechenzeit kostet.

• Nur verdächtige Treiber prüfen: verifier /standard /driver name.sys – Platzhalter wie n*.sys versteht der Befehl nicht.
• Sicherheitsnetz setzen: verifier /bootmode resetonbootfail schaltet die Prüfung ab, sobald Windows nicht mehr startet. Ohne diese Option bootet ein Rechner mit defektem Treiber in eine Bluescreen-Schleife.
• Status ansehen: verifier /querysettings zeigt, was beim nächsten Start geprüft wird.
• Alles zurücknehmen: verifier /reset löscht sämtliche Einstellungen – nach der Fehlersuche Pflicht, sonst läuft die Prüfung dauerhaft mit.

Zur Standard-Prüfung gehört der Special Pool: Windows legt Speicherblöcke einzeln mit Schutzmuster ab und schlägt sofort Alarm, wenn ein Treiber darüber hinausschreibt. Deshalb taucht dann oft der Parameter 0x2 aus der Tabelle oben auf – und der Bluescreen nennt endlich den Treibernamen.

Den Minidump auswerten: welcher Treiber war es wirklich?

Windows schreibt bei jedem Bluescreen ein kleines Speicherabbild. Es enthält die Stop-Meldung mit allen Parametern, die Liste der geladenen Treiber und den Aufrufstapel des abgestürzten Threads – also genau die Information, die dir beim Raten fehlt.

1. Abbild aktivieren. sysdm.cpl ausführen, Reiter Erweitert, unter Starten und Wiederherstellen auf Einstellungen, dann bei Debuginformationen speichern die Option Kleines Speicherabbild (256 KB) wählen. Windows braucht dafür eine Auslagerungsdatei von mindestens 2 MB auf dem Startvolume.
2. Dateien finden. Die Abbilder liegen unter %SystemRoot%\Minidump, also meist C:\Windows\Minidump. Jede Datei bekommt einen datumscodierten Namen, alte Dumps bleiben erhalten – praktisch, um zu sehen, ob immer derselbe Treiber auftaucht.
3. Analysieren. WinDbg gibt es kostenlos im Microsoft Store. Dump öffnen und !analyze -v eingeben: Der Befehl zeigt Stopcode, Parameter und den verdächtigen Modulnamen. lm N T listet die geladenen Treiber mit Pfad und Version.

Ein Vorbehalt aus derselben Microsoft-Anleitung: Weil das kleine Abbild nur wenige Daten enthält, findet die Analyse Fehler nicht immer, wenn sie nicht vom gerade laufenden Thread verursacht wurden. Bei Pool-Beschädigungen ist das häufig so – der Verursacher hat den Speicher womöglich Sekunden vorher zerschossen. Taucht in mehreren Dumps derselbe Fremdtreiber auf, ist das trotzdem der beste Hinweis, den du ohne Spezialwerkzeug bekommst.

Hintergrund: Warum passiert BAD_POOL_HEADER überhaupt?

Windows verwaltet Kernel-Speicher in zwei Pools: dem nonpaged pool (bleibt immer im RAM) und dem paged pool (darf auf die Auslagerungsdatei ausgelagert werden). Aus diesen Pools holen sich Treiber laufend kleine Speicherblöcke. Jeder Block trägt vorne einen Header mit Größe und Verkettung zum nächsten freien Block. Zusätzlich bekommt jede Anforderung ein vierstelliges Pool-Tag, an dem sich später ablesen lässt, welche Komponente den Speicher belegt hat.

Schreibt ein fehlerhafter Treiber ein paar Bytes zu viel, überschreibt er den Header des Nachbarblocks. Beim nächsten Zugriff merkt der Speichermanager, dass die Verwaltungsdaten nicht mehr zusammenpassen – und löst 0x19 aus. Denselben Effekt hat ein defekter RAM-Baustein: Kippt dort ein Bit im Header, passt die Verkettung ebenfalls nicht mehr. Microsoft formuliert es nüchtern: Der Pool ist zum Zeitpunkt der Anfrage bereits beschädigt – und der Aufrufer, der den Bluescreen auslöst, muss nicht der Schuldige sein.

Genau deshalb sieht die Fehlersuche so umständlich aus. Der Absturzzeitpunkt sagt wenig über den Verursacher, weil zwischen Zerstörung und Entdeckung Sekunden liegen können. Wer BAD_POOL_HEADER beheben will, kommt deshalb an zwei Fragen nicht vorbei: Welcher Treiber schreibt Unsinn? und Ist der Speicher physisch in Ordnung? Für Azubis und Prüflinge ist der Fehler ein gutes Lehrstück: Er zeigt, warum der Kernel Speicher überhaupt in Blöcke mit Verwaltungskopf zerlegt und warum ein einziger falscher Schreibzugriff das ganze System stoppen kann.

Quellen

• Microsoft Learn: Bug Check 0x19 BAD_POOL_HEADER – Parameter-Tabelle, Ursache, Driver Verifier und Windows-Speicherdiagnose
• Microsoft Learn: Driver Verifier Command Syntax – Befehle /standard, /bootmode, /querysettings, /reset
• Microsoft Learn: Lesen kleiner Speicherabbilddateien – Konfiguration, Speicherort %SystemRoot%\Minidump, Analyse mit !analyze -v
• Microsoft Support: Problembehandlung bei unerwarteten Neustarts und Stoppcodefehlern – neue Hardware, Treiber, freier Speicherplatz, Wiederherstellung
• Dell Support: Bluescreen-Dump-Dateien mit WinDbg analysieren – Schritt-für-Schritt-Anleitung für die Dump-Analyse

Häufige Fragen

Ist BAD_POOL_HEADER ein RAM- oder ein Treiberfehler?

Beides ist möglich. Kam der Bluescreen kurz nach einem Treiber-Update oder einer neuen Software, ist meist der Treiber schuld. Treten die Abstürze unregelmäßig mit wechselnden Stopcodes auf, deutet das laut Microsoft eher auf defekten Arbeitsspeicher hin.

Was bedeutet der Zusatzwert hinter 0x00000019?

Der Wert in Klammern ist der erste Parameter des Stopcodes: 0x3 steht für eine beschädigte Freispeicher-Liste, 0x21 für ein Überschreiben hinter dem Block, 0x22 für eine doppelt freigegebene Adresse.

Anzeige

Wo finde ich den Minidump nach einem Bluescreen?

Unter %SystemRoot%\Minidump, also meist C:\Windows\Minidump. Aktivieren lässt sich das kleine Speicherabbild (256 KB) über sysdm.cpl, Reiter Erweitert, Starten und Wiederherstellen.

Was mache ich, wenn Windows wegen 0x19 gar nicht mehr startet?

Erzwinge zweimal beim Hochfahren einen Abbruch über die Power-Taste, beim dritten Mal startet die automatische Reparatur. Über Erweiterte Optionen und Starteinstellungen erreichst du den abgesicherten Modus.

Ist Driver Verifier gefährlich?

Er erzeugt absichtlich Bluescreens und kann den Start blockieren. Setze deshalb verifier /bootmode resetonbootfail als Sicherheitsnetz und schalte ihn nach der Fehlersuche mit verifier /reset wieder ab.