Ha az ún kék képernyő halál a Windows 10 rendszerben, és készen áll arra, hogy ideges kómába essen, összeszedi magát, és megpróbálja megoldani a problémát. Először is érdemes elmondanunk, hogy ez az ominózus üzenet kritikus helyzetet jelez rendszer hiba. Sőt, nem mindig lehet elkapni a pillanatot, és nem mindig van ideje elolvasni a hibakódot, amikor a Windows a halál kék képernyőjére esik, és az eszköz újraindul. Azonnal jegyezzük meg, hogy van nagy mennyiség megoldásokat erre a problémára, valamint a kék képernyő okait. Ebben a cikkben megpróbáljuk megvizsgálni valószínű okok a boldogság kék képernyőjének megjelenése, valamint lehetséges megoldások Problémák.

Az esetek túlnyomó többségében a halál kék képernyője a BAD_POOL_CALLER - stop 0x000000c2 hibát jelzi. Őszintén szólva nehéz diagnosztizálni ezt a hibát, de talán megpróbáljuk ezt a hibát példaként felhasználni a következő műveletek algoritmusának leírására.

A probléma helyes diagnosztizálásához először elemeznie kell speciális fájl minidump (memóriadump) nevű rendszer. Az ilyen fájlok létrejöttét rendszerhiba okozza, sőt, arról is tájékoztathatnak bennünket, hogy pontosan mi vezetett a meghibásodáshoz.

1. Egy kis memóriakép automatikus rögzítésének engedélyezéséhez (alapértelmezés szerint le van tiltva), lépjen a számítógép tulajdonságaihoz, és lépjen a " szakaszra. Extra lehetőségek rendszerek" (ez a beillesztés minden rendszerre vonatkozik, nem csak a Windows 10-re):

Általános szabály, hogy minden minidump fájl mentésre kerül, amikor megjelenik a kék képernyő (BSOD), és a C:\Windows\Minidump mappában találhatók. Figyelemre méltó, hogy a fájlnév tartalmazza Az aktuális dátum– mikor készült, ami sokkal könnyebbé teszi a hiba fellépésének dátumának azonosítását, különös tekintettel arra, hogy egynél több ilyen fájl is lehet.

Két módja a kis memória minidump visszafejtésének

Első út, a meglehetősen népszerű BlueScreenView segédprogram használatából áll. Ez a segédprogram a memóriakiíratások elemzéséhez is jó lehetőség lehet. Ennek a segédprogramnak a használata hasznos lehet a problémás illesztőprogram azonosítására.

Sőt, különösen figyelemre méltó, hogy segítségével a BSOD-t (blue screen of death) úgy lehet nézni, mintha egy kimerevített képkockában lenne, mint a rendszer összeomlásakor. Megjeleníti a hiba időpontját és dátumát, információkat az illesztőprogramról vagy a modulról, verzióval és rövid leírás. Ezenkívül a segédprogram számos nyelven elérhető, beleértve az oroszt is. Tehát a BlueScreenView segédprogram a megfelelő dolog, ha gyorsan kell elemeznie a memóriakiíratásokat a BSOD során.

Mert második módszer telepítenie kell a Debugging Tools for Windows programot, és le kell töltenie a bsdos_utility segédprogramot. Ezután a bsdos_utility.cmd szkript kicsomagolása után helyezzük át a C:\ meghajtóra (létrehozhatunk külön mappát is, de nem árt megjegyezni, hogy a szkript indításának címsora eltér a példánkban szereplőtől). Ezután a parancssorba ezt kell írni:

C:\bsdos_utility.cmd

A C:\Windows\Minidump\ listában található összes kiírat listájának megjelenítése után a szkript megkérdezi, hogy melyik kiíratást kell elemezni. A szkript futtatásakor saját maga is kiválaszthatja a szükséges minidumpot:

Hasonló módon lehetséges a tömeg kimutatása Windows hibák 10, amely a BSOD-t okozta, valamint a problémás .exe programok, amelyek kék képernyőt okoztak.

A telepíteni kívánt összetevő kiválasztásának következő lépésében ( Válassza ki a telepíteni kívánt szolgáltatásokat) csak azt jelöljük meg, amire szükségünk van - Hibakereső eszközök a Windows számára és nyomja meg Telepítés

A program letölt és telepít egy segédprogramot az internetről az első képernyőn megadott mappába.

A telepítés befejezése után keresse meg a Start menüben vagy a kezdőképernyőn a parancsikoncsoportban Windows Kits hasznosság WinDbgés rendszergazdai jogokkal futtassa

Ha valamilyen okból nem található a parancsikon, akkor futtathatja a végrehajtható fájlt a telepítési könyvtárból - C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\windbg.exe

