Jeśli masz tzw. niebieski ekranśmierci w Windowsie 10 i jesteś gotowy zapaść w nerwową śpiączkę, zebrać się w sobie i spróbować rozwiązać problem. Na początek warto powiedzieć, że ta złowieszcza wiadomość sygnalizuje krytyczny błąd systemu. Co więcej, nie zawsze można uchwycić moment i mieć czas na odczytanie kodu błędu, gdy system Windows wpada na niebieski ekran śmierci i urządzenie uruchamia się ponownie. Od razu zauważamy, że istnieje duża ilość rozwiązania tego problemu, a także przyczyny niebieskiego ekranu. W tym artykule postaramy się rozważyć prawdopodobne przyczyny pojawienie się niebieskiego ekranu szczęścia, a także około możliwe rozwiązania Problemy.

W zdecydowanej większości przypadków niebieski ekran śmierci sygnalizuje błąd BAD_POOL_CALLER - stop 0x000000c2. Szczerze mówiąc trudno jest zdiagnozować ten błąd, ale możliwe, że postaramy się opisać algorytm Twoich kolejnych działań na przykładzie tego błędu.

Aby poprawnie zdiagnozować problem, musisz najpierw przeanalizować plik specjalny system o nazwie minidump (zrzut pamięci). Utworzenie takich plików prowadzi do awarii systemu, ponadto mogą nas poinformować – co dokładnie doprowadziło do awarii.

1. Aby włączyć takie automatyczne nagrywanie małego zrzutu pamięci (domyślnie wyłączone), przejdź do właściwości komputera i przejdź do sekcji " Dodatkowe opcje systemy” (to włączenie dotyczy wszystkich systemów, nie tylko Windows 10):

Z reguły wszystkie pliki minidump są zapisywane po wystąpieniu niebieskiego ekranu śmierci (BSOD) i można je znaleźć w folderze C:\Windows\Minidump. Warto zauważyć, że nazwa pliku zawiera Aktualna data- kiedy został utworzony, co znacznie ułatwia określenie daty wystąpienia błędu, zwłaszcza biorąc pod uwagę, że może istnieć więcej niż jeden taki plik.

Dwa sposoby na odszyfrowanie minizrzutu pamięci małej damy

Pierwszy sposób, jest użycie dość popularnego narzędzia BlueScreenView. To narzędzie może być również dobrą opcją do analizy zrzutu pamięci. Użycie tego narzędzia przydaje się jako sposób na zidentyfikowanie problematycznego sterownika.

Co więcej, jest to szczególnie godne uwagi, ponieważ można go używać do wyświetlania BSOD (niebieski ekran śmierci) tak, jak w zamrożonej ramce, tak jak miało to miejsce podczas awarii systemu. Wyświetla czas i datę awarii, szczegóły sterownika lub modułu wraz z wersją i krótki opis. Ponadto narzędzie jest dostępne w wielu językach, w tym w języku rosyjskim. Tak więc narzędzie BlueScreenView jest właśnie tym, jeśli chcesz szybko analizować zrzuty pamięci podczas BSOD.

Do druga droga musisz zainstalować Debugging Tools for Windows, a także pobrać narzędzie bsdos_utility. Ponadto po rozpakowaniu skryptu bsdos_utility.cmd należy go przenieść na dysk C:\ (można utworzyć osobny folder, ale pamiętaj, że ciąg adresu uruchamiania skryptu będzie inny niż w naszym przykładzie). Następnie w wierszu poleceń napisz:

C:\bsdos_utility.cmd

Po wyświetleniu listy wszystkich zrzutów z listy C:\Windows\Minidump\, po czym skrypt zapyta, który zrzut ma być analizowany. Możesz także samodzielnie wybrać żądany minizrzut podczas uruchamiania skryptu:

W ten sposób możliwe jest wykrycie masy Błędy systemu Windows 10, który spowodował BSOD, a także problematyczne programy .exe, które powodowały niebieski ekran.

W kolejnym kroku wyboru komponentów do zainstalowania ( Wybierz funkcje, które chcesz zainstalować) zaznacz tylko to, czego potrzebujemy - Narzędzia do debugowania dla Windowsa i naciśnij zainstalować

Zestaw narzędzi zostanie pobrany i zainstalowany z Internetu w folderze określonym na pierwszym ekranie.

Po zakończeniu instalacji znajdujemy się w menu „Start” lub na ekranie startowym w grupie skrótów Zestawy Windows pożytek windbg i uruchom go z uprawnieniami administratora

