Blåskärm (BSOD) i Windows 11: stoppkoder, minidump-analys och helpdesk-runbook 2026

Uppdaterad: 9 juli 2026

En blåskärm (Blue Screen of Death, BSOD) i Windows 11 är ett kontrollerat kraschstopp där kärnan upptäcker ett fel den inte kan återhämta sig från, oftast en trasig drivrutin, defekt RAM eller ett skadat system­filsystem, och skriver ut en stoppkod plus en minidump innan datorn startar om. För helpdesk är det stoppkoden och minidump-filen som gör skillnad mellan en biljett som stängs på tio minuter och en som studsar mellan nivå 1 och nivå 3 i två veckor. Den här runbooken visar hur du läser signalerna, kör !analyze -v mot dumpen och stänger ärendet med bevis, inte gissningar.

• Windows 11 skriver alltid en minidump till C:\Windows\Minidump när "Automatic memory dump" är aktivt. Se till att den inställningen är på innan du börjar felsöka på riktigt.
• Stoppkoden är den snabbaste ledtråden: DRIVER_IRQL_NOT_LESS_OR_EQUAL pekar nästan alltid på en drivrutin, WHEA_UNCORRECTABLE_ERROR pekar på fysisk hårdvara, och MEMORY_MANAGEMENT kan vara båda.
• WinDbg med kommandot !analyze -v och symbolstigen srv*https://msdl.microsoft.com/download/symbols ger en färdig hypotes på under en minut per dump.
• Byter stoppkoden mellan varje krasch (IRQL ena dagen, PAGE_FAULT nästa), misstänk RAM eller överklockning (inklusive Intel XMP och AMD EXPO) före drivrutin.
• Driver Verifier tvingar en misstänkt drivrutin att krascha snabbare och tydligare, men aktivera den bara med en återställningsplan.
• En strukturerad blåskärms-runbook (samla dump, notera stoppkod, klassificera, eskalera) halverar handläggningstiden i mina team.

Vad är en blåskärm och vad utlöser den?

Ärligt talat är blåskärmen egentligen ingen felmeddelande-skärm. Den är ett kontrollerat nödstopp. När Windows-kärnan upptäcker att någon (en drivrutin, en hårdvarukomponent eller en kärnprocess) precis har gjort något som skulle skada datat om systemet fortsatte att köra, väljer den att halta allt och skriva ut en bug check. Poängen är att skydda diskdata, inte att vara elak mot användaren. Det är också därför en dator som blåskärmar under ett Word-dokument nästan aldrig är Words fel.

De fem grundorsaker jag ser i mina biljettköer, i den ordning de faktiskt förekommer, är: en tredjeparts­drivrutin som skriver på fel minnesadress (vanligast), defekt RAM (näst vanligast, och undervärderat), en Windows-uppdatering som krockar med en befintlig drivrutin, en döende SSD eller kabel som ger CRC-fel på lässidan, och överhettning under last. Skadeprogram förekommer men är ovanligt jämfört med de andra fyra. Jag har haft ett enda fall på fem år där en rootkit var den verkliga orsaken.

Ett användarbeteende jag ser om och om igen är att biljetten kommer in som "min dator fryser slumpmässigt". Om användaren har "Restart automatically" påslaget så ser hen aldrig blåskärmen, bara att burken plötsligt startar om. Första frågan i telefon bör därför alltid vara: "Ser du en blå skärm med en QR-kod, eller startar den bara om?" Svaret dirigerar dig till helt olika delar av den här guiden.

Vanligaste stoppkoderna i Windows 11 2026

Stoppkoden är den enda enskilda ledtråden som är värd att skriva av från skärmen. Den finns i alla minidumps också, men om användaren kan läsa den i telefonen slipper du be dem starta om två gånger för att komma åt filen. Nedan är den tabell mina level 1-agenter har uppfäst intill sina skärmar. Om koden inte är i tabellen, anteckna den och gå direkt till minidump-analysen.

