Hur man tolkar BSOD-koder i Windows 11 steg för steg

PCHardwarePro » Windows » Hur man tolkar BSOD-koder i Windows 11 steg för steg

Om du har använt Windows 11 ett tag har du förmodligen stött på den ökända blåskärmen. Den skärmen där du ser ett meddelande som säger att din dator har stött på ett problem, en procentandel av informationsinsamlingen och en eller flera felkoder. Du hinner knappt läsa innan datorn visar en blå skärm och startar om.. De där BSOD-koderna (eller STOP-koderna) är den viktigaste ledtråden till vad som gick fel.Men att tolka dem är inte alltid så enkelt som att "titta på det i Loggboken".

Dessutom händer i många fall något ännu mer frustrerande: du försöker göra vad alla guider rekommenderar (kontrollera visningsprogrammet, öppna minidumpen, använd en automatisk analysator...) och du upptäcker att Windows har inte ens kunnat skapa dumpfilenDen oväntade avstängningen visas i Loggboken, ja, men nästa post säger att "skapandet av dumpfilen misslyckades". Vad gör man då? Är detta ett allvarligt systemfel, eller letar du på fel ställe?

Vad exakt är en blåskärm (BSOD) i Windows 11?

En blåskärm eller BSOD (Blue Screen of Death) är i huvudsak Windows försvarsmekanism aktiveras när ett kritiskt fel upptäcks som inte kan återställas utan att riskera datakorruption.När detta händer stoppar systemet allt, visar en blå skärm och tvingar fram en omstart för att skydda systemets och hårdvarans integritet.

I Windows 10 och Windows 11 visas vanligtvis meddelandet något i stil med "Din dator stötte på ett problem och behöver startas om", tillsammans med en felkod i text (som CRITICAL_PROCESS_DIED) och ibland en STOP-kod i hexadecimalt formatDen informationen, även om den kan verka som nonsens, är nyckeln till att veta om vi pratar om ett drivrutinsfel, ett hårdvarufel, ett minnesfel, ett diskfel eller en Windows-bugg eller en nyligen genomförd uppdatering.

De vanligaste orsakerna till dessa skärmar är ganska välkända: Felaktig hårdvara (RAM, CPU, SSD/HDD), gamla eller dåligt skrivna drivrutiner, inkompatibel programvara, skadlig kod och skadade systemfilerFysiska faktorer som överhettning eller problem med strömförsörjningen spelar också in, vilket i slutändan manifesterar sig som hårdvarufel (till exempel WHEA_UNCORRECTABLE_ERROR eller MACHINE_CHECK_EXCEPTION).

På senare tid har det till och med förekommit skärmdumpar orsakade av felaktiga Windows 11-patcharTill exempel har vissa kumulativa uppdateringar genererat BSOD:er med koder som KERNEL_SECURITY_CHECK_FAILURE vid intensiv användning av GPU:n, eller brutit Wi-Fi-anslutningen på vissa datorer tills Microsoft släppte en annan korrigerande uppdatering.

Vad är en STOP-kod och vilken information innehåller den?

STOP-koden är den numeriska identifieraren för det kritiska fel som har tvingat Windows att stoppa. Det visas vanligtvis i hexadecimalt format (till exempel 0x00000050 eller 0x00000124) och är associerad med ett symboliskt namn, såsom PAGE_FAULT_IN_NONPAGED_AREA eller WHEA_UNCORRECTABLE_ERROR.

Det symboliska namnet är det som Microsoft använder i sin dokumentation. Till exempel, DRIVER_POWER_STATE_FAILURE motsvarar kod 0x0000009FOm du öppnar en dumpfil med WinDbg-felsökaren och kör kommandot !analyze -v, ser du något liknande:

BugCheck 9F, {3, ffffe000f38c06a0, fffff803c596cad0, ffffe000f46a1010}

Raden ovan visar felkontrollkoden (9F) och fyra ytterligare parametrar i klammerparenteser. Varje STOP-kod har upp till fyra parametrar som ger en mycket specifik kontext om vad som hände. (till exempel inblandade minnesadresser, typ av operation, enhetsidentifierare etc.). Microsofts officiella referens för buggkontrollkod beskriver vad varje parameter betyder för varje buggkontroll.