Jeśli z jakiegoś powodu nie można znaleźć skrótu, możesz uruchomić plik wykonywalny z katalogu instalacyjnego - C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\windbg.exe

W menu głównym programu windbg wybierz przedmioty plik > Ścieżka do pliku symboli. W oknie, które się otworzy, wstaw linię określającą let do lokalnego katalogu pamięci podręcznej symboli i jej źródła online:

Zapisujemy ustawienia, wybierając pozycje w menu głównym plik > Zapisz obszar roboczy

Otwórz plik zrzutu pamięci, wybierając z menu plik > Otwórz zrzut awaryjny...

Wybierz plik PAMIĘĆ.DMP(domyślnie znajduje się w katalogu C:\Windows) i kliknij otwarty

Pojawi się informacja, który konkretny moduł wykonywalny spowodował, że system przestał działać. Klikając hiperłącze !analiza-v możesz uzyskać bardziej szczegółowe informacje o stanie systemu w momencie błędu zatrzymania.

Te same informacje można również uzyskać za pomocą wiersza poleceń, używając w przybliżeniu następującej sekwencji poleceń:

W tym przykładzie wszystkie informacje dotyczące analizy zrzutu zostaną zrzucone w czytelnej formie do pliku C:\Debuglog.txt

Źródła informacji:

Dzień dobry, drodzy koledzy i czytelnicy bloga. Dzisiaj chcę powiedzieć, jak przeanalizować zrzut pamięci systemu Windows 10 Redstone. Odbywa się to w większości przypadków, gdy pojawia się niebieski ekran śmierci z błędem, po którym komputer uruchamia się ponownie. I ta analiza pomaga zrozumieć przyczynę niepowodzenia.

Konfigurowanie zrzutu pamięci systemu Windows 10

A więc czym jest zrzut pamięci w systemie operacyjnym Windows 10 Redstone. Opisałem ci powyżej popularny przypadek w którym pojawia się zrzut pamięci systemowej i są to niebieskie ekrany śmierci. Powody ich pojawienia się są bardzo rozległe:

• Niezgodność aplikacji
• Niezgodność sterownika
• Nowy aktualizacje systemu Windows
• Urządzenie niekompatybilne

To tylko mała uogólniona lista, ponieważ jest wiele kodów błędów z niebieskich ekranów, podam te najnowsze.

Naszym zadaniem jest odnalezienie tych plików do diagnostyki i umiejętność ich interpretacji w celu uzyskania informacji o problemie.

Gdzie jest skonfigurowany zrzut awaryjny systemu Windows 10?

Na początek zastanówmy się, gdzie dokonano ustawienia, które jest odpowiedzialne za zrzut pamięci awaryjnej systemu Windows 10. Kliknij prawym przyciskiem myszy przycisk Start systemu Windows 10 i od menu kontekstowe wybierz System.

W oknie System, które się otworzy, jesteś po lewej stronie górny róg wybierz Zaawansowane opcje systemu.

Tutaj jest konfigurowany zrzut pamięci systemu Windows 10. Kliknij element ustawień w Boot and Recovery.

Z ustawień, zrzut pamięci systemu Windows 10, chcę zauważyć, co następuje:

• Nagrywanie wydarzenia w syslog> tutaj informacja o niebieskim ekranie zostanie dodana do logów system operacyjny.
• Biegać automatyczny restart> kontynuować po błędzie
• Wpisz informacje debugowania > pozwala wybrać typ pliku zrzutu, więcej na ten temat poniżej.
• Zastąp istniejący plik zrzutu, przydatne pole wyboru, ponieważ te zrzuty mogą ważyć dziesiątki gigabajtów, jest to bardzo ważne w przypadku małych dysków SSD.

Rodzaje zrzutów pamięci

Przyjrzyjmy się, jak różnią się opcje rejestrowania informacji debugowania.

• Mały zrzut pamięci 256 KB: Pliki małego zrzutu pamięci zawierają następujące informacje:

– komunikat o błędzie krytycznym, jego parametry i inne dane;

– lista załadowanych sterowników;

– kontekst procesora ( ChRL) na którym wystąpiła awaria;

EPROCES) dla procesu, który spowodował błąd;

– informacje o procesie i kontekst jądra ( WĄTEK) dla wątku, który spowodował błąd;

– stos wywołań trybu jądra dla wątku, który spowodował błąd.

