BSOD Master Guide ⚡ PAGE_FAULT, IRQL, MEMORY og alle stoppfeil fikset

Merk først stoppkoden – før du berører noe

En blå skjerm er ikke ett problem; det er Windows som rapporterer dusinvis av forskjellige feil i samme farge. Reparasjonen avhenger helt av stoppkoden som er skrevet på skjermen, så det første trinnet er alltid det samme: ta et bilde av den blå skjermen, skriv ned den nøyaktige koden (for eksempel PAGE_FAULT_IN_NONPAGED_AREA eller 0x00000050), og legg merke til tre ting - når det skjer (ved oppstart, i et spill, tilfeldig), hva som endret seg like før den startet, en ny, RAM og en ny driver (en, RAM og klokke) i samme øyeblikk eller beveger seg rundt. En kode som alltid vises ved de samme handlingspunktene ved programvaren; en kode som endrer alle krasjpunkter på maskinvare, vanligvis RAM.

PAGE_FAULT_IN_NONPAGED_AREA (0x50) — Minne eller driver

Denne koden betyr at kode prøvde å lese en side med minne som ikke eksisterer eller ikke er gyldig. I praksis er årsaken en av to familier. Først, RAM: en defekt pinne, en dårlig plassert pinne eller ustabile XMP/overklokkingsinnstillinger som ødelegger minnet – test det som vist i trinn 4. For det andre drivere: en driver (svært ofte grafikk-, nettverks- eller antivirusfilterdrivere) som refererer til frigjort eller feil minne. Hvis denne koden startet rett etter en driveroppdatering, rull den driveren tilbake i Enhetsbehandling eller avinstaller den i sikkermodus; hvis den startet etter å ha lagt til RAM, fjern den nye pinnen og test på nytt. Kjør minnetesten før du legger skylden på programvare – en PAGE_FAULT med tilfeldige andre koder ved siden av er en RAM-signatur.

IRQL_NOT_LESS_OR_EQUAL (0x0A) — En sjåfør som oppfører seg dårlig

IRQL_NOT_LESS_OR_EQUAL betyr kjernekode eller en driver som har tilgang til sideminne på for høyt nivå for avbruddsforespørsel - i enkle ord, en buggy-driver gjorde noe den aldri har lov til å gjøre. Dette er den mest driver-forårsakede koden av alle: nylig oppdaterte eller nylig installerte drivere er hovedmistenkte, spesielt grafikk, Wi-Fi/LAN, brikkesett og tredjeparts antivirusdrivere. Reparasjonsrekkefølgen: avinstaller eller rulle tilbake den driveren som ble endret sist; oppdater de resterende driverne fra PC-en eller hovedkortprodusentens offisielle støtteside (ikke tilfeldige driveroppdateringsverktøy); fjern tredjeparts antivirus midlertidig for å teste. Fordi minnekorrupsjon forårsaket av dårlig RAM kan forkle seg som et IRQL-krasj, kjør RAM-testen også hvis ingen driverendring forklarer det.

MEMORY_MANAGEMENT (0x1A) – Test RAM-en på riktig måte

MEMORY_MANAGEMENT betyr at Windows' minnebehandler fant sin egen bokføring ødelagt - den klassiske dårlige RAM-koden, selv om en korrupt sidefil eller en driver som skriver der den ikke burde, også kan utløse den. Test først, konkluder som andre. Start med det innebygde verktøyet: kjør mdsched.exe (Windows Memory Diagnostic), velg "Start på nytt nå og se etter problemer", og la det fullføre. For en dom du kan stole på, bruk MemTest86 fra en oppstartbar USB og la den kjøre flere fulle pass - feil som bare vises under lang testing er fortsatt feil: selv en enkelt feil betyr at minneundersystemet er defekt. Isoler deretter: test én pinne om gangen, i én spalte om gangen, for å finne den skyldige pinne eller sporet. Hvis RAM-en er overklokket eller på en XMP/EXPO-profil, sett den tilbake til lagerhastigheter og test på nytt – RAM som bare svikter ved XMP er fortsatt problemet.

WHEA_UNCORRECTABLE_ERROR (0x124) — Ekte maskinvare svikter

WHEA er forskjellig fra de andre kodene: det er Windows Hardware Error Architecture som rapporterer at selve maskinvaren ga en ukorrigerbar feil - oftest CPU, men også en sviktende strømforsyning, overoppheting, en ustabil overklokke eller noen ganger en døende stasjon eller hovedkort. Programvarerettinger kurerer ikke en ekte WHEA. Arbeid gjennom det fysisk: fjern hver overklokke (CPU, RAM XMP inkludert) og test på lager; sjekk temperaturer under belastning og rengjør/lim inn på nytt hvis CPU'en koker; plasser RAM og strømkabler på nytt; test med en kjent-god strømforsyning hvis krasj skjer under belastning; og sjekk Event Viewers WHEA-Logger-oppføringer for hvilken komponent som rapporterte feilen. Hvis WHEA-krasj fortsetter ved lagerinnstillinger med gode temperaturer, er CPU-en eller hovedkortet trolig slutten på veien.

Reparer systemfiler — DISM først, deretter SFC

For programvarefamilien av koder – CRITICAL_PROCESS_DIED (0xEF), SYSTEM_SERVICE_EXCEPTION (0x3B), og krasjer forårsaket av korrupte Windows-filer – reparer systembildet før noe drastisk. Åpne ledetekst som administrator og kjør de to kommandoene nøyaktig som vist, i denne rekkefølgen: DISM reparerer komponentlageret som SFC er avhengig av, deretter sjekker og erstatter SFC korrupte systemfiler. La hver enkelt bli ferdig; en omstart mellom dem er greit.

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.

Les Minidump og bekreft feilrettingen

Hver blå skjerm etterlater bevis: en liten dumpfil i C:\Windows\Minidump, navngitt etter datoen. Åpne den nyeste i en dump-leser som BlueScreenView eller WinDbg og les to ting - feilkontrollkoden (stemmer den med det skjermen viste?) og "forårsaket av driver"-modulnavnet. Behandle navn ærlig: grafikkdrivere som nvlddmkm.sys (NVIDIA) og amdkmdag.sys (AMD) klandrer seg selv direkte, men ntoskrnl.exe er Windows-kjernen – det er der krasj dukket opp, ikke den skyldige, så se på RAM-testresultatene i stedet. Reparasjonen bekreftes bare når krasjene stopper i reell bruk og ingen nye .dmp-filer vises – hold PC-en under normal arbeidsbelastning i noen dager før den løses.