A program főmenüjében WinDbg elemek kiválasztása Fájl > Szimbólum fájl elérési útja. A megnyíló ablakban szúrjon be egy sort, amely meghatározza a helyi szimbólum-gyorsítótár könyvtárát és annak online forrását:

A beállításokat a főmenü elemeinek kiválasztásával mentjük Fájl > Munkaterület mentése

Nyissa meg a memóriakiíratási fájlt a menü kiválasztásával Fájl > Nyissa meg a Crash Dump-ot...

Válasszon ki egy fájlt MEMORY.DMP(alapértelmezés szerint a C:\Windows könyvtárban található), és kattintson a gombra Nyisd ki

Megjelenik az információ arról, hogy melyik végrehajtható modul okozta a rendszer működésének leállását. Egy hiperhivatkozásra kattintva !elemez-v Részletesebb információkat kaphat a rendszer állapotáról a leállási hiba bekövetkeztekor.

Ugyanezek az információk a parancssorból is beszerezhetők a következő parancssorok használatával:

Ebben a példában a dump elemzésével kapcsolatos összes információ olvasható formában letöltődik a C:\Debuglog.txt fájlba.

Információforrások:

Jó napot, kedves kollégák és a blogoldal olvasói. Ma szeretném elmondani, hogyan lehet elemezni a Windows 10 Redstone memóriakiíratását. Ez a legtöbb esetben megtörténik, amikor egy kék halálos képernyő jelenik meg hibával, amely után a számítógép újraindul. ÉS ezt az elemzést segít megérteni a hiba okát.

A Windows 10 memóriakiíratásának beállítása

Tehát mi az a memória kiíratása a Windows 10 Redstone operációs rendszerben. Fentebb leírtam neked, nagyon gyakori ok amelyben megjelenik egy rendszermemória dump, és ezek a halál kék képernyői. Megjelenésük okai nagyon kiterjedtek:

• Alkalmazás-kompatibilitás
• Driver inkompatibilitás
• Új Windows frissítések
• Az eszközök nem kompatibilisek

Ez csak egy kis általánosított lista, mivel rengeteg hibakód van a kék képernyőkről, a legfrissebbeket adom.

A mi feladatunk, hogy ezeket a fájlokat diagnosztikai célból megtaláljuk és értelmezni tudjuk, hogy információt szerezzünk a problémáról.

Hol van beállítva a Windows 10 összeomlási kiíratása?

Először is nézzük meg, hol van a beállítás, amely a Windows 10 összeomlási memória kiíratásáért felelős. Kattintson a jobb gombbal a Windows 10 start gombjára, majd helyi menü válassza a Rendszer lehetőséget.

A megnyíló Rendszer ablakban Ön a bal oldalon van felső sarok válassza a Speciális rendszerbeállítások lehetőséget.

Itt van konfigurálva a Windows 10 memóriakiíratása. Kattintson a Beállítások elemre a Boot and Recovery menüben.

A Windows 10 memóriakiíratásának beállításai közül a következőket szeretném megjegyezni:

• Esemény rögzítése itt syslog> itt a kék képernyővel kapcsolatos információk hozzáadódnak a naplókhoz operációs rendszer.
• Végrehajtás automatikus újraindítás> hiba után tovább dolgozni
• A hibakeresési információk rögzítése > lehetővé teszi a dump fájl típusának kiválasztását, erről alább olvashat bővebben.
• Cserélje ki a meglévő dump fájlt, ez egy hasznos jelölőnégyzet, mivel ezek a kiíratások több tíz gigabájtot is nyomhatnak, ami nagyon kritikus a kis SSD meghajtók számára.

A memóriakiíratok típusai

Nézzük meg a különbségeket a hibakeresési információk rögzítésének lehetőségei között

• Kis memória kiíratása 256 KB: A kis memóriaképfájlok a következő információkat tartalmazzák:

– üzenet végzetes hibáról, annak paramétereiről és egyéb adatairól;

– a betöltött illesztőprogramok listája;

- processzor kontextus ( PRCB) amelyen a hiba bekövetkezett;

EPROCESS) a hibát okozó folyamathoz;

- feldolgozni az információkat és a kernelkörnyezetet ( CÉLASZÁM) a hibát okozó szálhoz;

– Kernel módú hívási verem a hibát okozó szálhoz.

Akkor használják, ha nagyon kevés van lemez terület tiéden helyi lemez. Ezen keresztül áldozunk hasznos információ, ami nem biztos, hogy elegendő a kék képernyő diagnosztizálásához.

A mini dump a C:\Windows\Minidump útvonalon tárolódik