Jest używany, gdy masz bardzo mało miejsca na dysku na Twoim dysk lokalny. W ten sposób przekazujemy przydatna informacja, co może nie wystarczyć do zdiagnozowania niebieskiego ekranu.

Minidump jest przechowywany w ścieżce C:\Windows\Minidump

• Zrzut pamięci jądra > rejestruje tylko pamięć jądra. W zależności od ilości pamięci fizycznej komputera w tym przypadku plik stronicowania wymaga od 50 do 800 MB lub jedną trzecią pamięci fizycznej komputera na woluminie rozruchowym.
• Pełny zrzut pamięci > cóż, wszystko jasne z nazwy. Pisze absolutnie wszystko, to maksymalna informacja o niebieskim ekranie, daje stuprocentową diagnostykę problemu.

Znajduje się wzdłuż ścieżki C:\Windows\Memory.dmp

• Zrzut pamięci aktywnej > dostaje się tutaj pamięć aktywna maszyny hosta, jest to funkcja bardziej dla platform serwerowych, ponieważ można je wykorzystać do wirtualizacji i aby informacje o maszynach wirtualnych nie dostały się do zrzutu, ta opcja została wymyślona.

Ta krótka notatka ma na celu pokazanie, jak można skonfigurować system, aby uzyskać do swojej dyspozycji sytuację awaryjną wysypisko Pamięć Windows , czyli zrzut, który można utworzyć w przypadku krytycznej awarii, charakteryzujący się pojawieniem się niebieskiego ekranu śmierci (BSOD). Czym w ogóle jest zrzut, do czego jest nam potrzebny i czym jest, jakie problemy ma rozwiązać i jakie informacje zawiera?

Zrzut pamięci to zawartość pamięci roboczej procesu, jądra lub całego systemu operacyjnego, w tym, oprócz obszarów roboczych, Dodatkowe informacje o stanie rejestrów procesora, zawartości stosu i innych strukturach usług.

Dlaczego potrzebujemy tej treści, tj. Zrzut pamięci systemu Windows? Być może najczęstszy zrzut pamięci służy do zbadania przyczyn awarii systemu (), która spowodowała całkowite zatrzymanie systemu operacyjnego. Oprócz tego stan pamięci można wykorzystać do innych celów. Ważny jest również fakt, że zrzut pamięci jest dosłownie jedynym sposobem uzyskania informacji o jakiejkolwiek awarii! A usuwanie (odbieranie) zrzutu pamięci systemowej jest w rzeczywistości jedyną dokładną metodą uzyskania natychmiastowego wydruku (kopii) zawartości pamięci fizycznej systemu.

Im dokładniej zawartość zrzutu będzie odzwierciedlać stan pamięci w momencie wystąpienia awarii, tym lepiej będziemy mogli przeanalizować sytuację awaryjną. Dlatego niezwykle ważne jest uzyskanie dokładnie aktualnej kopii pamięci fizycznej systemu w ściśle pewien moment czas bezpośrednio przed katastrofą. Jedynym sposobem, aby to zrobić, jest utworzenie pełnego zrzutu awaryjnego. Powód jest dość banalny - gdy nastąpi awaryjny zrzut pamięci systemu, czy to w wyniku awarii, czy w wyniku sztucznie zasymulowanej sytuacji, system w tym momencie przejęcia kontroli nad funkcjami awaryjnymi (KeBugCheckEx) jest w stanie całkowicie niezmieniony (statyczny) stan, dlatego od momentu wystąpienia awarii do czasu zapisania danych na nośniku nic nie zmienia zawartości pamięci fizycznej i jest ona zapisywana na dysku w swoim pierwotnym stanie. Cóż, tak jest w teorii, ale czasami w życiu, ale zdarzają się sytuacje, że z powodu wadliwych podzespołów sprzętowych sam zrzut pamięci może ulec uszkodzeniu lub stacja może się zawiesić podczas procesu nagrywania zrzutu.

W zdecydowanej większości przypadków od momentu uruchomienia procesu tworzenia zrzutu awaryjnego do momentu zapisania zawartości pamięci na dysku informacje w pamięci pozostają niezmienione.

