PAGE_FAULT_IN_NONPAGED_AREA in Windows 11: RAM, Treiber oder Dateisystem?

PAGE_FAULT_IN_NONPAGED_AREA in Windows 11 (Stopcode 0x50) bedeutet: Der Windows-Kernel hat auf eine Speicheradresse zugegriffen, die ungültig oder längst freigegeben war. Auslöser sind fast immer ein fehlerhafter Treiber, defekter Arbeitsspeicher, ein Fremd-Virenscanner oder ein beschädigtes NTFS-Dateisystem. Arbeite in dieser Reihenfolge: Stopcode und Treibernamen aus der Ereignisanzeige holen, RAM mit mdsched.exe testen, sfc und DISM laufen lassen, Treiber erneuern, zuletzt chkdsk.

Ist es wirklich PAGE_FAULT_IN_NONPAGED_AREA in Windows 11?

Seit Version 24H2 ist der klassische blaue Absturzbildschirm schwarz: kein trauriger Smiley, kein QR-Code, nur die Meldung, dass das Gerät neu starten muss, plus Stopcode und – wenn Windows ihn kennt – den Namen des schuldigen Treibers. Microsoft hat die Sammelphase auf rund zwei Sekunden verkürzt, weshalb viele den Text gar nicht mehr zu Gesicht bekommen. Stand August 2026 betrifft das die verbreiteten Stände 24H2 und 25H2 (Builds 26100/26200).

Den Code liest du danach in Ruhe nach: Win + X → Ereignisanzeige → Windows-Protokolle → System. Filtere nach der Quelle BugCheck, Ereignis-ID 1001 – dieser Eintrag nennt den Stopcode samt seinen vier Parametern und den Pfad zur Speicherabbild-Datei. Der Eintrag Kernel-Power mit ID 41 direkt daneben besagt nur, dass der Rechner ohne sauberes Herunterfahren neu gestartet ist; er ist die Folge, nicht die Ursache.

Zur Abgrenzung, weil die vier häufigsten Speicher-Bluescreens gern verwechselt werden:

• PAGE_FAULT_IN_NONPAGED_AREA (0x50): Zugriff auf eine ungültige oder bereits freigegebene Adresse im nicht auslagerbaren Speicher.
• DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1): Ein Treiber greift auf zu hoher Interrupt-Priorität auf auslagerbaren Speicher zu – fast immer ein Treiberfehler, seltener RAM.
• MEMORY_MANAGEMENT (0x1A): Die Speicherverwaltung selbst findet inkonsistente Strukturen – hier ist RAM oder eine kaputte Auslagerungsdatei wahrscheinlicher.
• CRITICAL_PROCESS_DIED (0xEF): Ein Systemprozess ist gestorben, meist nach beschädigten Systemdateien oder Update-Resten.

Steht auf dem Absturzbildschirm oder im BugCheck-Eintrag eine Datei mit der Endung .sys – etwa nvlddmkm.sys für Nvidia-Grafik oder ein Filtertreiber eines Virenscanners –, hast du bereits den ersten Verdächtigen und kannst mehrere Schritte überspringen.

Die vier Parameter des Stopcodes lesen

Der BugCheck-Eintrag liefert vier Werte in Klammern. Sie sind kein Deko-Beiwerk, sondern grenzen die Ursache ein – so beschreibt es Microsofts Bugcheck-Dokumentation zu 0x50:

Parameter	Bedeutung
1	Die Speicheradresse, auf die zugegriffen wurde.
2	Art des Zugriffs: 0 = Lesen, 2 = Schreiben, 10 = Ausführen (x86/x64).
3	Adresse des Befehls, der den Zugriff ausgelöst hat – der Fingerzeig auf das schuldige Modul.
4	Art des Seitenfehlers: 0x0 = Eintrag war als frei markiert, 0x2 = kein gültiger Page-Table-Eintrag, 0x4 = unzulässige (nicht kanonische) Adresse, 0xF = Kernel-Code wollte unerlaubt auf eine Benutzeradresse zugreifen.

Für die Praxis reicht die grobe Deutung: Ein 0x4 oder 0xF in Parameter 4 riecht stark nach Programmierfehler in einem Treiber, während wechselnde, wahllos aussehende Adressen in Parameter 1 eher zu kippenden Speicherzellen passen.

Lösung Schritt für Schritt

Arbeite die Punkte der Reihe nach ab und starte nach jedem Schritt neu. Nur so weißt du am Ende, welcher Handgriff geholfen hat – und musst nicht raten, ob der Fehler wirklich weg ist.