• Kernel memory dump > csak kernelmemóriát rögzít. A számítógép fizikai memóriájának méretétől függően ebben az esetben a lapozófájlhoz 50 és 800 között van szükség. MB vagy a számítógép fizikai memóriájának egyharmada a rendszerindító köteten.
• Full memory dump > nos, a névből minden kiderül. Abszolút mindent ír, ez a maximális információ a kék képernyőről, száz százalékos diagnózist ad a problémára.

A következő helyen található: C:\Windows\Memory.dmp

• Active memory dump > ide kerül a gazdagép aktív memóriája, ez a funkció inkább szerver platformokra való, mivel ezek használhatók virtualizációra, és hogy a virtuális gépekről szóló információk ne kerüljenek a dumpba, ezt az opciót találták ki.

Ennek a rövid megjegyzésnek az a célja, hogy bemutassa, hogyan konfigurálhatja a rendszert vészhelyzet esetén lerak Windows memória , vagyis egy kritikus hiba bekövetkeztekor létrejöhet dump, amelyet a halál kék képernyőjének (BSOD) megjelenése jellemez. Mi a szemétlerakó általában, miért van rá szükségünk és mi az, milyen problémákat hivatott megoldani és milyen információkat tartalmaz?

Memóriakiírat - egy folyamat, kernel vagy teljes operációs rendszer munkamemóriájának tartalma, beleértve a munkaterületeken kívül, További információ a processzorregiszterek állapotáról, a verem tartalmáról és egyéb szolgáltatási struktúrákról.

Miért lehet szükségünk erre a tartalomra, pl. Windows memória dump? A memóriakiírás talán legáltalánosabb használata a rendszerhiba okainak tanulmányozása (), amely az operációs rendszer teljes leállását okozta. Ezen kívül a memória állapota más célokra is használható. Az is fontos, hogy a memória kiíratása szó szerint az egyetlen módja annak, hogy információt szerezzünk bármilyen meghibásodásról! És a rendszermemória kiíratásának vétele (megszerzése) valójában az egyetlen pontos módszer a rendszer fizikai memória tartalmának azonnali ujjlenyomatának (másolatának) beszerzésére.

Minél pontosabban tükrözi a dump tartalma a memória meghibásodáskori állapotát, annál részletesebben tudjuk elemezni a vészhelyzetet. Ezért rendkívül fontos, hogy szigorúan beszerezzük a rendszer fizikai memóriájának tényleges másolatát bizonyos pillanatban a meghibásodást közvetlenül megelőző idő. Ennek egyetlen módja egy teljes összeomlási dump létrehozása. Az ok meglehetősen triviális - amikor a rendszermemória összeomlása meghibásodás vagy mesterségesen szimulált helyzet eredményeként megtörténik, a rendszer abban a pillanatban, amikor megkapja a vészhelyzeti funkciók vezérlését (KeBugCheckEx) abszolút változatlan (statikus) állapot, ezért a hiba bekövetkezte és az adatok adathordozóra írása között semmi sem változtatja meg a fizikai memória tartalmát, és az eredeti állapotában kerül lemezre. Nos, ez elméletben, de az életben is előfordul, de vannak olyan helyzetek, amikor a hibás hardverelemek miatt maga a memóriakiírás megsérülhet, vagy az állomás lefagyhat a kiírás rögzítése közben.

Az esetek túlnyomó többségében attól a pillanattól kezdve, hogy az összeomlási memóriakép létrehozásának folyamata elkezdődik, egészen a memóriatartalom lemezre írásának végéig, a memóriában lévő információk változatlanok maradnak.