Stoppkod	Hex	Trolig orsak	Första åtgärd
DRIVER_IRQL_NOT_LESS_OR_EQUAL	0x000000D1	Drivrutin skriver till minne på fel IRQL, nästan alltid nätverks-, grafik- eller VPN-drivrutin	Boota till felsäkert läge, rulla tillbaka senast uppdaterade drivrutin
IRQL_NOT_LESS_OR_EQUAL	0x0000000A	Kärnkomponent träffar minne den inte får, drivrutin eller RAM	Analysera minidump med WinDbg, testa RAM om koden är sporadisk
DPC_WATCHDOG_VIOLATION	0x00000133	DPC-tidsvakt löste ut, ofta gammal SSD-firmware eller trasig NVMe-drivrutin	Uppdatera SSD-firmware, kontrollera Intel RST/AMD Storage-drivrutin
SYSTEM_SERVICE_EXCEPTION	0x0000003B	Systemtjänst kraschar mot drivrutin eller minne, win32kfull.sys-varianten var vanlig efter maj-2026-uppdateringen	Kontrollera senaste Windows-uppdatering, uppdatera GPU-drivrutin
PAGE_FAULT_IN_NONPAGED_AREA	0x00000050	Åtkomst till minnessida som inte finns, drivrutin eller trasig RAM	Windows Memory Diagnostic, sedan minidump-analys
MEMORY_MANAGEMENT	0x0000001A	Minnesförvaltaren hittade korrupt sidtabell, RAM, pagefil eller drivrutin	MemTest86 över natten, kontrollera XMP/EXPO-profil
VIDEO_TDR_FAILURE	0x00000116	GPU svarade inte i tid, drivrutin, temperatur eller trasigt kort	DDU + färsk GPU-drivrutin, kontrollera temperaturer
INACCESSIBLE_BOOT_DEVICE	0x0000007B	Windows hittar inte bootenheten, lagrings­drivrutin, BIOS-läge eller trasig SSD	Kontrollera SATA/NVMe-läge i BIOS, boota WinRE och kör chkdsk /f /r
CRITICAL_PROCESS_DIED	0x000000EF	En kritisk Windows-process dog, ofta korrupta systemfiler	Boota WinRE, kör sfc /scannow och DISM /RestoreHealth
WHEA_UNCORRECTABLE_ERROR	0x00000124	Hårdvarufel som CPU eller chipset rapporterade, nästan alltid fysiskt	Ta bort överklockning, kör CPU-stresstest, förbered hårdvaruservice

En sak jag har lärt mig att alltid kolla när jag ser en SYSTEM_SERVICE_EXCEPTION i mina biljetter: startade det efter en kumulativ uppdatering? Efter maj-2026-uppdateringen fick vi en våg av kraschar med modul­namnet win32kfull.sys, mest under Chrome med många flikar. Det var en känd Microsoft-bugg som togs bort i följande cumulative rollup. Innan du eskalerar en biljett till hårdvara, kolla alltid Windows Update-felkoderna och kända problem i den byggen användaren kör.

Snabb triage: de första tio minuterna

Level 1 ska aldrig behöva öppna WinDbg. Deras uppgift är att bestämma om ärendet ska stanna hos dem eller eskaleras till en tekniker som gör dumpanalys. Här är den checklista jag ger nya agenter. Vi kallar den internt "T10", Triage på tio minuter.

1. Bekräfta att det är en riktig BSOD. Fråga användaren: blå skärm med QR-kod eller sur smiley? Bara omstart utan skärm betyder att auto-omstart är på och att du inte har någon symptombild ännu. Se punkt 6.
2. Notera stoppkoden och eventuell modul. "SYSTEM_SERVICE_EXCEPTION (win32kfull.sys)" är oändligt mycket mer värt än "något med system".
3. Fråga efter mönstret. Vid start, vid nedstängning, under Teams-samtal, vid dockning? Ett tydligt utlösande mönster är halva diagnosen. Anteckna i biljetten ordagrant.
4. Senaste ändringen. "Vad hände nytt igår?" Ny drivrutin, ny extern skärm, ny USB-dockning, kumulativ Windows-uppdatering, ny VPN-klient. 70 % av mina blåskärmar korrelerar med en ändring inom 72 timmar.
5. Kontrollera händelseloggen. Öppna Event Viewer, filtrera på System och Critical/Error runt kraschtiden. Kernel-Power Event 41 bekräftar oplanerad omstart. Bugcheck-eventet (ID 1001) upprepar stoppkoden.
6. Se till att auto-omstart är av och att minidumps skrivs. Utan detta kan du inte samla in bevis vid nästa krasch. Se nästa avsnitt.

Så hittar och samlar du in minidump-filer

Minidumps är små (256 kB), lätta att skicka via e-post och räcker till 95 % av all analys du kommer göra på nivå 2. Full MEMORY.DMP är sällan värt filstorleken om du inte jagar ett kernel pool-läckage. Standardplatsen är C:\Windows\Minidump och Windows 11 skapar filnamn på formen MMDDYY-XXXXX-01.dmp.

Innan du kan samla en dump från nästa krasch måste inställningen vara aktiverad. Öppna Kör, skriv sysdm.cpl, gå till fliken Avancerat, klicka Start och återställning. Sätt Skriv felsökningsinformation till "Automatic memory dump", avmarkera "Starta om automatiskt" och verifiera att dumpmappen är %SystemRoot%\Minidump.

