W momencie krytycznej awarii system operacyjny Windows przerywa i wyświetla niebieski ekran śmierci (BSOD). Zawartość pamięci RAM i wszystkie informacje o występującym błędzie są zapisywane w pliku strony. Przy następnym uruchomieniu systemu Windows tworzony jest zrzut awaryjny z informacjami debugowania na podstawie zapisanych danych. Rekord błędu krytycznego jest tworzony w dzienniku zdarzeń systemowych.
Uwaga! Zrzut awaryjny nie jest tworzony, jeśli podsystem dyskowy ulegnie awarii lub wystąpi błąd krytyczny podczas początkowej fazy uruchamiania systemu Windows.Treść
- Rodzaje zrzutów awarii systemu Windows
- Jak włączyć tworzenie zrzutu pamięci w systemie Windows?
- Instalowanie WinDBG w systemie Windows
- Konfigurowanie powiązania plików .dmp z WinDBG
- Konfigurowanie serwera symboli debugowania w WinDBG
- Analiza zrzutu awaryjnego w WinDBG
Rodzaje zrzutów awarii systemu Windows
Korzystając z bieżącego systemu operacyjnego Windows 10 (Windows Server 2016) jako przykładu, rozważ główne typy zrzutów pamięci, które system może utworzyć:
- Mini zrzut pamięci (256 KB) Ten typ pliku zawiera minimalną ilość informacji. Zawiera tylko komunikat o błędzie BSOD, informacje o sterownikach, procesach, które były aktywne w momencie awarii oraz który proces lub wątek jądra spowodował awarię.
- Zrzut pamięci jądra. Z reguły mały rozmiar - jedna trzecia pamięci fizycznej. Zrzut pamięci jądra jest bardziej szczegółowy niż mini zrzut. Zawiera informacje o sterownikach i programach w trybie jądra, zawiera pamięć przydzieloną do jądra systemu Windows i warstwy abstrakcji sprzętu (HAL), a także pamięć przydzieloną sterownikom i innym programom w trybie jądra.
- Pełny zrzut pamięci. Największy wolumen i wymaga pamięci równej pamięci RAM systemu plus 1 MB, która jest niezbędna do utworzenia tego pliku przez system Windows.
- Automatyczny zrzut pamięci. Odpowiada zrzutowi pamięci podstawowej pod względem informacji. Różni się tylko tym, ile miejsca zajmuje do utworzenia pliku zrzutu. Ten typ pliku nie istniał w systemie Windows 7. Został dodany w systemie Windows 8..
- Aktywny zrzut pamięci. Ten typ odfiltrowuje elementy, które nie mogą ustalić przyczyny awarii systemu. Zostało to dodane w systemie Windows 10 i jest szczególnie przydatne, jeśli używasz maszyny wirtualnej lub jeśli twój system jest hostem Hyper-V..
Jak włączyć tworzenie zrzutu pamięci w systemie Windows?
Korzystając z Win + Pause, otwórz okno z parametrami systemowymi, wybierz „Dodatkowe parametry systemowe„(Zaawansowane ustawienia systemu). W zakładce”Opcjonalnie„(Zaawansowane), sekcja”Pobierz i przywróć„Kliknij (Uruchamianie i odzyskiwanie)”Parametry„(Ustawienia). W oknie, które zostanie otwarte, skonfiguruj akcję w przypadku awarii systemu. Zaznacz pole„Zapisz zdarzenia w dzienniku systemowym„(Zapisz zdarzenie w dzienniku systemowym), wybierz typ zrzutu, który powinien zostać utworzony, gdy system ulegnie awarii. Jeśli w polu wyboru”Zastąp istniejący plik zrzutu„Pole wyboru (Zastąp istniejący plik), plik będzie zastępowany za każdym razem, gdy się zawiesi. Lepiej odznaczyć to pole, wtedy będziesz mieć więcej informacji do analizy. Wyłącz także automatyczne ponowne uruchomienie systemu (automatyczne ponowne uruchomienie).
W większości przypadków wystarczy mały zrzut pamięci, aby przeanalizować przyczynę BSOD..
Teraz, gdy wystąpi BSOD, możesz przeanalizować plik zrzutu i znaleźć przyczynę niepowodzenia. Domyślny mini zrzut jest zapisywany w folderze% systemroot% \ minidump. Aby przeanalizować plik zrzutu, zalecam użycie programu Windbg (Debuger jądra Microsoft).
Instalowanie WinDBG w systemie Windows
Utility Windbg zawarty w „Zestaw Windows 10 SDK„(Windows 10 SDK). Pobierz tutaj..
Plik nazywa się winsdksetup.exe, rozmiar 1.3 MB.
WinDBG dla Windows7 i wcześniejszych systemów znajduje się w pakiecie „Microsoft Windows SDK dla Windows 7 i .NET Framework 4”. Pobierz tutaj.Uruchom instalację i wybierz, co należy zrobić - zainstaluj pakiet na tym komputerze lub pobierz go w celu instalacji na innych komputerach. Zainstaluj pakiet na komputerze lokalnym.
Możesz zainstalować cały pakiet, ale aby zainstalować tylko narzędzie do debugowania, wybierz Narzędzia do debugowania dla systemu Windows.
Po instalacji skróty WinDBG można znaleźć w menu Start.
Konfigurowanie powiązania plików .dmp z WinDBG
Aby otworzyć pliki zrzutu jednym kliknięciem, powiąż rozszerzenie .dmp z narzędziem WinDBG.
- Otwórz wiersz polecenia jako administrator i uruchom polecenia dla systemu 64-bitowego:
cd C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x64
windbg.exe -IA
dla systemu 32-bitowego:C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x86
windbg.exe -IA - W rezultacie typy plików: .DMP, .HDMP, .MDMP, .KDMP, .WEW - zostaną zamapowane na WinDBG.
Konfigurowanie serwera symboli debugowania w WinDBG
Symbole debugowania (symbole debugowania lub pliki symboli) to bloki danych generowane podczas kompilacji programu wraz z plikiem wykonywalnym. Takie bloki danych zawierają informacje o nazwach zmiennych, zwanych funkcjami, bibliotekach itp. Te dane nie są potrzebne podczas uruchamiania programu, ale są przydatne podczas debugowania. Komponenty Microsoft kompilują się ze znakami dystrybuowanymi przez Microsoft Symbol Server.
Skonfiguruj WinDBG do korzystania z Microsoft Symbol Server:
- Otwórz WinDBG;
- Idź do menu Plik -> Ścieżka do pliku symboli;
- Zapisz wiersz zawierający adres URL do pobierania symboli debugowania ze strony internetowej Microsoft oraz folder do zapisywania pamięci podręcznej:
SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbolsW tym przykładzie pamięć podręczna jest ładowana do folderu E: \ Sym_WinDBG, możesz podać dowolny. - Pamiętaj, aby zapisać zmiany w menu. Plik -> Zapisz WorkSpace;
WinDBG wyszuka znaki w folderze lokalnym, a jeśli nie znajdzie w nim niezbędnych znaków, samodzielnie pobierze znaki z określonej witryny. Jeśli chcesz dodać własny folder z symbolami, możesz to zrobić w następujący sposób:
SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbols; c: \ Symbole
Jeśli nie ma połączenia z Internetem, najpierw pobierz pakiet symboli z zasobu Windows Symbol Packages..
Analiza zrzutu awaryjnego w WinDBG
Debuger WinDBG otwiera plik zrzutu i pobiera niezbędne symbole do debugowania z folderu lokalnego lub z Internetu. Podczas tego procesu nie można używać programu WinDBG. W dolnej części okna (w wierszu poleceń debuggera) pojawia się Debugee nie podłączony.
Polecenia są wprowadzane w wierszu poleceń znajdującym się w dolnej części okna.
Najważniejszą rzeczą, na którą należy zwrócić uwagę, jest kod błędu, który jest zawsze wskazywany w wartości szesnastkowej i ma postać 0xXXXXXXXXX (wskazany w jednej z opcji - STOP: 0x0000007B, 07/02/2019 0008F, 0x8F). W naszym przykładzie kod błędu 0x139.
Pełny przewodnik po błędach można znaleźć tutaj..Debuger oferuje uruchomienie polecenia! Analizuj -v, po prostu najedź kursorem na link i kliknij. Do czego służy to polecenie??
- Przeprowadza wstępną analizę zrzutu pamięci i dostarcza szczegółowych informacji, aby rozpocząć analizę..
- To polecenie wyświetla kod zatrzymania i symboliczną nazwę błędu..
- Pokazuje stos wywołań poleceń, które doprowadziły do awarii..
- Ponadto wyświetlane są tutaj nieprawidłowości w działaniu adresu IP, przetwarzania i rejestracji..
- Zespół może dostarczyć gotowe zalecenia dotyczące rozwiązania problemu..
Główne punkty, na które należy zwrócić uwagę podczas analizy po uruchomieniu polecenia! Analyze -v (lista jest niepełna).
1: kd> !analizować -v
***************************************************** ****************************
* * *
* Analiza błędów *
* * *
***************************************************** ****************************
Symboliczna nazwa błędu STOP (BugCheck)KERNEL_SECURITY_CHECK_FAILURE (139)
Opis błędu (składnik jądra uszkodził krytyczną strukturę danych. Uszkodzenie to może potencjalnie umożliwić osobie atakującej przejęcie kontroli nad tym komputerem):
Komponent jądra uszkodził krytyczną strukturę danych. Uszkodzenie może potencjalnie umożliwić złośliwemu użytkownikowi przejęcie kontroli nad tym komputerem.
Argumenty za błędem to:
Argumenty:
Arg1: 0000000000000003, LIST_ENTRY został uszkodzony (tj. Podwójne usunięcie).
Arg2: ffffd0003a20d5d0, Adres ramki pułapki dla wyjątku, który spowodował kontrolę błędów
Arg3: ffffd0003a20d528, Adres rekordu wyjątku dla wyjątku, który spowodował kontrolę błędów
Arg4: 0000000000000000, Zarezerwowane
Szczegóły debugowania:
------------------
Licznik pokazuje, ile razy system rozbił się z podobnym błędem:
CUSTOMER_CRASH_COUNT: 1
Główna kategoria bieżącej awarii:
DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY
Kod błędu STOP w skróconym formacie:
BUGCHECK_STR: 0x139
Proces, podczas którego wystąpiła awaria (niekoniecznie przyczyna błędu, właśnie w momencie awarii w pamięci proces ten został wykonany):
PROCESS_NAME: sqlservr.exe
CURRENT_IRQL: 2
Deszyfrowanie kodu błędu: W tej aplikacji system wykrył przepełnienie buforu stosu, które może pozwolić osobie atakującej na przejęcie kontroli nad tą aplikacją.
ERROR_CODE: (NTSTATUS) 0xc0000409 - System wykrył przekroczenie bufora stosu w tej aplikacji. To przekroczenie może potencjalnie umożliwić złośliwemu użytkownikowi przejęcie kontroli nad tą aplikacją.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - System wykrył przekroczenie bufora stosu w tej aplikacji. To przekroczenie może potencjalnie umożliwić złośliwemu użytkownikowi przejęcie kontroli nad tą aplikacją.
Ostatnie sprawdzenie na stosie:
LAST_CONTROL_TRANSFER: od fffff8040117d6a9 do fffff8040116b0a0
Stos wywołań w momencie awarii:
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'0000000000000000'00000000 00000000'00000000 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'00000000000000eb'a0cf1380: 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
Część kodu, w której wystąpił błąd:
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
Nazwa modułu w tabeli obiektów jądra. Jeśli analizator był w stanie wykryć problemowy sterownik, nazwa jest wyświetlana w polach MODULE_NAME i IMAGE_NAME:
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
Kliknięcie łącza modułu (nt) spowoduje wyświetlenie szczegółowych informacji o ścieżce i innych właściwościach modułu. Znajdź określony plik i przestudiuj jego właściwości.
1: kd> lmvm ntPrzeglądaj pełną listę modułów
Załadowany plik obrazu symbolu: ntkrnlmp.exe
Odwzorowany plik obrazu pamięci: C: \ ProgramData \ dbg \ sym \ ntoskrnl.exe \ 5A9A2147787000 \ ntoskrnl.exe
Ścieżka obrazu: ntkrnlmp.exe
Nazwa obrazu: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
Wersja produktu: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)
W powyższym przykładzie analiza wskazała na plik jądra ntkrnlmp.exe. Gdy analiza zrzutu pamięci wskazuje sterownik systemu (na przykład win32k.sys) lub plik jądra (jak w naszym przykładzie ntkrnlmp.exe), najprawdopodobniej ten plik nie jest przyczyną problemu. Często okazuje się, że problem leży w sterowniku urządzenia, ustawieniach BIOS-u lub awarii sprzętu.
Jeśli zauważyłeś, że BSOD był spowodowany przez sterownik innej firmy, jego nazwa zostanie podana w wartościach MODULE_NAME i IMAGE_NAME.
Na przykład:
Ścieżka obrazu: \ SystemRoot \ system32 \ drivers \ cmudaxp.sys
Nazwa obrazu: cmudaxp.sys
Otwórz właściwości pliku sterownika i sprawdź jego wersję. W większości przypadków problem ze sterownikami rozwiązuje się poprzez ich aktualizację..