Elméletileg a memória „ujjlenyomatának” statikusságát (változhatatlanságát) az magyarázza, hogy a KeBugCheckEx függvény meghívásakor, amely információt jelenít meg a hibáról, és elindítja a memóriakiírás létrehozásának folyamatát, a rendszer már teljesen leáll, és a a fizikai memória tartalma a lapozófájl által a lemezen elfoglalt blokkokra íródik, majd az operációs rendszer ezt követő betöltésekor visszaáll a rendszer adathordozóján lévő fájlba. Nos, szinte egyszer megfigyeltem egy olyan helyzetet, amikor egy hibás alaplap megakadályozta, hogy elmentsem egy memóriakiírást: a) lefagyás a kiíratási mentési logika futása közben (a folyamat nem érte el a 100%-ot), b) a memóriakiíratási fájl károsodása (a hibakereső struktúrákra panaszkodott), c) memória.dmp kiírás írása nulla hosszúságú fájlok. Ezért annak ellenére, hogy a rendszer már teljesen leállt a memóriadump létrehozásakor, és csak a vészhelyzeti kód fut, a hibás hardver kivétel nélkül bármilyen logikát módosíthat a működés bármely szakaszában.
Hagyományosan a kezdeti szakaszban a lapfájlhoz hozzárendelt lemezblokkokat használják a Windows memóriakiíratásának mentésére. Ezután a kék képernyő és az újraindítás után az adatok egy külön fájlba kerülnek, majd a fájl átnevezése a dump típusától függő minta segítségével történik. Kezdve azonban Windows verziók Vista esetén ez az állapot megváltoztatható; most a felhasználónak lehetősége van a kiválasztott kiíratás elmentésére swap fájl részvétele nélkül, és a meghibásodásról szóló információkat egy ideiglenes fájlba helyezi el. Erre azért került sor, hogy kiküszöböljük a lapozófájl méretének és pozíciójának helytelen beállításaiból adódó konfigurációs hibákat, amelyek gyakran problémákhoz vezettek a memóriakiírás mentése során.
Nézzük meg, hogy a Windows operációs rendszer milyen típusú dumpokat tesz lehetővé:

• Folyamat (alkalmazás) memória kiíratása;
• Kernel memória kiíratása;
• Teljes memória kiíratása (a rendszer fizikai memóriájának rendelkezésre álló részének kiíratása).

Minden lerakóhely két fő kategóriába sorolható:

• Összeomlási kiíratások a történt kivétellel kapcsolatos információkkal. Általában ben készült automatikus üzemmód, amikor kezeletlen kivétel történik az alkalmazásban/kernelben, és ennek megfelelően a rendszer (beépített) hibakeresője meghívható. Ebben az esetben a kivétellel kapcsolatos információk egy kiíratóban kerülnek rögzítésre, ami megkönnyíti a kivétel típusának és helyének meghatározását a későbbi elemzés során.
• Kivétel nélküli összeomlási dump információk. Általában a felhasználó manuálisan hozza létre, amikor egyszerűen egy pillanatképet kell létrehoznia egy folyamatról a későbbi elemzéshez. Ez az elemzés nem a kivétel típusának meghatározását jelenti, hiszen kivétel nem történt, hanem egy teljesen más jellegű elemzést, például egy folyamat adatszerkezetének tanulmányozását és így tovább.

Kernel memória dump konfigurációja

Be kell jelentkeznie az adminisztrációs területen fiókot az ebben a részben leírt lépések végrehajtásához.

Ugorjunk közvetlenül a Windows összeomlási dump beállításainak konfigurálására. Először is a rendszertulajdonságok ablakba kell lépnünk a következő módok egyikével:

1. Kattintson Jobb klikk egérrel a "Sajátgép" ikonra - "Tulajdonságok" - "Speciális rendszerbeállítások" - "Speciális".
2. "Start" gomb - "Vezérlőpult" - "Rendszer" - "Speciális rendszerbeállítások" - "Speciális".
3. Billentyűparancs "Windows" + "Szünet" - "Speciális rendszerbeállítások" - "Speciális".
4. 
   vezérlőrendszer.cpl,3
5. Futtassa a parancssorban (cmd):
   SystemPropertiesAdvanced

A leírt műveletek eredménye a "Rendszer tulajdonságai" ablak megnyitása és a "Speciális" fül kiválasztása:

Ezután a „Boot and Recovery” részben kattintunk, válassza az „Opciók” lehetőséget, és nyisson meg egy új „Letöltés és helyreállítás” nevű ablakot:

Az összes összeomlási kiíratási paraméter egy "Rendszerhiba" nevű paraméterblokkban van csoportosítva. Ebben a blokkban a következő paramétereket állíthatjuk be:

1. Események írása a rendszernaplóba.
2. Hajtsa végre az automatikus újraindítást.
3. Hibakeresési információk rögzítése.
4. Dump fájl.
5. Cseréljen le egy meglévő dump fájlt.

Amint láthatja, a listában szereplő paraméterek közül sok meglehetősen triviális és könnyen érthető. A "Dump File" paramétert azonban szeretném részletesebben kifejteni. A paraméter legördülő listaként jelenik meg, és négy lehetséges értéke van:

Kis memória dump

A kis memóriakiírat (minidump) egy olyan fájl, amely a legkisebb mennyiségű információt tartalmazza a hibáról. Az összes lehetséges memóriakiíratás közül a legkisebb. A nyilvánvaló hátrányok ellenére a minidumpokat gyakran használják információként a meghibásodásról, amelyet harmadik féltől származó illesztőprogram-szállítóknak kell továbbítaniuk későbbi tanulmányozás céljából.
Összetett:

• Hiba üzenet.
• Hiba érték.
• Hibaparaméterek.
• A processzorkörnyezet (PRCB), amelyen a hiba történt.
• Folyamatinformációk és kernelkörnyezet (EPROCESS) az összeomlási folyamathoz és annak összes szálához.
• Az összeomlást okozó szál feldolgozási információi és kernelkörnyezete (ETHREAD).
• A rendszermag módú verem az összeomlást okozó szálhoz.
• A betöltött illesztőprogramok listája.

Szállás: %SystemRoot%\Minidump\MMDDYY-XXXXX-NN.dmp. Ahol MMDDYY a hónap, nap és év, ott az NN sorozatszám lerak.
Kötet: A méret az operációs rendszer bitségétől függ: a lapozófájlban (vagy a DedicatedDumpFile-ban megadott fájlban) mindössze 128 kilobájt szükséges egy 32 biteshez, és 256 kilobájt egy 64 bites operációs rendszerhez. Mivel ilyen kicsi méretet nem tudunk beállítani, ezért felkerekítjük 1 megabájtra.

Kernel memória kiíratása

Az ilyen típusú kiíratások az összeomlás idején az összes kernelmemória másolatát tartalmazzák.
Összetett:

• A futó folyamatok listája.
• Az aktuális szál állapota.
• Az összeomlás idején a fizikai memóriában található kernel módú memórialapok: kernel módú illesztőprogram-memória és kernel módú programmemória.
• Hardverfüggő szintű (HAL) memória.
• A betöltött illesztőprogramok listája.

A kernel memóriakiírásából hiányoznak a le nem osztott memórialapok és a felhasználói mód oldalai. Egyetértünk, nem valószínű, hogy a felhasználói módú folyamatoldalak érdekelnének bennünket rendszerhiba esetén (BugCheck), mivel a rendszerhibát általában a kernel mód kódja kezdeményezi.

Méret: Az operációs rendszer által lefoglalt kernelcímtér méretétől és a kernelmódú illesztőprogramok számától függően változik. Általában a fizikai memória körülbelül egyharmada szükséges a swap fájlban (vagy a DedicatedDumpFile fájlban megadott fájlban). Változhat.

Teljes memória kiíratása

A teljes memória kiíratása tartalmazza az összes fizikai memória (RAM) másolatát a hiba idején. Ennek megfelelően a rendszermemória teljes tartalma bekerül a fájlba. Ez egyrészt előny, másrészt jelentős hátrány, mivel a mérete jelentős lehet egyes, nagy mennyiségű RAM-mal rendelkező szervereken.
Összetett:

• A "látható" fizikai memória összes oldala. Ez szinte a teljes rendszermemória, kivéve a hardver által használt területeket: BIOS, PCI-terület stb.
• Adatok azokból a folyamatokból, amelyek a rendszeren futottak a hiba idején.
• A fizikai memória olyan oldalai, amelyek nincsenek leképezve a virtuális címtérre, de segíthetnek a hiba okának kivizsgálásában.

Alapértelmezés szerint a teljes memóriakép nem tartalmazza a BIOS által használt fizikai memóriaterületeket.
Hely: %SystemRoot%\MEMORY.DMP . Az előző kiíratást felülírja.
Kötet: A lapozófájl (vagy a DedicatedDumpFile-ban megadott fájl) a fizikai memória méretével és 257 megabájttal megegyező kötetet igényel (ez a 257 MB egy bizonyos fejlécre + illesztőprogram-adatokra van osztva). Valójában egyes operációs rendszerekben a lapozófájl alsó küszöbértéke pontosan beállítható a fizikai memória méretének értékére.

Automatikus memória dump

Windows 8 óta/ Windows Server 2012-ben egy új "Automatic Memory Dump" nevű kiíratási típust vezettek be a rendszerbe, amely alapértelmezett típusként van beállítva. Ebben az esetben a rendszer maga dönti el, hogy egy adott hiba esetén melyik memóriakiírást rögzítse. Ezenkívül a választás logikája számos kritériumtól függ, beleértve az operációs rendszer „összeomlásának” gyakoriságát.

A Windows memóriakiíratási konfigurációjának módosítása után előfordulhat, hogy újra kell indítania a számítógépet.

Rendszerleíró adatbázis beállításai

A rendszerleíró adatbázis szakasz, amely meghatározza az összeomlási dump paramétereit:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Lehetőségek:

Memóriakiírás manuális létrehozása

