Om den så kallade blue screen of death i Windows 10 dyker upp framför dig och du är redo att hamna i en nervös koma, ta dig samman och försök lösa problemet. Till att börja med är det värt att säga att detta olycksbådande meddelande signalerar dig om en kritisk systemfel. Dessutom är det inte alltid möjligt att fånga ögonblicket och hinna läsa felkoden när Windows faller in i dödens blå skärm och enheten startar om. Låt oss omedelbart notera att det finns ett stort antal lösningar på detta problem, såväl som orsakerna till utseendet blå skärm. I den här artikeln kommer vi att försöka överväga de troliga orsakerna till den blå skärm av lycka, liksom möjliga lösningar problem.
I de allra flesta fall signalerar den blå skärmen av döden felet BAD_POOL_CALLER - stopp 0x000000c2. För att uttrycka det rakt på sak är det svårt att diagnostisera detta fel, men vi kanske kommer att försöka använda det här felet som ett exempel för att beskriva algoritmen för dina nästa åtgärder.
För att korrekt diagnostisera problemet bör du först analysera en speciell systemfil som heter minidump. Skapandet av sådana filer orsakas av ett systemfel. Dessutom kan de informera oss om vad som ledde till felet.
1. För att aktivera denna automatiska inspelning av en liten minnesdump (inaktiverad som standard), gå till datorns egenskaper och gå till avsnittet "Avancerade systeminställningar" (denna aktivering finns för alla system, inte bara Windows 10):
Som regel sparas alla minidumpfiler när en blå skärm av döden (BSOD) visas, och du kan hitta dem i mappen C:\Windows\Minidump. Det är anmärkningsvärt att filnamnet innehåller aktuellt datum– när den skapades, vilket gör det mycket lättare att identifiera datumet då felet inträffade, särskilt med tanke på att det kan finnas mer än en sådan fil.
Första sättet, består av att använda det ganska populära verktyget BlueScreenView. Detta verktyg kan också bli bra alternativ för att analysera minnesdumpen. Användningen av detta verktyg kommer att vara mycket praktiskt som ett sätt att identifiera den problematiska drivrutinen.
Dessutom är det särskilt anmärkningsvärt för det faktum att det med dess hjälp är möjligt att se BSOD (blue screen of death) som i en frysbild, som det var när systemet kraschade. Den visar tid och datum för felet, information om drivrutinen eller modulen med version och kort beskrivning. Dessutom finns verktyget tillgängligt på många språk, inklusive ryska. Så verktyget BlueScreenView är precis grejen om du behöver producera snabb analys minnesdumpar under BSOD.
För andra metoden du måste installera felsökningsverktyg för Windows och även ladda ner verktyget bsdos_utility. Därefter, efter att ha packat upp skriptet bsdos_utility.cmd, bör du flytta det till C:\-enheten (du kan skapa en separat mapp, men det är värt att komma ihåg att adressraden för skriptstart kommer att skilja sig från vårt exempel). Sedan in kommandoraden ska skrivas:
C:\bsdos_utility.cmd
Efter att ha visat en lista över alla dumpar från listan C:\Windows\Minidump\, varefter skriptet frågar vilken dump som ska analyseras. Du kan också välja önskad minidump själv när du kör skriptet:
På liknande sätt är det möjligt att detektera massa Windows-fel 10, som orsakade BSOD, samt problematiska .exe-program som orsakade en blå skärm.
Denna korta notering syftar till att visa hur du kan konfigurera systemet för att få en nödsituation Windows minnesdump, det vill säga en dumpning som kan skapas om ett kritiskt fel inträffar, kännetecknat av uppkomsten av en blå skärm av död (BSOD). Vad är en soptipp i allmänhet, varför behöver vi den och vad är den, vilka problem är den tänkt att lösa och vilken information innehåller den?
Minnesdump - innehållet i arbetsminnet för en process, kärna eller hela operativsystemet, inklusive, förutom arbetsområden, ytterligare information om tillståndet för processorregistren, innehållet i stacken och andra tjänstestrukturer.
Varför kan vi behöva detta innehåll, dvs. Windows minnesdump? Den kanske vanligaste användningen av en minnesdump är att studera orsakerna till ett systemfel (), vilket gjorde att operativsystemet slutade helt. Utöver detta kan minnesstatus användas för andra ändamål. Det är också viktigt att en minnesdump är bokstavligen det enda sättet få information om eventuella fel! Och att ta (skaffa) en systemminnesdump är faktiskt den enda korrekta metoden för att få ett omedelbart fingeravtryck (kopia) av innehållet fysiskt minne system.
Ju mer exakt innehållet i dumpningen återspeglar minnets tillstånd vid tidpunkten för felet, desto mer detaljerat kommer vi att kunna analysera nödsituationen. Därför är det extremt viktigt att få en verklig kopia av systemets fysiska minne i en strikt visst ögonblick tid omedelbart före felet. Och det enda sättet att göra detta är att skapa en fullständig kraschdump. Anledningen är ganska trivial - när en kraschdumpning av systemminnet inträffar, antingen som ett resultat av ett fel eller som ett resultat av en artificiellt simulerad situation, befinner sig systemet i detta ögonblick av att ta emot kontroll av nödfunktioner (KeBugCheckEx) i en absolut oförändrat (statiskt) tillstånd, därför, mellan det ögonblick då felet inträffar och det ögonblick då data skrivs till media, ändrar ingenting innehållet i det fysiska minnet, och det skrivs till disken i sitt ursprungliga tillstånd. Tja, detta är i teorin, men ibland i livet, men det finns situationer där, på grund av felaktiga hårdvarukomponenter, själva minnesdumpen kan skadas, eller stationen kan frysa medan dumpningen spelas in.
I de allra flesta fall förblir informationen i minnet oförändrad från det ögonblick då processen att skapa en kraschminnesdump börjar till slutet av att skriva minnesinnehållet till disk.
Teoretiskt förklaras den statiska (oföränderligheten) av minnets "fingeravtryck" av det faktum att när KeBugCheckEx-funktionen anropas, som visar information om felet och startar processen att skapa en minnesdump, är systemet redan helt stoppat och innehållet i det fysiska minnet skrivs till block som är upptagna på disken av personsökningsfilen, varefter den återställs till en fil på systemmediet under den efterföljande laddningen av operativsystemet. Tja, nästan en gång observerade jag en situation där en defekt moderkort hindrade mig från att spara en minnesdump: a) frös medan dumpsparlogiken kördes (processen nådde inte 100%), b) skadade minnesdumpfilen (felsökaren klagade på strukturer), c) skriver memory.dmp dump filer av noll längd. Därför, trots det faktum att systemet redan är helt stoppat när minnesdumpen skapas, och endast nödkoden körs, kan felaktig hårdvara göra justeringar av vilken logik som helst utan undantag i vilket skede av drift som helst.
Traditionellt, på inledande skede För att spara en Windows-minnesdump används diskblock som tilldelats sidfilen. Sedan, efter en blå skärm och en omstart, flyttas data till separat fil, och sedan byts filen om med ett mönster beroende på dumptypen. Dock med början från Windows-versioner Vista, detta tillstånd kan ändras, nu ges användaren möjlighet att spara en vald dump utan deltagande av en växlingsfil, och placera information om felet i en temporär fil. Detta gjordes för att eliminera konfigurationsfel associerade med felaktig inställning sökningsfilens storlek och position, vilket ofta ledde till problem under processen att spara en minnesdump.
Låt oss se vilka typer av dumpar som Windows-operativsystemet tillåter oss att skapa:
Alla kraschdumpar kan delas in i två huvudkategorier:
Du måste vara inloggad under administrativ konto för att utföra stegen som beskrivs i detta avsnitt.
Låt oss gå direkt till att konfigurera Windows kraschdumpinställningar. Först måste vi gå till fönstret för systemegenskaper på något av följande sätt:
Resultatet av de beskrivna åtgärderna är att öppna fönstret "Systemegenskaper" och välja fliken "Avancerat":
Efter det, i avsnittet "Boot and Recovery" klickar vi, väljer "Alternativ" och öppnar därmed ett nytt fönster som heter "Ladda ner och återställning":
Alla kraschdumpparametrar är grupperade i ett parameterblock som kallas "Systemfel". I detta block kan vi ställa in följande parametrar:
Som du kan se är många av parametrarna från listan ganska triviala och lätta att förstå. Jag skulle dock vilja utveckla parametern "Dump File". Parametern presenteras som en rullgardinslista och har fyra möjliga värden:
En liten minnesdump (minidump) är en fil som innehåller den minsta mängden information om felet. Den minsta av alla möjliga minnesdumpar. Trots de uppenbara nackdelarna, används minidumps ofta som information om ett misslyckande att överföras till tredje parts förarförsäljare för efterföljande undersökning.
Förening:
Logi: %SystemRoot%\Minidump\MMDDYY-XXXXX-NN.dmp. Där MMDDÅÅ är månad, dag respektive år, är NN dumpens serienummer.
Volym: Storleken beror på operativsystemets bithet: endast 128 kilobyte krävs för en 32-bitars och 256 kilobyte för ett 64-bitars operativsystem i växlingsfilen (eller i filen som anges i DedicatedDumpFile). Eftersom vi inte kan ställa in en så liten storlek, rundar vi den upp till 1 megabyte.
Denna typ av dump innehåller en kopia av allt kärnminne vid tidpunkten för kraschen.
Förening:
Kärnminnesdumpen saknar oallokerade minnessidor och användarlägessidor. Håller med, det är osannolikt att processsidor i användarläge kommer att vara av intresse för oss under ett systemfel (BugCheck), eftersom vanligtvis systemfel initieras av kärnlägeskod.
Storlek: Varierar beroende på storleken på kärnans adressutrymme som tilldelats av operativsystemet och antalet drivrutiner för kärnläge. Vanligtvis krävs ungefär en tredjedel av det fysiska minnet i växlingsfilen (eller i filen som anges i DedicatedDumpFile). Kan variera.
En full minnesdump innehåller en kopia av allt fysiskt minne (RAM) vid tidpunkten för felet. Följaktligen ingår hela innehållet i systemminnet i filen. Detta är både en fördel och en stor nackdel, eftersom dess storlek kan vara betydande på vissa servrar med stora mängder RAM.
Förening:
Som standard inkluderar en fullständig minnesdump inte områden av fysiskt minne som används av BIOS.
Plats: %SystemRoot%\MEMORY.DMP . Den tidigare dumpningen skrivs över.
Volym: Personsökningsfilen (eller filen som anges i DedicatedDumpFile) kräver en volym som är lika med storleken på fysiskt minne + 257 megabyte (dessa 257 MB är uppdelade i en viss rubrik + drivrutinsdata). Faktum är att i vissa operativsystem kan den nedre tröskeln för personsökningsfilen ställas in exakt till värdet för den fysiska minnesstorleken.
Från och med Windows 8/Windows Server 2012 introducerades systemet ny typ dump kallas "Automatic Memory Dump", som är inställd som standardtyp. I det här fallet bestämmer systemet självt vilken minnesdump som ska spelas in i händelse av ett visst fel. Dessutom beror valets logik på många kriterier, inklusive hur ofta operativsystemet kraschar.
När du har ändrat Windows-minnesdumpkonfigurationen kan du behöva starta om datorn.
Registeravsnittet som definierar kraschdumpparametrarna:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
Parametrar:
| Parameter | Typ | Beskrivning |
|---|---|---|
| Automatisk omstart | REG_DWORD | Aktivera/inaktivera automatisk omstart när BSOD inträffar. |
| CrashDumpEnabled | REG_DWORD | Typen av dump som skapas.
|
| DumpFile | REG_EXPAND_SZ | Sökväg och namn på kärnminnesdumpen och full minnesdump. |
| DumpFilters | REG_MULTI_SZ | Drivrutinsfilter i minnesdump-drivrutinstacken. Låter dig lägga till ny funktionalitet när du skapar kraschdumpar. Till exempel kryptera innehållet i dumpningen. Att ändra värdet rekommenderas inte. |
| LogEvent | REG_DWORD | Registrerar en händelse i systemloggen. |
| MinidumpDir | REG_EZPAND_SZ | Sökväg och namn på den lilla minnesdumpen. |
| MinidumpsCount | REG_DWORD | Maximalt antal små minnesdumpar. När det överskrids börjar äldre versioner skrivas över. |
| Skriva över | REG_DWORD | Ersätt en befintlig dumpfil. Endast för kärnminnesdumpning och full minnesdump. |
| IgnoreraSidfilstorlek | REG_DWORD | Ignorerar standardfil swap som en plats för tillfällig (mellanliggande) lagring av en minnesdump. Indikerar att minnesdumpen ska skrivas till en separat fil. Används tillsammans med alternativet DedicatedDumpFile. |
| DedicatedDumpFile | REG_EZPAND_SZ | Sökväg och namn på en temporär alternativ fil för inspelning av en minnesdump. I det andra passet kommer data fortfarande att flyttas till DumpFile/MinidumpDir. |
Ovan beskrev vi inställningarna för automatiskt skapande systemkraschdumpar i händelse av ett kritiskt fel, det vill säga ett ohanterat undantag i kärnkoden. Men i det verkliga livet, förutom att operativsystemet kraschar, finns det situationer när det är nödvändigt att få en systemminnesdump vid en viss tidpunkt. Vad ska man göra i det här fallet? Det finns metoder för att få en ögonblicksbild av allt fysiskt minne, till exempel genom att använda kommandot .dump i WinDbg/LiveKD-felsökningarna. LiveKD är ett program som låter dig köra Kd-kärnfelsökaren på ett körande system i lokalt läge. WinDbg debugger har också en liknande funktion. Emellertid är dumpningsmetoden i farten inte korrekt eftersom dumpen som genereras i det här fallet är "inkonsekvent" eftersom det tar tid att generera dumpen, och i händelse av att kärnlägesfelsökningen används fortsätter systemet att köra och göra ändringar på minnessidorna.
Hej vänner, idag ska vi titta intressant ämne, som kommer att hjälpa dig i framtiden när en Blue Screen of Death (BSoD) dyker upp.
Precis som jag var många andra användare tvungna att observera utseendet på en skärm med blå bakgrund som något skrevs på (vitt på blått). Detta fenomen indikerar ett kritiskt problem, som i programvara t.ex. en drivrutinkonflikt eller ett fysiskt fel på någon datorkomponent.
Jag fick nyligen ett problem med blå skärm i Windows 10 igen, men jag blev snabbt av med det och kommer att berätta om det snart.
Så de flesta användare är inte medvetna om att BSoD kan analyseras för att senare förstå de kritiska felproblemen. För sådana fall skapar Windows speciella filer på disken, och vi kommer att analysera dem.
Det finns tre typer av minnesdump:
Full minnesdump– den här funktionen låter dig spara innehållet i RAM-minnet helt. Det används sällan, för tänk dig att du har 32 GB RAM, med en full dumpning kommer all denna volym att lagras på disken.
Kärndump– sparar information om kärnläge.
Liten minnesdump– sparar en liten mängd felinformation och laddade komponenter som fanns när systemfelet inträffade. Vi kommer att använda den här typen av dump eftersom det kommer att ge oss tillräckligt med information om BSoD.
Platsen för både den lilla och den fullständiga dumpningen är annorlunda, till exempel är den lilla dumpen placerad i följande sökväg: %systemroot%\minidump.
Hela dumpningen är här: %systemroot%.
Det finns olika program för att analysera minnesdumpar, men vi kommer att använda två. Den första är Microsoft Kernel Debuggers, som namnet antyder, ett verktyg från Microsoft. Du kan ladda ner den från den officiella webbplatsen. Det andra programmet är BlueScreenView, ett gratisprogram, ladda ner här.
För olika versioner system du behöver för att ladda ner din egen typ av verktyg. Till exempel, för ett 64-bitars operativsystem behövs ett 64-bitarsprogram, för ett 32-bitars operativsystem behövs en 32-bitarsversion.
Det är inte allt, du måste ladda ner och installera paketet med felsökningssymboler som behövs för programmet. Det kallas Debugging Symbols. Varje version av detta paket laddas också ner under ett specifikt operativsystem, ta reda på först vilket system du har och ladda sedan ner. Så att du inte behöver leta efter dessa symboler någonstans, här är nedladdningslänken. Installationen bör helst göras på denna väg: %systemrot%\symbols.
Nu kan du starta vår debugger, vars fönster kommer att se ut så här:
Innan vi analyserar dumpningarna kommer vi att konfigurera något i verktyget. Först måste vi berätta för programmet där vi installerade felsökningssymbolerna. För att göra detta, klicka på "Arkiv"-knappen och välj "Symbolfilsökväg" och ange sedan sökvägen till symbolerna.
Programmet låter dig extrahera symboler direkt från webben, så att du inte ens behöver ladda ner dem (ursäkta de som redan har laddat ner dem). De kommer att tas från en Microsoft-server, så allt är säkert. Så du måste öppna "File" igen, sedan "Symbol File Path" och ange följande kommando:
SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols
Därför indikerade vi för programmet att symbolerna skulle tas från nätverket. När vi har gjort detta klickar du på "Arkiv" och väljer "Spara arbetsyta" och klickar sedan på OK.
Det är allt. Vi har konfigurerat programmet på rätt sätt, nu börjar vi analysera minnesdumpar. Tryck på knappen i programmet "Fil", Då "Öppna Crash Dump" och välj önskad fil.
Kernel Debuggers börjar analysera filen och matar sedan ut ett resultat om orsaken till felet.
I fönstret som visas kan du ange kommandon. Om vi går in !analysera –v, så får vi mer information.
Det är allt med det här programmet. För att stoppa felsökningen, välj "Debug" och alternativet "Stop Debugging".
För analys olika fel och BSoD, programmet BlueScreenView är också lämpligt, som har ett enkelt gränssnitt, så det borde inte vara några problem med att bemästra det.
Ladda ner programmet från länken ovan och installera. När du har startat verktyget måste du konfigurera det. Gå till parametrarna: "Inställningar" - "Avancerade inställningar". Ett litet fönster öppnas med ett par föremål. I det första stycket måste du ange platsen för minnesdumparna. De finns vanligtvis i sökvägen C:\WINDOWS\Minidump. Klicka sedan på knappen "Standard".
Vad kan du se i programmet? Vi har menyalternativ, en del av fönstret med namnen på dumpfilerna och den andra delen av fönstret – innehållet i minnesdumparna.
Som jag sa i början av artikeln kan dumpar lagra drivrutiner, skärmdumpen av själva "dödsskärmen" och andra användbar information, vilket kan vara användbart för oss.
Så, i den första delen av fönstret, där dumpfilerna finns, välj den minnesdump vi behöver. I nästa del av fönstret tittar vi på innehållet. Drivrutiner som finns i minnesstacken är markerade i rödaktig färg. De är just orsaken till den blå skärm av döden.
På Internet kan du hitta allt om felkod och drivrutin som kan vara skyldig till BSoD. För att göra detta, klicka på "Arkiv" och sedan "Hitta in Google-kod fel + drivrutin".
Du kan bara visa de drivrutiner som fanns när felet inträffade. För att göra detta, klicka på "Inställningar" - "Läge under fönstret" - "Endast drivrutiner som finns i kraschstacken". Eller tryck på F7-tangenten.
För att visa BSoD-skärmdumpen, tryck på F8.
För att visa alla drivrutiner och filer, tryck på F6.
Tja, det är allt. Nu vet du hur du tar reda på Blue Screen of Death-problemet, och om något händer, hitta en lösning på Internet eller på denna sida. Du kan erbjuda dina felkoder, och jag kommer att försöka skriva för varje artikel för att lösa problemet.
Glöm inte heller att ställa frågor i kommentarerna.
Jag kommer att fortsätta prata om dödens blå skärm, som jag började i.
Så om datorn plötsligt startar om eller fryser, och den blå skärmen av döden inte visas eller visas i en bråkdel av en sekund, kan information om orsakerna till felet fortfarande återställas.
Faktum är att operativsystemet vid tidpunkten för fel sparar innehållet i RAM i den så kallade dump filen(har förlängning .dmp). I framtiden kan dumpfilen analyseras och få samma information som på den blå skärmen och ännu lite till.
Men skapandet av dumpar kan inaktiveras i systemet, så du bör se till att systemet för det första skapar dumpar när det kraschar, och för det andra bör du känna till platsen på disken där de sparas.
För att göra detta måste du gå till avsnittet System.
I Windows 10 kan detta göras genom sökning och i tidigare versioner operativsystem via kontrollpanelen.
Här bör inspelning av händelser i systemloggen vara aktiverad, men för att förhindra att datorn automatiskt startas om och visar oss innehållet på den blå skärmen av döden, måste du avbryta den automatiska omstarten om den var aktiverad.
Sökvägen till dumparna visas också här - vi ser att dumpen är sparad i mappen %SystemRoot% - detta är beteckningen på Windows-mappen.
Du kan också välja "liten minnesdump" här, vilket är tillräckligt för att söka efter felkoder.
Så systemet kraschade in i dödens blå skärm, varefter en minnesdump skapades.
För dumpningsanalys finns det specialprogram och en av de mest populära är verktyget BlueScreenView.
Programmet är mycket lätt att använda och kräver ingen installation - ladda ner från den officiella webbplatsen och packa upp det. Samtidigt, från den officiella webbplatsen kan du ladda ner en fil med vilken du kan russifiera programmet. För detta denna fil du måste placera den i mappen med det uppackade programmet.
Om, efter att ha startat programmet, dumparna inte visas, även om systemet kraschade in i den blå skärmen av döden, bör du gå till programinställningarna och se till att sökvägen till minnesdumparna är korrekt specificerad, det vill säga den bör vara samma som i systeminställningarna.
Efter detta måste du uppdatera informationen i programfönstret och alla dumpar som skapats i systemet kommer att visas. Om det finns flera soptippar fokuserar vi på datumet för felet. Välj önskad dump, så visas den detaljerad information på den.
Här visas namnet på felet, dess STOPP-kod med parametrar, och om orsaken var föraren, kommer vi att hitta dess namn i motsvarande fält.
Längst ner i programfönstret kommer filer som också kan orsaka felet att markeras i rosa. Vi måste ta itu med var och en av dem i ordning. Algoritmen här liknar den som diskuterades i föregående inlägg - vi letar efter en lösning på Internet och använder filnamnet eller felkoden som söknyckel.
I det här fallet är det inte nödvändigt att manuellt mata in data i sökmotorn. Om du högerklickar på dumpraden, sedan från snabbmenyn Du kan välja ett objekt som gör att du kan hitta en beskrivning av just detta problem i Google.
Du kan välja att söka på Google med felkod, felkod och drivrutinsnamn eller efter felkod och parameter.
Med det här verktyget kan du också snabbt hitta platsen för den problematiska filen på disken.
Ibland händer det att filen som orsakade problemet tillhör något program eller spel. Genom platsen för filen på disken kan du snabbt avgöra vilket program eller spel den tillhör.
Tja, det är värt att veta att städare verkar ta bort minnesdumpar, så om du använder sådana program, bör du avstå från att använda dem samtidigt som du identifierar orsaken till den blå skärmen.
Och den sista frågan som jag kommer att besvara som en del av denna anteckning är vad ska man göra om datorn inte längre startar efter den blå skärmen? Det vill säga att datorn fryser eller är konstant överbelastad, vilket innebär att det inte finns något sätt att analysera minnesdumpen.
Svaret är logiskt och enkelt - du måste skapa startbart USB-minne, med vilken du kan "extrahera" dumpfilen från hårddisk och analysera det på en annan dator. För att göra detta, starta från en flash-enhet och på datorns hårddisk i mappen Windows eller i en undermapp minidump Vi hittar dumpfilen, som vi kopierar till flashenheten. Sedan på en annan dator med hjälp av verktyget BlueScreenView Vi analyserar soptippen, som beskrivs i denna not.
I Windows 8 introducerade Microsoft en ny minnesdump – ett alternativ för automatisk minnesdump. Denna parameter i operativsystem installerat som standard. Windows 10 introducerade en ny typ av dumpfil - aktiv minnesdump. För den som inte vet, i Windows 7 har vi liten dump, kärndump och full kärndump. Du kanske undrar varför Microsoft bestämde sig för att skapa detta ny parameter minnesdump? Enligt Robert Simpkins, senior supportingenjör, kan en automatisk minnesdump skapa stöd för "system"-sidan i konfigurationsfilen.
Konfigurationshanteringssystemet för personsökningsfilen ansvarar för att hantera storleken på personsökningsfilen - detta undviker onödigt utrymme eller storleken på personsökningsfilen. Detta alternativ introduceras främst för datorer som körs på SSD-enheter, som vanligtvis har mindre storlek, men en enorm mängd RAM.
Den största fördelen med "Automatisk minnesdumpning" är att den kommer att tillåta delsystemsessionen i processhanteraren att automatiskt reducera sidfilen till en storlek som är mindre än storleken på RAM. För den som inte vet så ansvarar sessionen för subsystem manager för systeminitiering, startmiljön för tjänster och processer som krävs för att användaren ska kunna logga in i systemet. Det ställer i princip in filsidan till virtuellt minne och startar winlogon.exe-processen.
Om du vill ändra dina inställningar för automatisk minnesdumpning gör du så här. Klick Windows-tangenter+ X och välj - System. Klicka sedan på knappen "Avancerade systeminställningar - Förskott System Inställningar”.
Klicka på knappen Avancerade systeminställningar.
Här kan du se en rullgardinsmeny där det står "Avancerat".
Här kan du välja det alternativ du vill ha. Föreslagna alternativ:
Inga minnesdumpar.
Liten minnesdump.
Kärnminnesdump.
Komplett minnesdump.
Automatisk minnesdumpning. Lades till i Windows 8.
Aktiv minnesdump. Lades till i Windows 10.
Platsen för minnesdumpfilen finns i filen %SystemRoot%\MEMORY.DMP.
Om du använder SSD-enhet, då är det bättre att lämna det på "Automatisk minnesdumpning"; men om du behöver en kraschdumpfil, så är det bättre att ställa in den på "liten minnesdump", med den kan du, om du vill, skicka den till någon så att de kan ta en titt på den.
I vissa fall kan du behöva öka sidfilstorleken med mer än RAM, så att den kan matcha en full minnesdump. I sådana fall måste du skapa en registernyckel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
det heter "LastCrashTime".
Detta kommer automatiskt att öka storleken på växlingsfilen. För att minska den senare kan du helt enkelt ta bort den här nyckeln.
Windows 10 har introducerat en ny dumpfil som heter aktiv minnesdump. Den innehåller bara det väsentliga och är därför mindre i storlek.
Jag har inget sätt att testa det, men jag skapade den här nyckeln och övervakade sidfilstorleken. Jag vet att jag förr eller senare kommer att få kritiskt fel. Då ska jag kolla det.
Du kan analysera minnesdump av Windows.dmp-filer med WhoCrashed. WhoCrashed Home är ett gratis verktyg som tillhandahåller drivrutiner som har installerats på din dator med ett klick. I de flesta fall kan den identifiera en felaktig drivrutin som orsakar problem med din dator. Detta är en systemanalyskraschdump, minnesdumpar och all insamlad information presenteras här i en tillgänglig form.
Vanligtvis kommer felsökningsverktyget att öppna en analyskraschdump. Med det här verktyget behöver du inga kunskaper eller felsökningsfärdigheter för att ta reda på vilka drivrutiner som orsakar problem på din dator.
WhoCrashed förlitar sig på ett felsökningspaket (windbg-programmet) från Microsoft. Om detta paket inte är installerat kommer WhoCrashed att ladda ner och automatiskt extrahera det här paketet åt dig. Kör bara programmet och klicka på knappen Analysera. När du har WhoCrashed installerat på ditt system och om det kraschar eller stängs oväntat, kommer programmet att meddela dig om kraschdumpning är aktiverat på din dator och det kommer att ge dig förslag på hur du aktiverar dem.