Teoretycznie statyczny (niezmienność) „odcisku” pamięci tłumaczy się tym, że w momencie wywołania funkcji KeBugCheckEx, która wyświetla informacje o awarii i rozpoczyna proces tworzenia zrzutu pamięci, system jest już całkowicie zatrzymany i zawartość pamięci fizycznej jest zapisywana do bloków zajmowanych na dysku przez plik stronicowania, po czym już podczas kolejnego rozruchu systemu operacyjnego jest zrzucana do pliku na nośniku systemowym. Otóż ​​prawie raz zaobserwowałem sytuację, w której awaria płyta główna nie pozwoliło na zapisanie zrzutu pamięci: a) zawieszanie się podczas działania logiki zapisu zrzutu (proces nie osiągnął 100%), b) uszkodzenie pliku zrzutu pamięci (przeklęte struktury debuggera), c) zapis memory.dmp zrzuć pliki o zerowej długości. Dlatego pomimo tego, że system był już całkowicie zatrzymany w momencie tworzenia zrzutu pamięci, a działa tylko kod awaryjny, wadliwy sprzęt może samodzielnie dostosować dowolną logikę bez wyjątku na dowolnym etapie działania.
Tradycyjnie na początkowym etapie do zapisania zrzutu pamięci systemu Windows wykorzystywane są bloki dyskowe przydzielone do pliku stronicowania (plik stronicowania). Następnie po pojawieniu się niebieskiego ekranu i ponownym uruchomieniu dane są przenoszone do oddzielnego pliku, a nazwa pliku jest zmieniana zgodnie ze wzorcem zależnym od typu zrzutu. Jednak począwszy od Wersje Windows Vista ten stan rzeczy można zmienić, teraz użytkownik ma możliwość zapisania dedykowanego zrzutu bez udziału pliku wymiany, umieszczając informacje o awarii w pliku tymczasowym. Zrobiono to w celu wyeliminowania błędów konfiguracyjnych związanych z nieprawidłowymi ustawieniami rozmiaru i pozycji pliku stronicowania, które często prowadziły do ​​problemów w procesie zapisywania zrzutu pamięci.
Zobaczmy, jakie rodzaje zrzutów system operacyjny Windows pozwala nam tworzyć:

• Zrzut pamięci procesu (aplikacja);
• Zrzut pamięci jądra;
• Pełny zrzut pamięci (zrzut dostępnej części pamięci fizycznej systemu).

Wszystkie zrzuty awaryjne można podzielić na dwie główne kategorie:

• Zrzuty awaryjne z informacjami o zgłoszonym wyjątku. Zwykle tworzone w tryb automatyczny, gdy w aplikacji / jądrze wystąpi nieobsłużony wyjątek i odpowiednio można wywołać debugger systemowy (wbudowany). W takim przypadku do zrzutu zapisywana jest informacja o wyjątku, co ułatwia określenie typu wyjątku i lokalizacji zdarzenia podczas późniejszej analizy.
• Zrzuty awaryjne bez informacji o wyjątkach. Zwykle tworzone przez użytkownika ręcznie, gdy konieczne jest stworzenie tylko migawki procesu do późniejszej analizy. Analiza ta nie implikuje określenia rodzaju wyjątku, ponieważ wyjątek nie wystąpił, ale analizę zupełnie innego rodzaju, na przykład badanie struktur danych procesowych i tak dalej.

Konfiguracja zrzutu jądra

Musisz być zalogowany jako administrator rachunek aby wykonać czynności opisane w tej sekcji.

Przejdźmy od razu do konfiguracji ustawień zrzutu awaryjnego systemu Windows. Najpierw musimy przejść do okna właściwości systemu w jeden z następujących sposobów:

1. Kliknij kliknij prawym przyciskiem myszy myszką na ikonie "Mój komputer" - "Właściwości" - "Zaawansowane ustawienia systemu" - "Zaawansowane".
2. Przycisk "Start" - "Panel sterowania" - "System" - "Zaawansowane ustawienia systemu" - "Zaawansowane".
3. Skrót klawiaturowy „Windows” + „Pauza” - „Zaawansowane ustawienia systemu” - „Zaawansowane”.
4. 
   controlsystem.cpl,3
5. Uruchom w wierszu poleceń (cmd):
   Właściwości systemu Zaawansowane

Efektem opisanych działań jest otwarcie okna „Właściwości systemu” i wybranie zakładki „Zaawansowane”:

Następnie w sekcji „Pobieranie i odzyskiwanie” klikamy, wybieramy „Opcje”, a tym samym otwieramy nowe okno o nazwie „Pobieranie i odzyskiwanie”:

Wszystkie ustawienia zrzutu awaryjnego są pogrupowane w blok ustawień o nazwie Awaria systemu. W tym bloku możemy ustawić następujące parametry:

1. Zapisuj zdarzenia do dziennika systemowego.
2. Wykonaj automatyczne ponowne uruchomienie.
3. Rejestrowanie informacji debugowania.
4. Zrzuć plik.
5. Zastąp istniejący plik zrzutu.

Jak widać, wiele parametrów z listy jest dość trywialnych i łatwych do zrozumienia. Chciałbym jednak bardziej szczegółowo zająć się parametrem „Dump file”. Parametr jest prezentowany jako lista rozwijana i ma cztery możliwe wartości:

Mały zrzut pamięci

Mały zrzut pamięci (minidump) to plik, który zawiera najmniej informacji o awariach. Najmniejszy ze wszystkich możliwych zrzutów pamięci. Pomimo oczywistych wad, często są to minizrzuty, które są wykorzystywane jako informacje o awariach, które są przekazywane zewnętrznemu dostawcy sterowników w celu dalszego zbadania.
Mieszanina:

• Komunikat o błędzie.
• Wartość błędu.
• Opcje błędów.
• Kontekst procesora (PRCB), który uległ awarii.
• Informacje o procesie i kontekst jądra (EPROCESS) dla procesu powodującego awarię wraz ze wszystkimi jego wątkami.
• Informacje o procesie i kontekst jądra (ETHREAD) dla wątku, który spowodował awarię.
• Stos trybu jądra dla wątku, który spowodował awarię.
• Lista załadowanych sterowników.

Zakwaterowanie: %SystemRoot%\Minidump\MMDDYY-XXXXX-NN.dmp. Gdzie MMDDYY - odpowiednio miesiąc, dzień i rok, NN - numer seryjny wysypisko.
Wolumen: rozmiar zależy od bitowości systemu operacyjnego: tylko 128 kilobajtów jest wymaganych dla 32-bitowego systemu operacyjnego i 256 kilobajtów dla 64-bitowego systemu operacyjnego w pliku stronicowania (lub w pliku określonym w DedicatedDumpFile). Ponieważ nie możemy ustawić tak małego rozmiaru, zaokrąglamy go do 1 megabajta.

Zrzut pamięci jądra

Ten typ zrzutu zawiera kopię całej pamięci jądra w momencie awarii.
Mieszanina:

• Lista uruchomionych procesów.
• Stan bieżącego wątku.
• Strony pamięci trybu jądra obecne w pamięci fizycznej w momencie awarii: pamięć sterownika trybu jądra i pamięć programu trybu jądra.
• Pamięć warstwy sprzętowej (HAL).
• Lista załadowanych sterowników.

W zrzucie pamięci jądra brakuje nieprzydzielonych stron pamięci i stron trybu użytkownika. Zgadzam się, jest mało prawdopodobne, aby strony procesu trybu użytkownika były dla nas interesujące podczas awarii systemu (BugCheck), ponieważ zwykle awaria systemu jest inicjowana przez kod trybu jądra.

Rozmiar: Zmienia się w zależności od rozmiaru przestrzeni adresowej jądra, przydziału systemu operacyjnego i liczby sterowników trybu jądra. Zazwyczaj wymagana jest około jedna trzecia ilości pamięci fizycznej w pliku wymiany (lub pliku określonym przez DedicatedDumpFile). Może się różnić.

Kompletny zrzut pamięci

Pełny zrzut pamięci zawiera kopię całej pamięci fizycznej (RAM) w momencie awarii. W związku z tym do pliku trafia również cała zawartość pamięci systemowej. Jest to zarówno zaleta, jak i poważna wada, ponieważ jej rozmiar może być znaczny na niektórych serwerach z dużą ilością pamięci RAM.
Mieszanina:

• Wszystkie strony „widocznej” pamięci fizycznej. To praktycznie cała pamięć systemu, z wyjątkiem obszarów wykorzystywanych przez sprzęt: BIOS, przestrzeń PCI itp.
• Przetwarzaj dane, które były uruchomione w systemie w momencie awarii.
• Strony pamięci fizycznej, które nie są mapowane na wirtualną przestrzeń adresową, ale które mogą pomóc w zbadaniu przyczyny niepowodzenia.