Fentebb leírtuk a beállításokat automatikus létrehozás rendszerösszeomlás kiírja kritikus hiba esetén, vagyis a kernelkódban lévő kezeletlen kivétel esetén. De a való életben az operációs rendszer összeomlása mellett vannak olyan helyzetek, amikor egy adott időpontban rendszermemória-kiíratást kell szerezni. Hogyan lehet ebben az esetben? Vannak módszerek az összes fizikai memória pillanatképének lekérésére, például a .dump paranccsal a WinDbg/LiveKD hibakeresőben. A LiveKD egy olyan program, amely lehetővé teszi a Kd kernel hibakereső futtatását egy futó rendszeren helyi módban. A WinDbg hibakereső is rendelkezik hasonló funkcióval. Az on-the-fly dump módszer azonban nem pontos, mert az ebben az esetben generált dump "inkonzisztens", mivel időbe telik a kiírás létrehozása, és a kernel módú hibakereső használata esetén a rendszer tovább fut és változások a memóriaoldalakon.

Kritikus meghibásodás esetén a Windows operációs rendszer összeomlik, és a Halál kék képernyőjét (BSOD) jelzi. Tartalom véletlen hozzáférésű memóriaés a fellépő hibával kapcsolatos minden információ a swap fájlba kerül. Legközelebb a Windows rendszerindításaösszeomlási dump jön létre a mentett adatok alapján hibakeresési információkkal. Kritikus hibabejegyzés jön létre a rendszereseménynaplóban.

Figyelem! Nem jön létre összeomlási dump, ha a lemez alrendszer meghibásodik vagy kritikus hiba a Windows rendszerindítás kezdeti szakaszában merült fel.

A Windows összeomlási dumpjainak típusai

Egy jelenlegi műtő példájával Windows rendszerek 10 (Windows Server 2016) nézzük meg a rendszer által létrehozható memóriakiíratok fő típusait:

• Mini memória dump(256 KB). Ez a fájltípus minimális mennyiségű információt tartalmaz. Csak a BSOD hibaüzenetet tartalmazza, információkat az illesztőprogramokról, az összeomlás idején aktív folyamatokról, valamint arról, hogy melyik folyamat vagy kernelszál okozta az összeomlást.
• Kernel memória kiíratása. Általában kis méretű – a fizikai memória méretének egyharmada. A kernel memória kiíratása részletesebb, mint a mini dump. Információkat tartalmaz az illesztőprogramokról és a kernel módú programokról, tartalmazza a lefoglalt memóriát Windows kernelés hardveres absztrakciós réteg (HAL), valamint az illesztőprogramok és más kernel módú programok számára lefoglalt memória.
• Teljes memória kiíratása. A legnagyobb méretű, és memóriát igényel, amely megegyezik a rendszer RAM-jával plusz 1 MB, szükséges Windows ennek a fájlnak a létrehozásához.
• Automatikus memória dump. Információ tekintetében a kernel memória kiíratásának felel meg. Az egyetlen különbség az, hogy mennyi helyet foglal el a dump fájl létrehozásához. Ez a fájltípus nem létezett a Windows 7 rendszerben. A Windows 8 rendszerben került hozzáadásra.
• Aktív memória kiíratása. Ez a típus kiküszöböli azokat az elemeket, amelyek nem tudják meghatározni a rendszerhiba okát. Ez hozzáadásra került a Windows 10 rendszerhez, és különösen hasznos, ha használja Virtuális gép, vagy ha rendszere Hyper-V gazdagép.

Hogyan lehet engedélyezni a memória dumpolást a Windows rendszerben?

A Win+Pause használatával nyissa meg a rendszerbeállítások ablakát, válassza a " Haladó rendszerbeállítások"(Haladó rendszerbeállítások). Ban,-ben " Továbbá" (Speciális), "" szakasz (Indítás és helyreállítás) kattintson a " gombra Lehetőségek"(Beállítások). A megnyíló ablakban konfigurálja a rendszer meghibásodása esetén végrehajtandó műveleteket. Ellenőrizd a " Események naplózása a rendszernaplóba" (Esemény írása a rendszernaplóba), válassza ki a rendszer összeomlásakor létrejövő kiíratás típusát. Ha a jelölőnégyzetben " Cserélje le a meglévő dump fájlt"(Bármely meglévő fájl felülírása) jelölje be a négyzetet, a fájl minden hiba esetén felülírásra kerül. Jobb, ha törli a jelölést ebből a négyzetből, akkor több információhoz jut az elemzéshez. Kapcsolja ki az Automatikus újraindítást is.

A legtöbb esetben egy kis memóriakép elegendő a BSOD okának elemzéséhez.

Most, amikor BSOD történik, elemezheti a dump fájlt, és megtalálhatja a hiba okát. A mini dump alapértelmezés szerint a %systemroot%\minidump mappába kerül mentésre. A dump fájl elemzéséhez a program használatát javaslom WinDBG(Microsoft Kernel Debugger).