Det symboliska namnet (till exempel DRIVER_POWER_STATE_FAILURE) och det hexadecimala värdet (0x9F) visas tillsammans i felsökarens utdata och i dokumentationen. När du letar efter avancerad teknisk information vill du använda både namnet och koden.Däremot tenderar mer generiska guider att fokusera på namnet i texten eftersom det är mer lättläst.

Hur samlas parametrarna för en felkontrollkod in?

Om du vill gå längre än "Jag fick en blå skärm" och förstå vad som gick fel, behöver du hämta STOP-koden och dess parametrarDet finns flera sätt att uppnå detta, beroende på om du har minnesdumpar, kan koppla en felsökare eller bara har händelseloggen.

Det mest tillgängliga sättet för de flesta användare är via Loggboken. I systemloggen, Felkontrollhändelser inkluderar STOP-koden och de fyra tillhörande parametrarnaDet är inte alltid vackert eller lättläst, men informationen finns där, såvida inte skapandet av dumpfilen misslyckades eller systemet kraschade så illa att det inte ens kunde registreras korrekt.

Ett annat mer tekniskt sätt är att ladda den genererade dumpfilen (minidump eller fullständig dump) till WinDbg eller Windows felsökare och använda Kommandot !analyze, helst med alternativet -v för att se en detaljerad analysDär ser du BugCheck med dess parametrar, modulen som troligen orsakade problemet (till exempel hidusb.sys) och till och med anropsstacken vid tidpunkten för felet.

Om du har en kärnfelsökare ansluten till datorn när felet uppstår, Felkontrollen gör att systemet stoppas direkt i felsökarenI det här scenariot kanske den blå skärmen inte ens visas på skärmen; istället skickas all information till felsökningsfönstret. Du kan visa buggkontrolldata igen med kommandot `.bugcheck` eller starta om analysen med `!analyze`.

Varför misslyckas det ibland med att skapa en dumpfil?

Ett mycket vanligt klagomål är att hitta en loggpost i Loggboken som säger "Det gick inte att skapa dumpfilen på grund av ett fel under processen att skapa dumpfilen."Det här betyder inte nödvändigtvis att ditt system är oåterkalleligt trasigt, men det tyder på att något har hindrat Windows från att spara den viktiga informationen.

Orsakerna kan vara flera: brist på diskutrymme, fel i volymen där dumpen ska skrivas, skadat filsystem, minnesproblem så allvarliga att operationen inte ens kan slutföras eller felaktiga dumpinställningarDet kan också störa programvara från tredje part (aggressivt antivirusprogram, lågnivåkryptering, etc.).

I dessa fall är det ofta bra att granska de avancerade systeminställningarna i avsnittet Start och återställning för att se till att Du har aktiverat någon typ av dump (minidump, kernel eller full) och sökvägen för att spara är giltigDessutom är det lämpligt att kontrollera att systemenheten inte är full och att filsystemet är fritt från fel (med hjälp av verktyg som CHKDSK).

Om det fortfarande misslyckas beror det inte på att du ser det fel: Ert team har helt enkelt inte lyckats "logga" felet i form av en dumpfil.I dessa fall måste du förlita dig mer på Loggboken, hårdvarutestning och kontextanalys (vad du gjorde, vad som nyligen uppdaterats osv.).

Läsa felsökningsinformation med WinDbg

För de som vill komma till botten med detta är nyckelverktyget WinDbg. När du laddar en kerneldump och kör !analyze -v, felsökaren visar en detaljerad beskrivning av felet, inklusive buggkontrollen, parametrar, anropsstack och misstänkt modul.

Till exempel kan du se något i stil med felet "Troligen orsakat av: hidusb.sys”, vilket pekar på ett problem med USB HID-styrenheten (möss, tangentbord, etc.). Därifrån kan du fördjupa dig, sätta brytpunkter i relevant kod, gå vidare steg för steg och kontrollera exakt var i kontrollenheten överträdelsen inträffar.

Om du har möjlighet att ansluta en felsökare till systemet med ihållande problem är kärnfelsökning särskilt användbart för återkommande eller mycket komplexa felSärskilt när andra diagnostiska tekniker har nått sin gräns. Det är dock alltid lämpligt att anteckna exakt vilken text som visas på blåskärmsmeddelandet och de specifika åtgärder som leder till problemet så att det kan reproduceras på ett kontrollerat sätt.