Pełny zrzut pamięci domyślnie nie obejmuje obszarów pamięci fizycznej używanej przez system BIOS.
Lokalizacja: %SystemRoot%\MEMORY.DMP . Poprzedni zrzut zostanie nadpisany.
Rozmiar: plik stronicowania (lub plik określony w DedicatedDumpFile) wymaga ilości równej rozmiarowi pamięci fizycznej + 257 MB (te 257 MB są podzielone na pewien rodzaj nagłówka + dane sterownika). W rzeczywistości w niektórych systemach operacyjnych dolny próg pliku stronicowania można ustawić dokładnie na wartość rozmiaru pamięci fizycznej.

Automatyczny zrzut pamięci

Począwszy od Windows 8/ Serwer Windows 2012 do systemu wprowadzono nowy typ zrzutu o nazwie „Automatyczny zrzut pamięci”, który jest ustawiony jako typ domyślny. W takim przypadku system sam decyduje, który zrzut pamięci zapisać w sytuacji konkretnej awarii. Co więcej, logika wyboru zależy od wielu kryteriów, w tym od częstotliwości „upadku” systemu operacyjnego.

Po zmianie konfiguracji zrzutu pamięci systemu Windows może być konieczne ponowne uruchomienie komputera.

Ustawienia rejestru

Klucz rejestru definiujący ustawienia zrzutu awaryjnego:

HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control CrashControl

Opcje:

Ręczne tworzenie zrzutu pamięci

Powyżej opisaliśmy ustawienia dla automatyczne tworzenie zrzuty awaryjne systemu w przypadku błędu krytycznego, czyli nieobsłużonego wyjątku w kodzie jądra. Ale w rzeczywistości, oprócz awarii systemu operacyjnego, zdarzają się sytuacje, w których trzeba uzyskać zrzut pamięci systemowej w określonym momencie. Jak być w tym przypadku? Istnieją metody uzyskania natychmiastowej kopii całej pamięci fizycznej, takie jak użycie polecenia .dump w debugerach WinDbg/LiveKD. LiveKD to program, który pozwala uruchomić debugger jądra Kd na uruchomionym systemie w trybie lokalnym. Debuger WinDbg ma również podobną funkcję. Jednak metoda uzyskiwania zrzutu w locie nie jest dokładna, ponieważ zrzut jest tworzony w tym przypadku jest „niespójny”, ponieważ utworzenie zrzutu zajmuje czas, a w przypadku korzystania z debugera trybu jądra , system kontynuuje pracę i wprowadza zmiany w stronach pamięci.

W momencie krytycznej awarii system operacyjny Windows przestaje działać i wyświetla niebieski ekran śmierci (BSOD). Zawartość pamięć o dostępie swobodnym a wszystkie informacje o błędzie, który wystąpił, są zapisywane w pliku stronicowania. W następnym Uruchamianie systemu Windows tworzony jest zrzut awaryjny z informacjami debugowania opartymi na zapisanych danych. W dzienniku zdarzeń systemowych tworzony jest wpis błędu krytycznego.

Uwaga! Zrzut awaryjny nie jest generowany, jeśli podsystem dysku uległ awarii lub błąd krytyczny powstały na początkowym etapie ładowania systemu Windows.

Rodzaje zrzutów awarii systemu Windows

Na przykładzie obecnego funkcjonowania Systemy Windows 10 (Windows Server 2016) przyjrzyjmy się głównym typom zrzutów pamięci, które system może tworzyć:

• Mini zrzut pamięci (mały zrzut pamięci)(256 KB). Ten typ pliku zawiera minimalną ilość informacji. Zawiera tylko komunikat o błędzie BSOD, informacje o sterownikach, procesach aktywnych w momencie awarii oraz o tym, który proces lub wątek jądra spowodował awarię.
• Zrzut pamięci jądra. Zwykle niewielka, jedna trzecia ilości pamięci fizycznej. Zrzut pamięci jądra jest bardziej szczegółowy niż minizrzut. Zawiera informacje o sterownikach i programach w trybie jądra, w tym przydzieloną pamięć Jądro Windows oraz warstwę abstrakcji sprzętu (HAL), a także pamięć przydzieloną sterownikom i innym programom w trybie jądra.
• Kompletny zrzut pamięci. Największy rozmiar i wymaga pamięci równej pamięci RAM systemu plus 1 MB wymaganej przez system Windows do utworzenia tego pliku.
• Automatyczny zrzut pamięci. Odpowiada zrzutowi pamięci jądra 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ą określić przyczyny awarii systemu. Zostało to dodane do systemu Windows 10 i jest szczególnie przydatne, jeśli używasz maszyna wirtualna lub jeśli twój system jest hostem Hyper-V.