A WinDBG telepítése Windows rendszeren

Hasznosság WinDBG tartalmazza " Windows 10 SDK"(Windows 10 SDK). .

A fájl neve winsdksetup.exe, mérete 1,3 MB.

Futtassa a telepítést, és válassza ki, hogy pontosan mit szeretne tenni – telepítse a csomagot erre a számítógépre, vagy töltse le más számítógépekre való telepítéshez. Telepítsük a csomagot a helyi számítógépre.

Telepítheti a teljes csomagot, de csak a hibakereső eszköz telepítéséhez válassza a lehetőséget Hibakeresés Eszközök a ablakok.

A telepítés után a WinDBG parancsikonok a start menüben találhatók.

.dmp fájlok társításának beállítása a WinDBG-vel

A dump fájlok egyszerű kattintással történő megnyitásához rendelje hozzá a .dmp kiterjesztést a WinDBG segédprogramhoz.

1. Nyisd ki parancs sor rendszergazdaként, és futtassa a parancsokat egy 64 bites rendszerhez: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
   windbg.exe –IA
   32 bites rendszerhez:
   C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
   windbg.exe –IA
2. Ennek eredményeként a .DMP, .HDMP, .MDMP, .KDMP, .WEW fájltípusok hozzá lesznek rendelve a WinDBG-hez.

Hibakeresési szimbólumszerver beállítása a WinDBG-ben

A hibakereső szimbólumok (hibakereső szimbólumok vagy szimbólumfájlok) olyan adatblokkok, amelyek egy program fordítása során keletkeznek a végrehajtható fájllal együtt. Az ilyen adatblokkok változónevekről, úgynevezett függvényekről, könyvtárakról stb. tartalmaznak információkat. Ezekre az adatokra nincs szükség a program futtatásakor, de a hibakeresés során hasznosak. A Microsoft összetevői a Microsoft Symbol Serveren keresztül terjesztett szimbólumokkal vannak összeállítva.

Konfigurálja a WinDBG-t a Microsoft Symbol Server használatához:

• Nyissa meg a WinDBG-t;
• Menjen a menübe Fájl –> Szimbólum fájl elérési útja;
• Írjon egy sort, amely tartalmazza a hibakereső szimbólumok Microsoft webhelyről történő letöltésének URL-címét és a gyorsítótár mentési mappáját: SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols A példában a gyorsítótár letöltése megtörtént. az E:\Sym_WinDBG mappába, bármelyiket jelezheti.
• Ne felejtse el menteni a menü módosításait Fájl–>Munkaterület mentése;

A WinDBG szimbólumokat keres a helyi mappában, és ha nem találja meg benne a szükséges szimbólumokat, automatikusan letölti a szimbólumokat a megadott webhelyről. Ha saját szimbólummappát szeretne hozzáadni, ezt a következőképpen teheti meg:

SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:\Symbols

Ha nincs internetkapcsolata, először töltse le a szimbólumcsomagot a Windows Szimbólumcsomagok erőforrásból.

A WinDBG összeomlási dump elemzése

A WinDBG hibakereső megnyitja a dump fájlt, és letölti a hibakereséshez szükséges szimbólumokat egy helyi mappából vagy az internetről. A folyamat során nem használhatja a WinDBG-t. Az ablak alján (a hibakereső parancssorban) megjelenik az üzenet Debugee nincs csatlakoztatva.

A parancsok az ablak alján található parancssorba kerülnek.

A legfontosabb dolog, amire figyelni kell, az a hibakód, amelyet mindig jeleznek hexadecimális értékés úgy néz ki 0xXXXXXXXXX(az egyik opcióban jelezve - STOP: , 2019.02.07. 0008F, 0x8F). Példánkban a hibakód 0x139.

A hibakereső felajánlja az!analyze -v parancs futtatását, csak vigye az egeret a hivatkozásra, és kattintson. Mire való ez a parancs?

• Előzetes memóriakiírás-elemzést végez, és biztosítja részletes információk az elemzés megkezdéséhez.
• Ez a parancs megjeleníti a STOP kódot és a hiba szimbolikus nevét.
• Az összeomláshoz vezető parancshívások halmazát mutatja.
• Ezen kívül itt jelennek meg az IP-címek, a folyamat- és regiszterhibák.
• A csapat kész javaslatokat tud adni a probléma megoldására.

A főbb pontok, amelyekre figyelni kell az!analyze –v parancs végrehajtása utáni elemzéskor (a felsorolás hiányos).

1: kd> !analyze -v