Microsoft erbjuder specifik dokumentation om hur man analyserar minnesdumpar (både i kernelläge och användarläge) och hur man använder felsökningstilläggen på djupet, i synnerhet Analysera och dess alternativFör utvecklare och avancerad supportpersonal gör detta att de kan skilja på om felet faktiskt ligger i deras egen kod eller i en annan komponent i systemet.

Vanliga BSOD:er i Windows 11 och vad de vanligtvis betyder

Det finns en uppsättning blåskärmsfel som förekommer ganska ofta i Windows 10 och Windows 11. Att känna igen dem med en snabb blick hjälper till att prioritera var man ska börja leta. Några av de vanligaste är:

• PAGE_FAULT_IN_NONPAGED_AREA (0x00000050)Windows har försökt komma åt en minnessida som inte finns eller för närvarande är oåtkomlig. Detta indikerar vanligtvis felaktigt RAM-minne eller en skadad NTFS-volym.
• IRQL_NOT_LESS_OR_EQUAL (0x0000000A)En kärnlägeskontroller har försökt komma åt sidbart minne när den inte borde ha gjort det (IRQL för hög). Detta är mycket typiskt för felaktiga drivrutiner eller trasig hårdvara.
• SYSTEM_SERVICE_EXCEPTION (0x0000003B)En systemtjänst, vanligtvis en drivrutin eller en kritisk process, har genererat ett ohanterat undantag. Detta är ofta relaterat till inkompatibla drivrutiner eller programvara som stör kärnan för mycket.
• DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1)En styrenhet har försökt att komma åt en ogiltig minnesadress med hög prioritetsnivå. Återigen, nästan säkert en problematisk förare.
• KRITISK_PROCESS_AVLÄNGD (0x000000EF)En viktig systemprocess har avslutats oväntat. Detta kan orsakas av skadade systemfiler, skadlig programvara eller Windows-fel.
• MINNESHANTERING (0x0000001A)Detta indikerar inkonsekvenser i minneshanteringen. Dessa orsakas vanligtvis av felaktiga RAM-moduler, hårdvarufel eller djupgående systemkorruption.
• SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x0000007E)starkt associerad med gamla eller inkompatibla kontrollanter som genererar ohanterade undantag.
• OÅTKOMLIG_STARTENHET (0x0000007B)Windows kan inte komma åt startpartitionen. Detta kan bero på ändringar i SATA-konfigurationen (RAID/AHCI), saknade lagringskontroller eller skadade startfiler.
• AVMONTERINGSVOLYM_FÖR_START (0x000000ED)Systemet kan inte montera startenheten korrekt, ofta under uppstart. Återigen, problem med disk eller filsystem.
• DPC_WATCHDOG_VIOLATION (0x00000133): vanligtvis kopplat till drivrutiner som blockerar systemet för länge (timeouts som överskridits i DPC-köer).
• WHEA_UNCORRECTABLE_ERROR (0x00000124) y MACHINE_CHECK_EXCEPTION (0x0000009C)fel som är nära relaterade till hårdvarufel (CPU, RAM, moderkort, strömförsörjning) eller allvarliga temperatur- eller spänningsproblem.

Var och en av dessa fel har sin egen post i Microsofts dokumentation, med teknisk förklaring, parametrarnas betydelse och specifika rekommendationerOm din STOP-kod matchar någon av dessa är det värt att kontrollera den officiella referensen för att förfina diagnosen.

Mindre frekventa BSOD-koder och typiska riktlinjer

Utöver vanliga buggkontroller samlar många tillverkare (Huawei, Dell och andra) in interna data Listor över mindre vanliga koder med snabba rekommendationer för deras tekniska support. Även om de är utformade för sitt ekosystem, ger de en uppfattning om den allmänna riktning de vanligtvis tar:

Fel som t.ex MANUALLY_INITIATED_POWER_BUTTON_HOLD eller NMI_HARDWARE_FAILURE Dessa fel uppstår bara om systemet är konfigurerat att visa en blå skärm när strömbrytaren hålls nedtryckt under en viss tid. Även om avtryckaren är "manuell" kan det faktum att den utlöses tyda på ett hårdvaruproblem som tvingar användaren att stänga av datorn på detta sätt.