Jak włączyć generowanie zrzutu pamięci w systemie Windows?

Używając Win + Pause, otwórz okno ustawień systemowych, wybierz " Dodatkowe ustawienia systemu" (Zaawansowane ustawienia systemu). W zakładce „ do tego„ (Zaawansowane), sekcja „” (Uruchamianie i odzyskiwanie), kliknij przycisk „ Opcje» (Ustawienia). W oknie, które zostanie otwarte, skonfiguruj działania w przypadku awarii systemu. Zaznacz pole wyboru " Zapisuj zdarzenia do dziennika systemowego» (Zapisz zdarzenie w dzienniku systemowym), wybierz typ zrzutu, który ma być generowany w przypadku awarii systemu. Jeśli w polu wyboru „ Zastąp istniejący plik zrzutu» (Zastąp dowolny istniejący plik) zaznacz pole, plik zostanie nadpisany przy każdej awarii. Lepiej odznaczyć to pole, wtedy będziesz mieć więcej informacji do analizy. Wyłącz również automatyczny restart systemu (Automatycznie uruchom ponownie).

W większości przypadków wystarczy mały zrzut pamięci, aby przeanalizować przyczynę BSOD.

Teraz, jeśli wystąpi BSOD, możesz przeanalizować plik zrzutu i znaleźć przyczynę niepowodzeń. Minidump jest domyślnie przechowywany w folderze %systemroot%\minidump. Aby przeanalizować plik zrzutu, polecam skorzystać z programu WinDBG(Debuger jądra firmy Microsoft).

Instalowanie WinDBG w systemie Windows

Pożytek WinDBG zawarte w " Zestaw SDK dla systemu Windows 10» (pakiet SDK dla systemu Windows 10). .

Plik nazywa się winsdksetup.exe, rozmiar 1,3 MB.

Uruchom instalację i wybierz, czy chcesz zainstalować pakiet na tym komputerze, czy pobrać go do instalacji na innych komputerach. Zainstaluj pakiet na komputerze lokalnym.

Możesz zainstalować cały pakiet, ale aby zainstalować tylko narzędzie do debugowania, wybierz Debugowanie Narzędzia do Okna.

Po zainstalowaniu skróty WinDBG można znaleźć w menu Start.

Ustawianie powiązania plików .dmp z WinDBG

Aby otworzyć pliki zrzutu jednym kliknięciem, zmapuj rozszerzenie .dmp na narzędzie WinDBG.

1. otwarty wiersz poleceń jako administrator i uruchamiaj 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
2. W rezultacie typy plików: .DMP, .HDMP, .MDMP, .KDMP, .WEW zostaną zmapowane do WinDBG.

Konfigurowanie serwera symboli debugowania w WinDBG

Symbole debugowania (symbole debugowania lub pliki symboli) to bloki danych generowane w procesie kompilacji programu wraz z plikiem wykonywalnym. Takie bloki danych zawierają informacje o nazwach zmiennych, nazwanych funkcjach, bibliotekach itp. Te dane nie są potrzebne podczas uruchamiania programu, ale przydatne podczas debugowania. Składniki firmy Microsoft są kompilowane z symbolami rozpowszechnianymi za pośrednictwem serwera symboli firmy Microsoft.

Skonfiguruj WinDBG do korzystania z Microsoft Symbol Server:

• Otwórz WinDBG;
• Przejdź do menu plik –> Ścieżka pliku symbolu;
• Napisz ciąg znaków zawierający adres URL do pobierania symboli debugowania ze strony internetowej firmy Microsoft oraz folder do zapisania pamięci podręcznej: SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols W tym przykładzie pamięć podręczna jest pobierana do folderu E:\Sym_WinDBG, możesz określić dowolny.
• Nie zapomnij zapisać zmian w menu plik–>Zapisz obszar roboczy;

WinDBG wyszuka symbole w folderze lokalnym, a jeśli nie znajdzie w nim niezbędnych symboli, automatycznie pobierze symbole z określonej witryny. Jeśli chcesz dodać własny folder symboli, możesz to zrobić w ten sposób:

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

Jeśli nie ma połączenia z Internetem, najpierw pobierz pakiet symboli z zasobu Pakiety symboli systemu Windows.

Analiza zrzutu awarii 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żesz używać WinDBG. Na dole okna (w linii poleceń debuggera) pojawia się napis Debug nie podłączony.

