V době kritického selhání operační systém Windows přeruší a zobrazí modrou obrazovku smrti (BSOD). Obsah paměti RAM a veškeré informace o chybě, která nastane, jsou zaznamenány v souboru stránky. Při příštím spuštění systému Windows je vytvořen výpis havárie s ladícími informacemi založenými na uložených datech. V protokolu systémových událostí je vytvořen záznam kritických chyb.
Pozor! Havarijní výpis není vytvořen, pokud selže diskový subsystém nebo dojde-li ke kritické chybě během počáteční fáze spouštění systému Windows.Obsah:
- Typy výpisů Windows Crash
- Jak povolit vytváření výpisu paměti ve Windows?
- Instalace WinDBG na Windows
- Konfigurace přidružení souborů .dmp k WinDBG
- Konfigurace serveru symbolů ladění ve WinDBG
- Havarijní analýza výpisu ve WinDBG
Typy výpisů Windows Crash
Jako příklad použijte aktuální operační systém Windows 10 (Windows Server 2016), zvažte hlavní typy výpisů paměti, které může systém vytvořit:
- Mini výpis paměti (256 KB) Tento typ souboru obsahuje minimální množství informací. Obsahuje pouze chybovou zprávu BSOD, informace o ovladačích, procesech, které byly aktivní v době havárie a který proces nebo jádro vlákna způsobilo havárii.
- Výpis paměti jádra. Zpravidla malá velikost - jedna třetina fyzické paměti. Výpis paměti jádra je podrobnější než výpis mini. Obsahuje informace o ovladačích a programech v režimu jádra, obsahuje paměť přidělenou jádru Windows a hardwarovou abstrakční vrstvu (HAL), stejně jako paměť přidělenou ovladačům a dalším programům v režimu jádra.
- Kompletní výpis paměti. Největší objem a vyžaduje paměť rovnající se RAM vašeho systému plus 1 MB, což je nezbytné pro Windows k vytvoření tohoto souboru.
- Automatický výpis paměti. Odpovídá výpisu základní paměti, pokud jde o informace. Liší se pouze tím, kolik místa používá k vytvoření souboru výpisu. Tento typ souboru v systému Windows 7 neexistoval. Byl přidán do systému Windows 8..
- Výpis aktivní paměti. Tento typ odfiltruje položky, které nemohou určit příčinu selhání systému. Toto bylo přidáno v systému Windows 10 a je zvláště užitečné, pokud používáte virtuální stroj nebo pokud je váš systém hostitelem Hyper-V..
Jak povolit vytváření výpisu paměti ve Windows?
Pomocí Win + Pause otevřete okno se systémovými parametry, vyberte „Další systémové parametry"(Pokročilá nastavení systému). Na kartě"Volitelné"(Upřesnit), oddíl"Stahujte a obnovujte„(Startup and Recovery) klikněte na“Parametry"(Nastavení). V okně, které se otevře, nakonfigurujte akci v případě selhání systému. Zaškrtněte políčko"Zápis událostí do systémového protokolu"(Zápis události do systémového protokolu), vyberte typ výpisu, který by měl být vytvořen při selhání systému. Pokud je zaškrtnuto políčko"Nahraďte existující soubor výpisu"(Přepsat jakýkoli existující soubor), pak bude soubor přepsán pokaždé, když dojde ke zhroucení. Je lepší zrušit zaškrtnutí tohoto políčka, pak budete mít více informací k analýze. Vypněte také automatický restart.
Ve většině případů vám stačí malý výpis paměti pro analýzu příčiny BSOD..
Nyní, když dojde k BSOD, můžete analyzovat soubor výpisu a najít příčinu selhání. Výchozí mini výpis je uložen ve složce% systemroot% \ minidump. K analýze souboru výpisu doporučujeme použít program Windbg (Ladicí program jádra Microsoft).
Instalace WinDBG na Windows
Nástroj Windbg součástí "Windows 10 SDK"(Windows 10 SDK). Stáhněte si zde..
Soubor se nazývá winsdksetup.exe, velikost 1,3 MB.
WinDBG pro Windows7 a starší systémy je součástí balíčku „Microsoft Windows SDK pro Windows 7 a .NET Framework 4“. Stáhněte si zde.Spusťte instalaci a vyberte, co je třeba udělat - nainstalujte balíček do tohoto počítače nebo si jej stáhněte pro instalaci do jiných počítačů. Nainstalujte balíček do místního počítače.
Můžete nainstalovat celý balíček, ale chcete-li nainstalovat pouze nástroj pro ladění, vyberte Ladicí nástroje pro Windows.
Po instalaci najdete zástupce WinDBG v nabídce Start.
Konfigurace přidružení souborů .dmp k WinDBG
Chcete-li otevřít soubory výpisu jednoduchým kliknutím, přidružte příponu .dmp k nástroji WinDBG.
- Otevřete příkazový řádek jako správce a spusťte příkazy pro 64bitový systém:
cd C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x64
windbg.exe -IA
pro 32bitový systém:C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x86
windbg.exe -IA - V důsledku toho budou typy souborů: .DMP, .HDMP, .MDMP, .KDMP, .WEW - mapovány do WinDBG.
Konfigurace serveru symbolů ladění ve WinDBG
Ladicí symboly (ladicí symboly nebo soubory symbolů) jsou datové bloky generované během kompilace programu společně s spustitelným souborem. Tyto datové bloky obsahují informace o názvech proměnných, tzv. Funkcích, knihovnách atd. Tato data nejsou při spuštění programu potřebná, ale jsou užitečná při ladění. Komponenty společnosti Microsoft se kompilují se znaky distribuovanými prostřednictvím serveru Microsoft Symbol.
Nakonfigurujte WinDBG tak, aby používal Microsoft Symbol Server:
- Otevřete WinDBG;
- Přejděte do nabídky Soubor -> Cesta souboru symbolu;
- Napište řádek obsahující adresu URL pro stahování ladících symbolů z webu společnosti Microsoft a složku pro uložení mezipaměti:
SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbolsV příkladu je mezipaměť načtena do složky E: \ Sym_WinDBG, můžete zadat libovolnou. - Nezapomeňte uložit změny do nabídky. Soubor -> Uložit WorkSpace;
WinDBG bude hledat znaky v místní složce a pokud nenajde potřebné znaky v něm, stáhne znaky z určeného webu samostatně. Pokud chcete přidat vlastní složku se symboly, můžete to udělat takto:
SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbols; c: \ Symbols
Pokud není k dispozici připojení k internetu, stáhněte si nejprve sadu symbolů ze zdroje Windows Symbol Packages..
Havarijní analýza výpisu ve WinDBG
Ladicí program WinDBG otevře soubor výpisu a stáhne potřebné symboly pro ladění z místní složky nebo z Internetu. Během tohoto procesu nelze použít program WinDBG. Ve spodní části okna (na příkazovém řádku debuggeru) se zobrazí Debuga není připojena.
Příkazy se zadávají do příkazového řádku umístěného ve spodní části okna.
Nejdůležitější věcí, které je třeba věnovat pozornost, je chybový kód, který je vždy uveden v hexadecimální hodnotě a má tvar 0xXXXXXXXXX (uvedeno v jedné z možností - STOP: 0x0000007B, 07/02/2019 0008F, 0x8F). V našem příkladu kód chyby 0x139.
Úplný průvodce chybami naleznete zde..Ladicí program nabízí spuštění příkazu! Analyzovat -v, stačí umístit kurzor nad odkaz a kliknout. K čemu je tento příkaz??
- Provádí předběžnou analýzu výpisu paměti a poskytuje podrobné informace pro zahájení analýzy..
- Tento příkaz zobrazí kód zastavení a symbolický název chyby..
- Zobrazuje hromadu příkazových volání, která vedla k havárii..
- Kromě toho se zde zobrazí IP adresa, proces a registrace chyb..
- Tým může poskytnout hotová doporučení pro řešení problému..
Hlavní body, kterým byste měli věnovat pozornost při analýze po spuštění příkazu! Analyze -v (výpis je neúplný).
1: kd> !analyzovat -v
******************************************************** ********************************
* * *
* Analýza chyb *
* * *
******************************************************** ********************************
Symbolický název chyby STOP (BugCheck)KERNEL_SECURITY_CHECK_FAILURE (139)
Popis chyby (Komponenta jádra poškodila strukturu kritických dat. Toto poškození by potenciálně mohlo útočníkovi umožnit získat kontrolu nad tímto počítačem):
Komponenta jádra poškodila strukturu kritických dat. Poškození by potenciálně mohlo uživateli se zlými úmysly získat kontrolu nad tímto počítačem.
Argumenty chyby jsou:
Argumenty:
Arg1: 0000000000000003, A LIST_ENTRY byl poškozen (tj. Dvojité odebrání).
Arg2: ffffd0003a20d5d0, Adresa rámečku pasti pro výjimku, která způsobila chybu
Arg3: ffffd0003a20d528, Adresa záznamu výjimky pro výjimku, která způsobila chybu
Arg4: 0000000000000000, vyhrazeno
Podrobnosti ladění:
------------------
Počitadlo ukazuje, kolikrát systém havaroval s podobnou chybou:
CUSTOMER_CRASH_COUNT: 1
Hlavní kategorie současného selhání:
DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY
Chybový kód STOP ve zkráceném formátu:
BUGCHECK_STR: 0x139
Proces, během kterého došlo k selhání (ne nutně příčina chyby, právě v době selhání v paměti byl tento proces proveden):
PROCESS_NAME: sqlservr.exe
CURRENT_IRQL: 2
Dešifrování kódu chyby: V této aplikaci systém detekoval přetečení zásobníku zásobníku, což může útočníkovi umožnit získat kontrolu nad touto aplikací..
ERROR_CODE: (NTSTATUS) 0xc0000409 - Systém zjistil v této aplikaci přetečení zásobníku na vyrovnávací paměti. Toto překročení by potenciálně mohlo uživateli se zlými úmysly získat kontrolu nad touto aplikací.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - Systém zjistil v této aplikaci přetečení zásobníku na vyrovnávací paměti. Toto překročení by potenciálně mohlo uživateli se zlými úmysly získat kontrolu nad touto aplikací.
Poslední hovor v zásobníku:
LAST_CONTROL_TRANSFER: od fffff8040117d6a9 do fffff8040116b0a0
Zásobník hovorů v době selhání:
STACK_TEXT:
ffffd000'3a20d2a8 fffff804'0117d6a9: 00000000'00000139 00000000'00000003 ffffd000'3a20d5d0 ffffd000'3a20d528: nt! KeBugCheckEx
ffffd000'3a20d2b0 fffff804'0117da50: ffffe000'f3ab9080 ffffe000'fc37e001 ffffd000'3a20d5d0 fffff804'0116e2a2: nt! KiBugCheckDispatch + 0x69
ffffd000'3a20d3f0 fffff804'0117c150: 00000000'000000000000000000000000000000 00000000'000000 00000000'00000000: nt! KiFastFailDispatch + 0xd0
ffffd000'3a20d5d0 fffff804'01199482: ffffc000'701ba270 ffffc000'00000001 000000ea'73f68040 fffff804'000006f9: nt! KiRaiseSecurityCheckFailure + 0x3d0
ffffd000'3a20d760 fffff804'014a455d: 00000000'00000001 ffffd000'3a20d941 ffffe000'fcacb000 ffffd000'3a20d951: nt! ?? :: FNODOBFM :: 'string' + 0x17252
ffffd000'3a20d8c0 fffff804'013a34ac: 00000000'00000004 00000000'00000000 ffffd000'3a20d9d8 ffffe001'0a34c600: nt! IopSynchronousServiceTail + 0x379
ffffd000'3a20d990 fffff804'0117d313: ffffffff'fffffffe 00000000'00000000 00000000'0000000000000000''0cf1380: nt! NtWriteFile + 0x694
ffffd000'3a20da90 00007ffb'475307da: 00000000'00000000 00000000'00000000 00000000'00000000 00000000'00000000: nt! KiSystemServiceCopyEnd + 0x13
000000ee'f25ed2b8 00000000'00000000: 00000000'00000000 00000000'00000000 00000000'00000000 00000000'00000000: 0x00007ffb'475307da
Část kódu, kde došlo k chybě:
FOLLOWUP_IP:
nt! KiFastFailDispatch + d0
fffff804'0117da50 c644242000 mov byte ptr [rsp + 20h], 0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt! KiFastFailDispatch + d0
FOLLOWUP_NAME: MachineOwner
Název modulu v tabulce objektů jádra. Pokud analyzátor dokázal detekovat problémový ovladač, název se zobrazí v polích MODULE_NAME a IMAGE_NAME:
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
Pokud kliknete na odkaz na modul (nt), zobrazí se podrobné informace o cestě a dalších vlastnostech modulu. Vyhledejte určený soubor a prostudujte jeho vlastnosti.
1: kd> lmvm ntProcházet úplný seznam modulů
Načtený soubor se symbolem obrázku: ntkrnlmp.exe
Soubor mapované paměti: C: \ ProgramData \ dbg \ sym \ ntoskrnl.exe \ 5A9A2147787000 \ ntoskrnl.exe
Cesta obrázku: ntkrnlmp.exe
Název fotografie: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)
Ve výše uvedeném příkladu analýza poukázala na soubor jádra ntkrnlmp.exe. Když analýza výpisu paměti ukazuje na systémový ovladač (například win32k.sys) nebo soubor jádra (jako v našem příkladu ntkrnlmp.exe), nejspíše tento soubor není příčinou problému. Často se ukazuje, že problém spočívá v ovladači zařízení, nastavení systému BIOS nebo selhání hardwaru.
Pokud jste viděli, že BSOD byl způsoben ovladačem třetí strany, bude jeho název uveden v hodnotách MODULE_NAME a IMAGE_NAME.
Například:
Cesta obrazu: \ SystemRoot \ system32 \ drivers \ cmudaxp.sys
Název fotografie: cmudaxp.sys
Otevřete vlastnosti souboru ovladače a zkontrolujte jeho verzi. Ve většině případů je problém s ovladači vyřešen jejich aktualizací..