Vill du göra detta över hela flottan för en användargrupp är PowerShell snabbare. Skriptet nedan slår på minidump-generering, stänger av auto-omstart och verifierar mappen. Kör det över Intune Remediation eller din befintliga endpoint management-lösning:

# Aktivera minidumps + inaktivera auto-omstart för BSOD-triage.
# CrashDumpEnabled: 7 = Automatic memory dump (Windows 10/11 default)
# AutoReboot: 0 = låt blåskärmen stå kvar

$key = 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl'
Set-ItemProperty -Path $key -Name CrashDumpEnabled -Value 7 -Type DWord
Set-ItemProperty -Path $key -Name AutoReboot        -Value 0 -Type DWord
Set-ItemProperty -Path $key -Name MinidumpDir       -Value '%SystemRoot%\Minidump' -Type ExpandString
Set-ItemProperty -Path $key -Name DumpFile          -Value '%SystemRoot%\MEMORY.DMP' -Type ExpandString

# Skapa katalogen om den saknas och rapportera senaste dumpen
$dir = "$env:SystemRoot\Minidump"
if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir | Out-Null }

Get-ChildItem $dir -Filter *.dmp -ErrorAction SilentlyContinue |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 3 Name, Length, LastWriteTime

När användaren har fått en ny krasch, be dem paketera hela Minidump-mappen som en zip och ladda upp den till ärendet, inte klistra in filnamnet i chatten. Ett verkligt fall från förra kvartalet: agent bad om "senaste dumpen", användaren mailade en fil, och det visade sig vara en gammal dump från januari som pekade på en drivrutin som redan uppdaterats. Bit av hela mappen alltid.

Analysera en minidump med WinDbg

Så, WinDbg är gratis och installeras enklast från Microsoft Store. Sök efter "WinDbg" så får du "WinDbg" (den moderna versionen som förr hette WinDbg Preview). Ingen SDK-installation behövs för dumpanalys. Enligt Microsofts officiella dokumentation för Windows debugging tools stödjer den både Windows 11 och äldre kernel-dumps.

Det första du måste göra efter installation är att peka WinDbg mot Microsofts offentliga symbol­server. Öppna Settings, sedan Debugging settings, och till sist Default Symbol Path. Klistra in:

srv*C:\SymCache*https://msdl.microsoft.com/download/symbols

Detta cachar symbolerna lokalt i C:\SymCache så andra körningen går snabbt. Utan denna sökväg blir !analyze -v gissningar snarare än analys.

Nu det praktiska: öppna File, välj Open dump file, peka på .dmp-filen och vänta tills prompten visar kd>. Kör:

!analyze -v

Vad du letar efter i utdata, i den ordning det spelar roll:

• BUGCHECK_CODE. Hexkoden. Matcha mot tabellen ovan.
• MODULE_NAME och IMAGE_NAME. Filnamnet på den drivrutin eller kärnkomponent WinDbg misstänker. nvlddmkm.sys = NVIDIA-grafik, ndis.sys = nätverksstack, ntoskrnl.exe = Windows-kärnan själv (vanligast tecken på RAM-fel).
• FAILURE_BUCKET_ID. Microsofts interna kategori. Googla den ordagrant, den ger ofta träff på KB-artiklar.
• STACK_TEXT. Anropsstacken. Läs den nedifrån och upp. Botten är där kraschen började.

En viktig sanningssägning: MODULE_NAME pekar på var kraschen manifesterade sig, inte alltid var buggen bor. En trasig nätverks­drivrutin kan skriva över minne som senare läses av kärnan, och då blir ntoskrnl "skyldig". Om !analyze -v säger att kärnan gjorde fel, misstänk RAM eller överklockning innan du börjar reinstallera Windows. Enligt Microsofts felsökningsguide för stoppkodsfel är dumpanalys evidence-based diagnostik, inte facit.

BlueScreenView för snabb triage utan WinDbg

WinDbg är kraftfullt men kräver att man vet vad man tittar på. För Level 1-agenter som bara behöver identifiera vilken .sys-fil som är misstänkt fungerar NirSofts gratisverktyg BlueScreenView utmärkt. Det läser alla dumps i C:\Windows\Minidump, listar dem i övre halvan och färgar de moduler som fanns i stacken när kraschen inträffade i undre halvan. Rödmarkerade moduler är de mest sannolika misstänkta.