Polecenia wprowadza się do wiersza poleceń znajdującego się na dole okna.

Najważniejszą rzeczą, na którą należy zwrócić uwagę, jest kod błędu, który jest zawsze wskazany w wartość szesnastkowa i wygląda jak 0xXXXXXXXXX(wskazane w jednej z opcji - STOP:, 07.02.2019 0008F, 0x8F). W naszym przykładzie kod błędu to 0x139.

Debuger poprosi o wykonanie polecenia!analizuj -v, po prostu najedź na link i kliknij. Do czego służy to polecenie?

• Przeprowadza wstępną analizę zrzutu pamięci i zapewnia: dokładna informacja aby rozpocząć analizę.
• To polecenie wyświetli kod STOP i symboliczną nazwę błędu.
• Pokazuje stos wywołań poleceń, które doprowadziły do ​​awarii.
• Ponadto wyświetlane są tutaj adres IP, błędy procesu i rejestru.
• Zespół może przedstawić gotowe zalecenia dotyczące rozwiązania problemu.

Główne punkty, na które należy zwrócić uwagę podczas analizy po wykonaniu polecenia !analyze -v (lista nie jest kompletna).

1: kd> !analizuj -v

* *
*Analiza kontrolna 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. To uszkodzenie może potencjalnie umożliwić osobie atakującej przejęcie kontroli nad tym komputerem):

Składnik jądra uszkodził krytyczną strukturę danych. Uszkodzenie może potencjalnie umożliwić złośliwemu użytkownikowi przejęcie kontroli nad tym komputerem.
Argumenty błędów:

Argumenty:
Arg1: 0000000000000003, A LIST_ENTRY została uszkodzona (tj. podwójne usunięcie).
Arg2: ffffd0003a20d5d0, Adres ramki pułapki dla wyjątku, który spowodował sprawdzenie błędów
Arg3: ffffd0003a20d528, Adres rekordu wyjątku dla wyjątku, który spowodował sprawdzenie błędów
Arg4: 0000000000000000, zarezerwowane
Szczegóły debugowania:
------------------

Licznik pokazuje, ile razy system uległ awarii z podobnym błędem:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Kod błędu STOP w formie skróconej:

BUGCHECK_STR: 0x139

Proces, który uległ awarii podczas wykonywania (niekoniecznie przyczyna błędu, po prostu ten proces był uruchomiony w pamięci w momencie awarii):

PROCESS_NAME: sqlservr.exe

Odszyfrowanie kodu błędu: system wykrył przepełnienie bufora stosu w tej aplikacji, co może umożliwić osobie atakującej przejęcie kontroli nad tą aplikacją.

ERROR_CODE: (NTSTATUS) 0xc0000409 — system wykrył przepełnienie 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ł przepełnienie bufora opartego na stosie w tej aplikacji. To przekroczenie może potencjalnie umożliwić złośliwemu użytkownikowi przejęcie kontroli nad tą aplikacją.

Ostatnie wywołanie 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`00000000 00000000`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::`ciąg"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`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

Sekcja kodu, w której wystąpił błąd:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov bajt ptr ,0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: Właściciel Maszyny

Nazwa modułu w tabeli obiektów jądra. Jeżeli analizatorowi udało się wykryć problematyczny sterownik, nazwa jest wyświetlana w polach NAZWA_MODUŁU i NAZWA_OBRAZU:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

1: kd > lmvm nt
Przeglądaj pełną listę modułów
Załadowany plik obrazu symbolu: ntkrnlmp.exe
Plik obrazu zmapowanej pamięci: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Ścieżka obrazu: ntkrnlmp.exe
Nazwa obrazu: ntkrnlmp.exe
Nazwa wewnętrzna: ntkrnlmp.exe
Oryginalna nazwa pliku: ntkrnlmp.exe
Wersja produktu: 6.3.9600.18946
Wersja pliku: 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 na sterownik systemowy (na przykład win32k.sys) lub plik jądra (na przykład ntkrnlmp.exe w naszym przykładzie), najprawdopodobniej jest to podany plik nie jest przyczyną problemu. Bardzo często okazuje się, że problem leży w sterowniku urządzenia, Ustawienia BIOS lub wadliwe działanie sprzętu.

Jeśli zauważysz, że BSOD jest spowodowany sterownikiem innej firmy, jego nazwa zostanie wymieniona 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ę.