Andra, som CPFN_REFERENCE_COUNT, FAST_ERESOURCE_PRECONDITION_VIOLATION eller INVALID_KERNEL_STACK_ADDRESSDessa problem beror vanligtvis på interna Windows-fel som sällan återkommer. I dessa fall är det typiska rådet att starta om systemet, uppdatera patchar och, om problemet kvarstår, kontakta teknisk support eftersom det kan finnas djupgående korruption eller ett fel i själva systemet.

Det finns också många koder som nästan alltid är förknippade med tredjepartsprogram eller drivrutinerTill exempel QUOTA_UNDERFLOW, PROCESS_HAS_LOCKED_PAGES, BUGCODE_NDIS_DRIVER (nätverk), BUGCODE_USB3_DRIVER (USB 3.0), DRIVER_OVERRAN_STACK_BUFFER eller FSRTL_EXTRA_CREATE_PARAMETER_VIOLATION. I praktiken är rekommendationen vanligtvis att kontrollera vilka program eller drivrutiner som nyligen har installerats, särskilt PC-hanterare, antivirusprogram eller "mirakel"-optimeringsverktyg, och avinstallera dem för att se om problemet försvinner.

Det finns koder som är direkt relaterade till filsystemet, till exempel FAT_FILE_SYSTEM, UDFS_FILE_SYSTEM, EXFAT_FILE_SYSTEM eller FLTMGR_FILE_SYSTEMNär dessa fel uppstår upprepade gånger tyder de på dåligt partitionerade enheter, okonventionella systeminstallationer, felaktiga diskar eller filterdrivrutiner som stör diskåtkomsten. I många fall rekommenderar tillverkare att man återställer fabriksinställningarna eller installerar om Windows om problemet kvarstår efter att filsystemet har uppdaterats och reparerats.

Andra koder är kopplade till CPU-, minnes- eller hypervisorfelTill exempel MACHINE_CHECK_EXCEPTION, WHEA_INTERNAL_ERROR, HYPERVISOR_ERROR eller STORE_DATA_STRUCTURE_CORRUPTION. Dessa fel indikerar nästan alltid hårdvaruproblem eller problem med avancerade virtualiseringskonfigurationer, och den vanliga lösningen är att förlita sig på garantianspråk eller avancerad fysisk diagnostik.

När problemet härrör från Windows 11-uppdateringar

Inte alla BSOD:er orsakas av din hårdvara eller programvaran du har installerat. Ibland är de Windows-uppdateringar introducerar själva regressionerNyligen har fall dokumenterats där kumulativa patchar för Windows 11 har orsakat KERNEL_SECURITY_CHECK_FAILURE-skärmar på datorer med vissa grafikkort, samt Wi-Fi-anslutningsfel.

I sådana fall erkänner Microsoft vanligtvis problemet offentligt och publicera en korrigerande uppdateringTill exempel kan en felaktig kumulativ uppdatering vara KB5074105, och uppdateringen som åtgärdar buggarna kan vara KB5077181. Den senare distribueras via Windows Update och lanseras gradvis.

Om du börjar se blå skärmar efter att du har installerat en specifik uppdatering och allt fungerade bra tidigare är det en bra idé att kontrollera din Windows Update-historik och Kontrollera om din KB-artikel är kopplad till några kända problem i Microsofts dokumentation.Medan du väntar på patchen kan du avinstallera den motstridiga uppdateringen eller tillfälligt pausa automatiska uppdateringar, även om detta alltid innebär en viss säkerhetsrisk.

I vilket fall som helst, förutom att installera patchen som åtgärdar problemet, är det lämpligt att hålla resten av systemet uppdaterat: Uppdaterade drivrutiner för BIOS/UEFI, chipset, grafik, nätverk och lagring i senare versionersärskilt om din utrustningstillverkare tillhandahåller sina egna verktyg (SupportAssist, PC Manager, etc.).

Verktyg och tekniker för att undersöka en BSOD på djupet

Utöver det generiska rådet "uppdatera allt och starta om" finns det flera kraftfulla verktyg utformade just för detta ändamål. Diagnostisera grundorsaken till en blå skärmäven när dumpar inte har genererats på ett tillförlitligt sätt.