1. Die letzte Änderung zurücknehmen. Traten die Abstürze nach einem Treiber- oder Windows-Update auf, ist das der schnellste Weg: Geräte-Manager (Win + X) → Gerät doppelklicken → Reiter Treiber → Vorheriger Treiber. Ein Windows-Update entfernst du unter Einstellungen → Windows Update → Updateverlauf → Updates deinstallieren.
2. Arbeitsspeicher testen. Win + R, mdsched.exe eingeben, Jetzt neu starten und nach Problemen suchen wählen. Der Durchlauf dauert je nach Ausbau einige Minuten bis rund eine halbe Stunde. Das Ergebnis landet in der Ereignisanzeige unter System im Eintrag MemoryDiagnostics-Results. Bleibt der Test sauber, die Abstürze aber sporadisch, lohnt ein mehrstündiger Lauf mit MemTest86 vom USB-Stick – die Bordmittel-Diagnose findet grobe Defekte, nicht jede wackelige Zelle.
3. Systemdateien reparieren. Terminal als Administrator öffnen (Win + X → Terminal (Administrator)) und nacheinander ausführen:
   • sfc /scannow – sucht beschädigte Systemdateien und ersetzt sie aus dem lokalen Komponentenspeicher.
   • DISM /Online /Cleanup-Image /RestoreHealth – repariert genau diesen Komponentenspeicher, wenn sfc nichts ersetzen konnte. Danach sfc /scannow ein zweites Mal laufen lassen.
   • Treiber gezielt erneuern. Grafikkarte, Chipsatz, Speichercontroller (SATA/NVMe) und Netzwerkkarte lädst du direkt beim Hersteller – Nvidia, AMD, Intel oder der Mainboard-Support-Seite. Windows Update liefert oft ältere, generische Versionen. Zeigt der Geräte-Manager ein gelbes Ausrufezeichen, fängst du bei diesem Gerät an.
   • Dateisystem prüfen. Vorher wichtige Daten sichern – chkdsk repariert Strukturen und kann in seltenen Fällen Daten opfern. Im Administrator-Terminal chkdsk C: /f /r ausführen; für das Systemlaufwerk fragt Windows, ob die Prüfung beim nächsten Start laufen soll. Mit J bestätigen und neu starten.
   • Fremd-Virenscanner testweise entfernen. Microsoft nennt Antivirensoftware ausdrücklich als Auslöser von 0x50, weil sie tiefe Filtertreiber im Kernel einhängt. Deinstalliere sie mit dem Removal-Tool des Herstellers, nicht nur über die Programmliste; der Defender springt in der Zwischenzeit automatisch ein.

Wenn das nicht hilft: die selteneren Ursachen

Bleibt der Bluescreen, geht es an die Auslöser, die keine Standard-Anleitung abdeckt. Hier trennt sich echte Diagnose von blindem Herumklicken.

• Speicher außerhalb der Spezifikation. Läuft der RAM mit XMP- oder EXPO-Profil, arbeitet er oberhalb der garantierten Werte. Setze das Profil im BIOS/UEFI testweise auf Standard und beobachte ein paar Tage. Kürzlich verbaute Module, SSDs oder Steckkarten baust du zum Test wieder aus; bei zwei Riegeln hilft der Einzeltest, um den defekten zu finden.
• Laufwerk am Ende. Ein sterbendes Systemlaufwerk erzeugt Lesefehler in ausgelagerten Kernel-Strukturen. Prüfe die SMART-Werte mit dem Herstellertool (Samsung Magician, Crucial Storage Executive, WD Dashboard) und spiele eine verfügbare Firmware ein – gerade bei NVMe-SSDs sind Firmware-Bugs eine reale Absturzquelle.
• Kernisolierung prüfen. Unter Windows-Sicherheit → Gerätesicherheit → Details zur Kernisolierung zeigt Windows, ob die Speicherintegrität aktiv ist und welche Treiber sie als inkompatibel blockiert. Diese Liste ist eine hervorragende Verdächtigenliste, wenn du keinen Namen auf dem Absturzbildschirm gesehen hast.
• Absturzprotokoll auswerten. Windows legt Minidumps unter C:\Windows\Minidump ab. Fehlt der Ordner, ist die Abbild-Erstellung deaktiviert: Win + R → sysdm.cpl → Erweitert → Starten und Wiederherstellen → Einstellungen → als Debuginformationen Automatisches Speicherabbild wählen. Auswerten kannst du die Datei mit BlueScreenView (zeigt den zuletzt aktiven Treiber) oder mit WinDbg aus dem Microsoft Store: Der Befehl !analyze -v nennt unter MODULE_NAME und FAULTING_MODULE das verantwortliche Modul.
• Driver Verifier als letzte Instanz. Nur mit vorher gesetztem Wiederherstellungspunkt: verifier im Startmenü, Standardeinstellungen erstellen, dann gezielt nur die verdächtigen Fremdtreiber prüfen lassen. Der Verifier provoziert absichtlich einen Bluescreen, sobald sich ein Treiber falsch verhält, und nennt ihn im Dump. Achtung: Landet der Rechner danach in einer Absturzschleife, im abgesicherten Modus verifier /reset ausführen.

