BSOD Master Guide ⚡ PAGE_FAULT, IRQL, MEMORY & All Stop Errors Fixed

Notera stoppkoden först – innan du rör något

En blå skärm är inte ett problem; det är Windows som rapporterar dussintals olika fel i samma färg. Korrigeringen beror helt på stoppkoden som skrivits på skärmen, så det första steget är alltid detsamma: ta ett foto av den blå skärmen, skriv ner den exakta koden (till exempel PAGE_FAULT_IN_NONPAGED_AREA eller 0x00000050), och notera tre saker - när det händer (vid start, i ett spel, slumpmässigt), vad som ändrades precis innan det startade, en ny drivrutin, en klocka, en ny drivrutin (ett, en ny RAM och en ny) i samma ögonblick eller rör sig. En kod som alltid visas vid samma åtgärdspunkter i programvaran; en kod som ändrar alla kraschpunkter på hårdvara, vanligtvis RAM.

PAGE_FAULT_IN_NONPAGED_AREA (0x50) — Minne eller drivrutin

Denna kod betyder att kod försökte läsa en sida i minnet som inte finns eller är ogiltig. I praktiken är orsaken en av två familjer. Först, RAM: en defekt sticka, en dåligt placerad sticka eller instabila XMP/överklockningsinställningar som skadar minnet – testa det som visas i steg 4. För det andra, drivrutiner: en drivrutin (mycket ofta grafik-, nätverks- eller antivirusfilterdrivrutiner) som refererar till frigjort eller fel minne. Om den här koden startade direkt efter en drivrutinsuppdatering, rulla tillbaka den drivrutinen i Enhetshanteraren eller avinstallera den i felsäkert läge; om den startade efter att ha lagt till RAM, ta bort den nya stickan och testa igen. Kör minnestestet innan du skyller på programvaran — en PAGE_FAULT med slumpmässiga andra koder bredvid den är en RAM-signatur.

IRQL_NOT_LESS_OR_EQUAL (0x0A) — En förare som inte beter sig

IRQL_NOT_LESS_OR_EQUAL betyder kärnkod eller en drivrutin som har åtkomst till det sökta minnet på en för hög nivå för avbrottsbegäran – med enkla ord, en buggig drivrutin gjorde något den aldrig får göra. Detta är den mest drivrutinorsakade koden av alla: nyligen uppdaterade eller nyinstallerade drivrutiner är de främsta misstänkta, särskilt grafik, Wi-Fi/LAN, chipset och antivirusdrivrutiner från tredje part. Fixeringsordningen: avinstallera eller återställa den drivrutin som ändrades senast; uppdatera de återstående drivrutinerna från PC- eller moderkortstillverkarens officiella supportsida (inte slumpmässiga drivrutinsuppdateringsverktyg); ta bort antivirus från tredje part tillfälligt för att testa. Eftersom minneskorruption orsakad av dåligt RAM-minne kan dölja sig som en IRQL-krasch, kör RAM-testet också om ingen drivrutinsändring förklarar det.

MEMORY_MANAGEMENT (0x1A) – Testa RAM-minnet på rätt sätt

MEMORY_MANAGEMENT betyder att Windows minneshanterare fann sin egen bokföring skadad - den klassiska dåliga RAM-koden, även om en korrupt sidfil eller en drivrutin som skriver där den inte borde också kan utlösa den. Testa först, avsluta sedan. Börja med det inbyggda verktyget: kör mdsched.exe (Windows Memory Diagnostic), välj "Starta om nu och leta efter problem" och låt det slutföras. För en dom som du kan lita på, använd MemTest86 från en startbar USB och låt den köra flera helpassningar - fel som bara visas under långa tester är fortfarande misslyckanden: även ett enda fel betyder att minnesundersystemet är felaktigt. Isolera sedan: testa en pinne i taget, i en lucka i taget, för att hitta den skyldiga stickan eller luckan. Om RAM-minnet är överklockat eller på en XMP/EXPO-profil, ställ tillbaka det till lagerhastigheter och testa om – RAM som bara misslyckas vid XMP är fortfarande problemet.

WHEA_UNCORRECTABLE_ERROR (0x124) — Verklig hårdvara fungerar inte

WHEA skiljer sig från de andra koderna: det är Windows Hardware Error Architecture som rapporterar att hårdvaran i sig orsakade ett okorrigerbart fel - oftast CPU, men också en felaktig strömförsörjning, överhettning, en instabil överklocka eller ibland en döende enhet eller moderkort. Programfixar botar inte en äkta WHEA. Arbeta igenom det fysiskt: ta bort varje överklockning (CPU, RAM XMP ingår) och testa på lager; kontrollera temperaturer under belastning och rengör/klistra in om CPU:n lagar mat; sätt tillbaka RAM och strömkablar; testa med en känd-bra strömförsörjning om kraschar inträffar under belastning; och kontrollera Event Viewers WHEA-Logger-poster för vilken komponent som rapporterade felet. Om WHEA-krascher fortsätter vid lagerinställningar med bra temperaturer är CPU eller moderkort troligtvis slutet på vägen.

Reparera systemfiler — DISM först, sedan SFC

För programfamiljen av koder – CRITICAL_PROCESS_DIED (0xEF), SYSTEM_SERVICE_EXCEPTION (0x3B) och krascher orsakade av korrupta Windows-filer – reparera systemavbildningen innan något drastiskt. Öppna kommandotolken som administratör och kör de två kommandona exakt som visas, i denna ordning: DISM reparerar komponentlagret som SFC är beroende av, sedan kontrollerar och ersätter SFC korrupta systemfiler. Låt var och en avsluta helt; en omstart mellan dem är bra.

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

Two neighbours worth knowing: INACCESSIBLE_BOOT_DEVICE (0x7B) after a BIOS change usually means the storage mode was switched (RAID/RST vs AHCI) or the boot drive's driver is missing — set the mode back, do not reinstall. DPC_WATCHDOG_VIOLATION (0x133) most often traces to a stuck driver or an SSD firmware/storage driver problem — update the storage and chipset drivers from the maker first. And if Windows will not stay up long enough to work, do all of this from Safe Mode (hold Shift while choosing Restart → Troubleshoot → Advanced options → Startup Settings → Safe Mode), where most third-party drivers never load — a PC that is stable in Safe Mode but crashes normally has just told you the fault lives in a driver or startup service.

Läs minidumpen och bekräfta åtgärden

Varje blå skärm lämnar bevis: en liten dumpfil i C:\Windows\Minidump, namngiven efter dess datum. Öppna den senaste i en dumpläsare som BlueScreenView eller WinDbg och läs två saker – buggkontrollkoden (stämmer den överens med vad skärmen visade?) och modulens "orsakad av drivrutin"-namnet. Behandla namn ärligt: ​​grafikdrivrutiner som nvlddmkm.sys (NVIDIA) och amdkmdag.sys (AMD) skyller sig själva direkt, men ntoskrnl.exe är Windows-kärnan – det är där kraschen dök upp, inte boven, så titta på RAM-testresultaten och istället. Korrigeringen bekräftas först när krascharna slutar i verklig användning och inga nya .dmp-filer dyker upp – håll datorn under normal arbetsbelastning i några dagar innan du anropar det löst.