Använd BlueScreenView när: du har fler än tre dumps att sortera igenom snabbt, användaren själv ska förstå vad felet är, eller du vill se om samma .sys-fil dyker upp i flera kraschar (starkt tecken på en enda drivrutinsbugg snarare än hårdvara). Gå till WinDbg när: BlueScreenView pekar på ntoskrnl.exe och du behöver stackspåret för att komma vidare, eller när du ska lämna över ett ärende till Microsoft support och behöver !analyze -v-utdatan i biljetten.

Jag rekommenderar inte att köra båda samtidigt på samma dump. Är dumpen väldigt liten kan de låsa filen mot varandra och du får läs­fel. Kopiera först dumpen till en arbetsmapp utanför Minidump.

Isolera drivrutinsfel med Driver Verifier

Ibland ser du en DRIVER_IRQL_NOT_LESS_OR_EQUAL med MODULE_NAME: nvlddmkm.sys, uppdaterar grafik­drivrutinen, och kraschen kommer tillbaka två dagar senare med samma text. Det brukar betyda att kraschen är en följdverkan; en annan drivrutin skriver på fel adress och NVIDIA:s drivrutin är bara den som råkar upptäcka det. Här är Driver Verifier oumbärlig.

Driver Verifier tvingar utvalda drivrutiner genom extra sanity checks och kommer krascha maskinen medvetet, snabbare och med bättre modul­namn i dumpen, om drivrutinen bryter mot reglerna. Aktivera den så här:

# Kör som administratör. Öppnar Driver Verifier Manager i GUI-läge.
verifier

# Alternativt via kommandorad: verifiera alla drivrutiner utom Microsoft-signerade,
# vilket brukar räcka för att hitta tredjepartsdrivrutinen som stökar:
verifier /standard /all /volatile

I GUI: välj "Create standard settings", sedan "Automatically select unsigned drivers" eller "Automatically select all drivers not shipped with Microsoft Windows". Starta om. Får du en BSOD inom några timmar med en tydlig drivrutin i MODULE_NAME, det är boven.

Hårdvarutest: RAM, disk och överhettning

Om stoppkoden byter mellan varje krasch (IRQL ena dagen, PAGE_FAULT nästa, MEMORY_MANAGEMENT tredje) och WinDbg pekar på olika moduler varje gång, är det nästan aldrig drivrutin. Det är hårdvara som producerar felaktig data i olika minnesceller vid olika tillfällen. Innan du eskalerar biljetten till fältservice ska du bevisa det.

RAM-test. Windows Memory Diagnostic är den snabba första kollen. Öppna Start, sök "Windows Memory Diagnostic", välj "Restart now and check". Basic-testet tar 10–15 minuter, Extended (välj F1 under körning) tar 1–2 timmar och fångar subtila fel. Slår du i noll fel men blåskärmarna fortsätter, kör MemTest86 från USB-stick och låt den köra minst en full sweep över natten. Om XMP/EXPO-profil är aktiverad i BIOS: stäng av den och kör om testet. Enligt Microsofts referens för att läsa små minnesdumpar är RAM och överklockning tillsammans den enskilt vanligaste orsaken till sporadiska stoppkoder.

Disktest. En SSD som börjar dö producerar DPC_WATCHDOG_VIOLATION och INACCESSIBLE_BOOT_DEVICE. Kör:

chkdsk C: /f /r /x
# Verifiera SMART-status:
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus

Är HealthStatus "Warning" eller "Unhealthy" är det dags att byta disk oavsett vad SMART-detaljerna säger. Kontrollera också om NVMe- eller Intel Rapid Storage-drivrutinen är från 2022 medan Windows är på 24H2. Inkompatibla lagringsdrivrutiner är en tyst dödare av Windows 11-installationer.

Överhettning. BSOD som bara händer under Teams-samtal med video, gaming eller stora Excel-omberäkningar är ofta värmerelaterade. Kör HWMonitor eller Core Temp under användarens normala arbetsdag i en timme och läs av max-temperaturer. Över 90 °C på CPU eller GPU är i praktiken en tidsfråga innan WHEA_UNCORRECTABLE_ERROR eller VIDEO_TDR_FAILURE dyker upp. På bärbara datorer är det oftast damm i fläkten; på stationära är det åldrande värmepasta. Nätverksrelaterade BSOD:er efter RDP-anslutningar över VPN pekar däremot nästan alltid på nätverksdrivrutinen, inte temperatur.

Runbook och biljetthygien för BSOD-ärenden

En blåskärms­biljett som saknar stoppkod, minidump och senaste-ändring-noteringen kommer att studsa mellan tekniker i två veckor. Efter att vi införde nedanstående runbook föll vår median­tid-till-lösning från 6,3 arbetsdagar till 2,1 för Windows-relaterade kraschbiljetter. Modellen är enkel: ingen eskalering utan artefakter.