* *
* Hibaellenőrzési elemzés *
* *
*****************************************************************************
A STOP hiba szimbolikus neve (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
A hiba leírása (Egy kernelkomponens megsértett egy kritikus adatszerkezetet. Ez a sérülés lehetővé teheti, hogy a támadó átvegye az irányítást a gép felett):

Egy kernel-összetevő megrongált egy kritikus adatszerkezetet. A korrupció potenciálisan lehetővé teheti egy rosszindulatú felhasználó számára, hogy átvegye az irányítást a gép felett.
Hiba argumentumok:

Érvek:
Arg1: 0000000000000003, A LIST_ENTRY megsérült (azaz dupla eltávolítás).
Arg2: ffffd0003a20d5d0, A hibaellenőrzést okozó kivétel csapdakeretének címe
Arg3: ffffd0003a20d528, a hibaellenőrzést okozó kivétel kivételrekordjának címe
Arg4: 000000000000000, fenntartva
Hibakeresés részletei:
------------------

A számláló azt mutatja, hogy a rendszer hányszor omlott össze hasonló hibával:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

STOP hibakód rövidített formátumban:

BUGCHECK_STR: 0x139

A folyamat, amelynek során a hiba bekövetkezett (nem feltétlenül a hiba oka, csak a hiba időpontjában ez a folyamat futott a memóriában):

PROCESS_NAME: sqlservr.exe

Hibakód leírása: A rendszer verempuffer túlcsordulást észlelt ebben az alkalmazásban, ami lehetővé teheti a támadó számára, hogy átvegye az irányítást az alkalmazás felett.

ERROR_CODE: (NTSTATUS) 0xc0000409 – A rendszer egy veremalapú puffer túlcsordulását észlelte ebben az alkalmazásban. Ez a túllépés lehetővé teheti egy rosszindulatú felhasználó számára, hogy átvegye az irányítást az alkalmazás felett.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 – A rendszer egy veremalapú puffer túlcsordulását észlelte ebben az alkalmazásban. Ez a túllépés lehetővé teheti egy rosszindulatú felhasználó számára, hogy átvegye az irányítást az alkalmazás felett.

Utolsó hívás a veremben:

LAST_CONTROL_TRANSFER: fffff8040117d6a9-ről fffff8040116b0a0-ra

Verem hívása a hiba idején:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`B28:20nt!
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: CheckiisBpatch nt!
ffffd000`3a20d3f0 ffff804`0117c150: 00000000`00000000 00000000`00000000 00000000`00000000 000000000 000000000 000000000 000000000 000000000 xd 0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`0000006fffff804`0000006f90
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951: ?? ::FNODOBFM::`karakterlánc"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c60
ffffd000`3a20d990 fffff804`0117d313: ffffffff`ffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380:64Fintle+0txrite
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 000000000 0000000000x13
000 000 307da

A kód szakasz, ahol a hiba történt:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr ,0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: Géptulajdonos

A modul neve a kernel objektumtáblájában. Ha az elemző képes észlelni egy problémás illesztőprogramot, akkor a név megjelenik a MODULE_NAME és az IMAGE_NAME mezőben:

MODULE_NAME:nt
IMAGE_NAME: ntkrnlmp.exe

1: kd> lmvm nt
Böngésszen a teljes modullistában
Betöltött szimbólum képfájl: ntkrnlmp.exe
Leképezett memóriaképfájl: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
A kép elérési útja: ntkrnlmp.exe
A kép neve: ntkrnlmp.exe
Belső név: ntkrnlmp.exe
Eredeti fájlnév: ntkrnlmp.exe
TermékVerzió: 6.3.9600.18946
Fájlverzió: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

A megadott példában az elemzés az ntkrnlmp.exe kernelfájlra mutatott. Ha a memóriakiíratási elemzés egy rendszer-illesztőprogramra (például win32k.sys) vagy egy kernelfájlra mutat (mint az ntkrnlmp.exe példánkban), akkor az valószínűleg ez a fájl nem a probléma oka. Nagyon gyakran kiderül, hogy a probléma az eszközillesztőben van, BIOS beállítások vagy a berendezés meghibásodása.

Ha azt látja, hogy a BSOD-t egy harmadik féltől származó illesztőprogram okozta, a neve megjelenik a MODULE_NAME és az IMAGE_NAME értékekben.

Például:

A kép elérési útja: \SystemRoot\system32\drivers\cmudaxp.sys
Kép neve: cmudaxp.sys

Nyissa meg az illesztőprogram fájl tulajdonságait, és ellenőrizze a verzióját. A legtöbb esetben az illesztőprogramokkal kapcsolatos probléma megoldódik azok frissítésével.