Å ena sidan finns Loggboken, som vi redan nämnt. Genom att navigera till Windows-loggar > System kan du filtrera efter kritiska fel som inträffade runt tidpunkten för BSOD:n. Även om dumpen misslyckas, finns det vanligtvis kvar information om den oväntade avstängningen och försöket att skapa dumpen., med lite användbar data (felkod, modul, etc.).

Minidump-filerna är också mycket värdefulla, de små filer som Windows skapar i C:\Windows\Minidump när det lyckas slutföra åtminstone en delvis dump. De innehåller kondenserad information om systemets status vid tidpunkten för felet. och kan öppnas med WinDbg eller andra verktyg för att identifiera den berörda drivrutinen eller modulen.

Om systemet startar finns det ett annat alternativ att använda Driver VerifierEtt inbyggt Windows-verktyg som utsätter drivrutiner för ett slags realtids-"stresstest". Det validerar deras beteende med minne, IRQL:er, köer och så vidare. När det upptäcker felaktig användning kan det tvinga fram en proaktiv buggkontroll för att tydligt identifiera vilken drivrutin som beter sig fel. Det lägger dock till en del omkostnad, så du måste noggrant välja vilka drivrutiner som ska kontrolleras för att undvika att datorn blir alltför långsam.

Dessutom kan du förlita dig på andra avancerade verktyg, till exempel paketet med Sysinternals-verktyg och nätverksmonitorerDessa hjälper till att isolera problem som i slutändan kan leda till en blå skärm (extrem minnesläckage, drivrutiner som inte svarar, frysta tjänster etc.). Tillsammans med händelseloggen och dumpfilerna låter de dig skapa en ganska komplett bild av vad som händer.

Specifika råd för utvecklare och tredjepartsprogramvara

Om du utvecklar drivrutiner eller programvara som stör kärnan kommer du förr eller senare att stöta på en blåskärmsfel orsakad av din egen kod. I så fall fungerar det inte att bara "installera om Windows". Det är dags att felsöka och åtgärda problemetFör att göra detta är den mest effektiva metoden att använda kärnfelsökning med WinDbg, reproducera felet i en kontrollerad miljö, analysera buggkontrollen och studera anropsstacken och IRQL:erna vid tidpunkten för kraschen.

När buggkontrollen inte beror på din kod, utan din applikation påverkas, ändras målet: Du kommer inte att kunna åtgärda grundorsaken, men du kan försöka förhindra att din programvara utlöser den.Detta innebär ofta att implementera ytterligare kontroller, bättre hantering av fel från andra komponenter, minska aggressiva beroenden av tredjepartsdrivrutiner eller undvika riskfyllda metoder som förlitar sig alltför mycket på odokumenterat beteende.

I vilket fall som helst är det viktigt att föra noggranna anteckningar. de exakta handlingarna som leder till skärmdumpen, de koder som visas och hur ofta den reproducerasMed den informationen är det mycket enklare för supportteam eller Microsoft att bedöma om det är en känd bugg, felaktig hårdvara eller en konstig interaktion mellan komponenter.

Slutligen får vi inte underskatta de beprövade "grundlösningarna": Granska manualer, installera om viktiga komponenter, kontrollera fildatum, avinstallera påträngande antivirusprogram eller PC-hanterare och verifiera nätverks-, USB- eller lagringsdrivrutiner.En stor andel av BSOD:er kopplade till programvara från tredje part löses genom att den problematiska komponenten tas bort.

Kort sagt, att tolka BSOD-koder i Windows 11 handlar inte bara om att se ett nummer på den blå skärmen: det handlar om att kombinera den koden och dess parametrar med ledtrådar från händelsevisaren, minnesdumpar, hårdvarustatus och senaste systemändringar. När allt det sammanhanget samlas – och du förstår vad varje buggkontroll betyder – slutar det att vara en "mystisk" skärmdump och blir ett mycket konkret verktyg för att ta reda på vad som felar, oavsett om det är felet på en drivrutin, hårdvaran, en uppdatering eller till och med din egen kod.och avgöra om det räcker med att uppdatera, avinstallera något, reparera Windows, eller om det är dags att tänka på fysisk diagnos och specialiserad teknisk service.