Windows startet gar nicht mehr durch

Kommt der Absturz schon beim Hochfahren, brauchst du die Wiederherstellungsumgebung. Schalte den Rechner dreimal während des Startvorgangs hart aus – beim vierten Versuch bootet Windows in die automatische Reparatur. Von dort: Problembehandlung → Erweiterte Optionen → Starteinstellungen → Neu starten, dann Taste 4 für den abgesicherten Modus oder 5 mit Netzwerktreibern. Im abgesicherten Modus laden nur Microsoft-Treiber; läuft der Rechner dort stabil, ist ein Fremdtreiber die Ursache.

Ab Windows 11 25H2 greift zusätzlich die Schnellwiederherstellung (Quick Machine Recovery): Scheitert der Start mehrfach, startet das Gerät selbstständig in die Wiederherstellungsumgebung, meldet die Absturzdaten an Microsoft und holt sich über Windows Update einen gezielten Fix, sofern für das Problem einer bereitsteht. Dafür braucht die Maschine eine Netzwerkverbindung – per Kabel klappt das zuverlässiger als über WLAN. Findet sich keine Abhilfe, landest du wieder bei Startreparatur und den übrigen WinRE-Werkzeugen. Microsofts Leitfaden zu unerwarteten Neustarts beschreibt die gleiche Reihenfolge: neue Hardware entfernen, abgesichert starten, Geräte-Manager prüfen, ausreichend freien Speicherplatz halten.

Warum passiert das überhaupt?

Windows teilt den Kernel-Speicher in zwei Pools. Der Paged Pool darf bei Speicherdruck auf die Festplatte ausgelagert werden, der Nonpaged Pool nicht – dort liegen Strukturen, auf die der Kernel jederzeit sofort zugreifen können muss, etwa in Interrupt-Routinen von Treibern. Greift Code auf eine Adresse in diesem Bereich zu, die gar nicht (mehr) gültig ist, kann Windows den Fehler nicht abfangen: Microsoft schreibt dazu wörtlich, der Zugriff lasse sich nicht per try-except schützen. Weiterarbeiten hieße, mit kaputten Kernel-Daten zu rechnen – also stoppt das System sofort.

Genau daraus folgt die Merkregel, die auch in der Fachinformatiker-Prüfung trägt: Ein reproduzierbarer 0x50, der immer bei derselben Aktion auftritt, zeigt auf Software – Treiber, Sicherheitsprogramm, ein bestimmtes Gerät. Ein zufälliger 0x50 ohne erkennbares Muster deutet auf Hardware, meist RAM oder Laufwerk. Deshalb steht der Speichertest so weit vorn: Er kostet eine halbe Stunde und halbiert den Suchraum. Und deshalb bringt ein Zurücksetzen von Windows bei PAGE_FAULT_IN_NONPAGED_AREA in Windows 11 oft gar nichts – gegen einen defekten Riegel hilft keine Neuinstallation.

Häufige Fragen

Was bedeutet PAGE_FAULT_IN_NONPAGED_AREA?

Der Stopcode 0x50 zeigt, dass Windows auf eine Adresse im nicht auslagerbaren Kernel-Speicher zugegriffen hat, die ungültig oder bereits freigegeben war. Weil dort kritischer Kernel-Code läuft, muss das System sofort anhalten.

Ist der Fehler ein Hardware- oder ein Treiberproblem?

Beides ist möglich. Ein Absturz, der immer bei derselben Aktion auftritt, deutet auf einen Treiber oder ein Sicherheitsprogramm; ein zufälliger Absturz eher auf defekten RAM oder ein sterbendes Laufwerk.

Wie finde ich heraus, welcher Treiber den Bluescreen ausgelöst hat?

Windows speichert jeden Absturz als Minidump unter C:\Windows\Minidump. BlueScreenView zeigt daraus den zuletzt aktiven Treiber, WinDbg analysiert den Dump mit dem Befehl !analyze -v und nennt das fehlerhafte Modul.

Wo sehe ich den Stopcode, wenn der Rechner zu schnell neu startet?

In der Ereignisanzeige unter Windows-Protokolle → System. Der Eintrag der Quelle BugCheck mit der Ereignis-ID 1001 enthält den Stopcode, seine vier Parameter und den Pfad zur Speicherabbild-Datei.

Kann defekter RAM PAGE_FAULT_IN_NONPAGED_AREA verursachen?

Ja, fehlerhafte Speichermodule gehören zu den häufigsten Ursachen. Teste mit mdsched.exe, prüfe bei zwei Riegeln jeden einzeln und setze ein aktives XMP- oder EXPO-Profil testweise auf Standardwerte zurück.