1. Level 1 samlar in. Stoppkod, mönster, senaste ändring, hela Minidump-mappen som zip. Öppnar aldrig WinDbg. Anteckningar i biljetten enligt mall, inklusive "Auto restart avaktiverad: ja/nej".
2. Level 2 analyserar. Kör !analyze -v mot alla insamlade dumps, dokumenterar MODULE_NAME och FAILURE_BUCKET_ID per krasch. Klipper in utdatan i biljetten som kommentar. Avgör om det är: (a) uppdatera drivrutin, (b) återställ Windows-uppdatering, (c) misstänk hårdvara, (d) okänt, kör Driver Verifier.
3. Level 3 eskalerar externt. Vid misstänkt hårdvara: beställ hårdvarudiagnostik hos leverantören med !analyze -v-utdatan bifogad. Vid oidentifierad kernel-bugg: öppna Premier-ärende hos Microsoft med minidump.
4. Stäng med rot­orsak, inte "löst". "Ersatte DIMM slot A2 efter MEMORY_MANAGEMENT bekräftad av MemTest86" är en användbar biljett­historik. "Fungerar nu" är det inte.

Ett verkligt exempel som fastnat hos mig: en användare hade sex blåskärmar på tre veckor, alla klassade som "olöst, omstart hjälpte". När jag gick tillbaka och läste dumperna hade fem av dem MEMORY_MANAGEMENT med olika stackspår varje gång. En femton minuters MemTest86-körning på fysisk plats visade en trasig DIMM. Biljetten hade dragit ut på tiden i en månad för att ingen krävde in dumpen. Runbooken finns för att sådant inte ska hända.

Vanliga frågor

Var hittar jag minidump-filen i Windows 11?

Minidumps ligger i C:\Windows\Minidump med filnamn på formen MMDDYY-XXXXX-01.dmp. Om mappen är tom eller saknas är "Automatic memory dump" inte aktiverat. Slå på det via sysdm.cpl, Avancerat, Start och återställning, eller genom registret via PowerShell-skriptet ovan.

Vad betyder SYSTEM_SERVICE_EXCEPTION i Windows 11?

Stoppkoden pekar på ett fel i hur en systemtjänst interagerar med en drivrutin eller minnesregion, ofta med en .sys-modul i felmeddelandet. I Windows 11 2026 är den vanligaste roten en trasig grafik- eller nätverks­drivrutin. Efter maj-2026-uppdateringen sågs också en känd bugg med win32kfull.sys som Microsoft fixade i följande cumulative rollup.

Hur startar jag Windows 11 i felsäkert läge om datorn kraschar innan inloggning?

Håll ner strömknappen tre gånger under uppstart för att tvinga Windows in i återställningsmiljön (WinRE). Välj Felsök, Avancerade alternativ, Startinställningar, Starta om, och tryck sedan 4 (felsäkert läge) eller 5 (felsäkert läge med nätverk). Om felsäkert läge fungerar utan krasch är felet nästan säkert en tredjeparts­drivrutin eller programvara.

Är blåskärm alltid ett hårdvarufel?

Nej. I mina biljettköer är drivrutinsfel den enskilt vanligaste orsaken (uppskattningsvis 55–60 %), följt av korrupta systemfiler eller misslyckade Windows-uppdateringar. Hårdvara (RAM, disk, överhettning) står för resten. Byter stoppkoden mellan varje krasch är misstanke om hårdvara berättigad; är stoppkoden och modulen samma varje gång är det nästan alltid programvara.

Hur läser jag !analyze -v-utdata från WinDbg?

Fokusera på fyra fält: BUGCHECK_CODE (stoppkoden), MODULE_NAME (misstänkt drivrutin), FAILURE_BUCKET_ID (Microsofts kategori, sökbar mot KB-artiklar) och STACK_TEXT (anropsstacken, läses nedifrån och upp). Kom ihåg att MODULE_NAME pekar på var kraschen manifesterade sig, inte alltid var buggen bor. Vid ntoskrnl.exe misstänk RAM eller överklockning först.

Kan Driver Verifier skada datorn?

Driver Verifier kraschar datorn medvetet (det är hela poängen) och kan orsaka en boot-loop om en verifierad drivrutin laddas tidigt i uppstarten. Skador på hårdvaran är extremt osannolikt, men risken att sätta datorn i ett oanvändbart tillstånd är verklig. Aktivera aldrig utan att veta hur du når WinRE och kör verifier /reset från en admin-kommandopromt.