Otwórz zrzut systemu Windows 7. Jak zrozumieć, na czym polega problem, gdy pojawia się niebieski ekran (BSOD) lub jak otworzyć plik zrzutu. Ręczne tworzenie zrzutu pamięci

Plik zrzutu pamięci jest zapisywany w przypadku wystąpienia błędów STOP (lub niebieskich ekranów śmierci, BSOD). Zobaczmy, jak skonfigurować zapisywanie zrzutu pamięci w systemie Windows 7.

Kliknij ikonę prawym przyciskiem myszy Komputer wybierz z menu kontekstowego Nieruchomości.

W lewej kolumnie wybierz Zaawansowane ustawienia systemu (Zaawansowane ustawienia systemu).

W oknie Właściwości systemu wybierz zakładkę Dodatkowo (zaawansowane), w sekcji Uruchamianie i odzyskiwanie naciskać Opcje(Ustawienia).

W oknie Uruchamianie i odzyskiwanie) konfigurujemy lokalizację i nazwę pliku zrzutu, a także inne parametry związane z uruchamianiem i odzyskiwaniem systemu.

Wpisz ścieżkę do pliku w polu tekstowym Zrzuć plik.

%SystemRoot% to zmienna środowiskowa zastępowana przez system pełną ścieżką do folderu Windows, w którym znajdują się pliki systemowe.

Kliknij OK aby zapisać ustawienia (jeśli zostały wprowadzone zmiany).

Po drodze możesz odznaczyć pole wyboru Wykonaj automatyczne ponowne uruchomienie, jeśli nie chcesz, aby komputer automatycznie uruchamiał się ponownie, ale dał ci możliwość zapisania informacji o błędzie, który doprowadził do niebieskiego ekranu. Więcej szczegółów znajdziesz w artykule.

Wszystkie systemy Windows po wykryciu błędu krytycznego wykonują zrzut awaryjny (migawkę) zawartości pamięci RAM i zapisują ją na dysku twardym. Istnieją trzy typy zrzutów pamięci:

Pełny zrzut pamięci – zapisuje całą zawartość pamięci RAM. Rozmiar obrazu jest równy rozmiarowi pamięci RAM + 1 MB (nagłówek). Bardzo rzadko używany, ponieważ w systemach z dużą ilością pamięci rozmiar zrzutu będzie zbyt duży.

Zrzut pamięci jądra – zapisuje informacje o pamięci RAM związane wyłącznie z trybem jądra. Informacje o trybie użytkownika nie są zapisywane, ponieważ nie zawierają informacji o przyczynie awarii systemu. Rozmiar pliku zrzutu zależy od wielkości pamięci RAM i waha się od 50 MB (dla systemów z 128 MB pamięci RAM) do 800 MB (dla systemów z 8 GB pamięci RAM).

Mały zrzut pamięci (mini zrzut) - zawiera dość niewielką ilość informacji: kod błędu z parametrami, listę sterowników załadowanych do pamięci RAM w momencie awarii systemu itp., ale ta informacja wystarczy do zidentyfikowania wadliwego sterownika . Kolejną zaletą tego typu zrzutu jest mały rozmiar pliku.

Ustawienia systemu

Aby zidentyfikować sterownik, który to spowodował, wystarczy nam skorzystanie z małego zrzutu pamięci. Aby system zapisał mini zrzut podczas awarii, musisz wykonać następujące kroki:

Po zakończeniu wszystkich manipulacji po każdym BSoD plik z rozszerzeniem .dmp zostanie zapisany w folderze C:\WINDOWS\Minidump. Radzę przeczytać materiał „”. Możesz także zaznaczyć pole „ Zastąp istniejący plik zrzutu" W takim przypadku każdy nowy zrzut awaryjny zostanie nadpisany na starym. Nie polecam włączania tej opcji.

Analizowanie zrzutu awaryjnego przy użyciu BlueScreenView

Tak więc, po pojawieniu się niebieskiego ekranu śmierci, system zapisał nowy zrzut pamięci awaryjnej. Do analizy zrzutu polecam skorzystać z programu BlueScreenView. Można go pobrać bezpłatnie. Program jest dość wygodny i ma intuicyjny interfejs. Po zainstalowaniu pierwszą rzeczą, którą musisz zrobić, to określić lokalizację przechowywania zrzutów pamięci w systemie. Aby to zrobić, przejdź do punktu menu „ Opcje” i wybierz „ ZaawansowanyOpcje" Wybierz przycisk radiowy „ ObciążeniezthenastępnyMini zrzutteczka” i określ folder, w którym przechowywane są zrzuty. Jeśli pliki są przechowywane w folderze C:\WINDOWS\Minidump, możesz kliknąć przycisk „ Domyślny" Kliknij OK i przejdź do interfejsu programu.

Program składa się z trzech głównych bloków:

1. Blok menu głównego i panel sterowania;
2. Blok listy zrzutów awaryjnych;
3. W zależności od wybranych parametrów może zawierać:

• lista wszystkich sterowników w pamięci RAM przed pojawieniem się niebieskiego ekranu (domyślnie);
• lista sterowników znajdujących się na stosie RAM;
• Zrzut ekranu BSoD;
• i inne wartości, których nie będziemy używać.

W bloku listy zrzutów pamięci (oznaczonym na rysunku numerem 2) wybierz interesujący nas zrzut i przejrzyj listę sterowników, które zostały załadowane do pamięci RAM (oznaczonych numerem 3 na rysunku). Sterowniki znajdujące się na stosie pamięci mają kolor różowy. Są przyczyną BSoD. Następnie przejdź do Menu Głównego sterownika, określ do jakiego urządzenia lub programu one należą. Przede wszystkim zwróć uwagę na pliki niesystemowe, ponieważ pliki systemowe i tak są ładowane do pamięci RAM. Łatwo zauważyć, że wadliwym sterownikiem na obrazie jest myfault.sys. Powiem, że ten program został specjalnie uruchomiony, aby spowodować błąd zatrzymania. Po zidentyfikowaniu wadliwego sterownika należy go zaktualizować lub usunąć z systemu.

Aby program wyświetlał listę sterowników znajdujących się na stosie pamięci w przypadku wystąpienia BSoD, należy przejść do pozycji menu „ Opcje„kliknij menu” NiżejSzkłoTryb” i wybierz „ TylkoKierowcyZnalezionyWStos” (lub naciśnij klawisz F7) i aby wyświetlić zrzut ekranu błędu, wybierz „ NiebieskiEkranWXPStyl” (F8). Aby powrócić do listy wszystkich kierowców należy wybrać „ WszystkoKierowcy” (F6).

W następnym kroku wyboru komponentu do zainstalowania ( Wybierz funkcje, które chcesz zainstalować) zaznaczamy tylko to, czego potrzebujemy - Narzędzia do debugowania dla systemu Windows i naciśnij zainstalować

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

Po zakończeniu instalacji znajdź go w menu Start lub na ekranie startowym w grupie skrótów Zestawy Windowsa pożytek WinDbg i uruchom go z uprawnieniami administratora

Jeżeli z jakiegoś powodu skrót nie został odnaleziony, 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 elementy Plik > Ścieżka pliku symboli. W oknie, które zostanie otwarte, wstaw linię określającą lokalny katalog pamięci podręcznej symboli i jej źródło online:

Ustawienia zapisujemy wybierając pozycje w menu głównym Plik > Zapisz obszar roboczy

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

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

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

Te same informacje można uzyskać za pomocą wiersza poleceń, stosując w przybliżeniu następującą sekwencję poleceń:

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

Źródła informacji:

Awaria systemu spowodowana błędem krytycznym (BSOD) najczęściej ma miejsce na skutek nieprawidłowego działania lub uszkodzenia sterownika, za wyjątkiem przypadków problemów ze sprzętem komputera.

W tym artykule przyjrzymy się podstawowym krokom, które pomogą Ci samodzielnie ustalić przyczynę BSOD, a w rezultacie ją wyeliminować.

Przeanalizujemy zrzuty pamięci za pomocą debugera WinDBG, więc zanim zaczniesz, musisz zainstalować debuger i go skonfigurować.
Jak to zrobić, dowiesz się z artykułu.

Interfejs WinDBG

Po otwarciu pliku zrzutu pamięci zobaczysz takie okno:

Warto zaznaczyć, że domyślne okno poleceń jest niezależne od głównego okna debugera, można więc zmieniać jego rozmiar, przesuwać czy wpasowywać w okno debugera przeciągając myszką jego górną granicę do dolnej krawędzi paska narzędzi, a także rozwiń go do pełnego ekranu.

Po otwarciu pliku zrzutu debugerowi zajmie trochę czasu połączenie się z Internetem i załadowanie symboli niezbędnych do debugowania. Podczas ładowania symboli debugowania w wierszu poleceń debugera pojawia się następujący komunikat: Debugee nie jest podłączony, w tym czasie nie będzie można korzystać z debugera.

Gdy symbole zostaną załadowane, a debuger będzie gotowy do analizy pliku zrzutu, zostanie wyświetlony komunikat Kontynuacja: Właściciel maszyny na dole okna tekstowego.

Teraz możesz rozpocząć analizę zrzutu pamięci. Wszystkie polecenia wprowadza się w wierszu poleceń znajdującym się na dole okna.

Analiza zrzutu pamięci

Pierwszą rzeczą, na którą należy zwrócić uwagę podczas otwierania pliku zrzutu, jest kod błędu, który w dużej mierze określa główny kierunek błędu i metodologię analizy.

Kody błędów są zawsze podawane w formacie szesnastkowym i mają postać 0xXXXXXXXXX. Kody błędów są wskazywane w jednej z następujących opcji:

• ZATRZYMAJ: 0x0000009F
• 03.06.2015 0009F

Odniesienie do kodu błędu: Informacje o kodzie sprawdzania błędów w Centrum deweloperów systemu Windows

Polecenie!thread i analiza sterowników

Najczęstszą przyczyną BSOD są sterowniki innych firm (producenta urządzenia). Aby sprawdzić, czy sterownik urządzenia pojawi się na zrzucie, będziemy musieli wyświetlić stos.
Uruchom polecenie ! nitka i znaleźć w wynikach jego wykonania Baza I Limit i ich wartości szesnastkowe.
W rozważanym przykładzie są to:
Podstawa fffff80000b9b000 Limit fffff80000b95000

W wierszu poleceń wpisz dps następnie oddzielone spacją w formacie szesnastkowym Limit, po którym następuje wartość Baza. W tym przypadku istotna jest kolejność podawania wartości – musi być ona odwrotna do tego, co wyświetli się w wyniku wykonania polecenia!thread.

dps fffff80000b95000 fffff80000b9b000

Po załadowaniu stosu zobaczysz wiele linii z tekstem i wartościami. Wśród wyników polecenia poszukaj komunikatów o błędach wskazujących sterowniki. W rozważanym przykładzie jest to sterownik igdkmd64.sys i iaStorA.sys, a w debugerze wygląda to tak:

Wyszukaj na komputerze określone sterowniki. Nie jest to konieczne, ale wskazane jest, aby to zrobić. Po odinstalowaniu sterownika z Menedżera urządzeń lub przy użyciu programu dezinstalacyjnego producenta urządzenia sterownik może nie zostać odinstalowany – w takim przypadku można go odinstalować ręcznie. Drugim powodem jest to, że może to być plik złośliwego programu (wirus, trojan, górnik itp.) i w takich przypadkach sterownik zwykle znajduje się w nietypowych folderach.
Aby uprościć procedurę, uruchom następujące polecenie w wierszu poleceń uruchomionym jako administrator:

Driverquery /v > „%USERPROFILE%\Desktop\drivers.txt”

Po wykonaniu polecenia na pulpicie zostanie utworzony plik sterowniki.txt, zawierający szczegółowe informacje o wszystkich sterownikach zainstalowanych w systemie, wraz z ich opisem i lokalizacją pliku sterownika.

W rozważanym przykładzie prawdopodobnymi winowajcami BSOD były sterowniki karty graficznej Intel (igdkmd64.sys) i kontrolera SATA/AHCI (iaStorA.sys).

Warto zaznaczyć, że sterowniki nie zawsze są przyczyną BSOD, może to być również konsekwencja awarii sprzętu, jednak jeśli kod błędu wskazuje na problem ze sterownikiem, wówczas zalecane jest skorzystanie z Windows Driver Checker.

Polecenie!analizuj -v

Polecenie!analyze wyświetla informacje o bieżącym wyjątku lub kodzie błędu, a opcja -v generuje szczegółowe dane wyjściowe. W tym przypadku będziemy potrzebować danych o zablokowanych pakietach IRP w wartości Arg4 i wartości AWARIA_WIADERKO_ID I WIADERKO_ID.

Uruchom polecenie !irp dodanie wartości z Arg4

!irp ffffe001eb781600

W wyniku wykonania polecenia zidentyfikowano problematyczny sterownik - RT630x64.sys

W tym przypadku sterownik Rt630x64.sys jest powiązany z kartą sieciową i powoduje błąd DRIVER_POWER_STATE_FAILURE podczas zamykania systemu.
Aby uzyskać szczegółowe informacje o pliku sterownika, uruchom polecenie

Jak widać data sterownika jest dość stara i warto ją zaktualizować, aby rozwiązać problem.

Wniosek

Celem tego artykułu jest omówienie algorytmu analizy zrzutu pamięci w celu zidentyfikowania przyczyny BSOD. Niemożliwe jest rozważenie wszystkich opcji analizy w ramach jednego artykułu, a wiele subtelności przychodzi dopiero z doświadczeniem. Uwzględniono tylko jeden kod błędu, ponieważ kolejność jego analizy wydała mi się najciekawsza, w przeciwieństwie do np. błędu 0x124, który w zdecydowanej większości przypadków wskazuje na problem sprzętowy, czy 0x116, który wskazuje na problem ze sterownikiem wideo lub problem z wideo Karta w 95% przypadków.

Jeśli nie udało Ci się znaleźć przyczyny BSOD lub po prostu potrzebujesz szybkiej i wykwalifikowanej pomocy w analizie problemu, zawsze możesz skontaktować się z forum

Witajcie przyjaciele, dzisiaj omówimy ciekawy temat, który pomoże wam w przyszłości, gdy pojawi się niebieski ekran śmierci (BSoD).

Podobnie jak ja, wielu innych użytkowników musiało obserwować wygląd ekranu z niebieskim tłem, na którym coś było napisane (białe na niebieskim). Zjawisko to wskazuje na krytyczny problem, zarówno w oprogramowaniu, na przykład konflikt sterowników, jak i na fizyczną awarię jakiegoś elementu komputera.

Niedawno znów pojawił się problem z niebieskim ekranem w systemie Windows 10, ale szybko się go pozbyłem i wkrótce Ci o tym powiem.

Dlatego większość użytkowników nie jest świadoma, że ​​BSoD można przeanalizować, aby później zrozumieć problemy krytyczne. W takich przypadkach system Windows tworzy specjalne pliki na dysku, a my je przeanalizujemy.

Istnieją trzy typy zrzutów pamięci:

Pełny zrzut pamięci– funkcja ta umożliwia całkowite zapisanie zawartości pamięci RAM. Jest rzadko używany, ponieważ wyobraź sobie, że masz 32 GB pamięci RAM, przy pełnym zrzucie cały ten wolumin będzie przechowywany na dysku.

Zrzut rdzenia– zapisuje informacje o trybie jądra.

Mały zrzut pamięci– zapisuje niewielką ilość informacji o błędach i załadowanych komponentach, które były obecne w momencie wystąpienia awarii systemu. Będziemy używać tego typu zrzutu, ponieważ dostarczy nam on wystarczających informacji o BSoD.

Lokalizacja małego i pełnego zrzutu jest inna, na przykład mały zrzut znajduje się w następującej ścieżce: %systemroot%\minidump.

Pełny zrzut znajduje się tutaj: %systemroot%.

Istnieją różne programy do analizy zrzutów pamięci, ale my użyjemy dwóch. Pierwszym z nich jest Microsoft Kernel Debuggers, jak sama nazwa wskazuje, narzędzie firmy Microsoft. Można go pobrać z oficjalnej strony internetowej. Drugi program to BlueScreenView, darmowy program, który można pobrać stąd.

Analizowanie zrzutu pamięci przy użyciu debugerów jądra firmy Microsoft

W przypadku różnych wersji systemów należy pobrać inny typ narzędzia. Na przykład w przypadku 64-bitowego systemu operacyjnego potrzebny jest program 64-bitowy, w przypadku 32-bitowego systemu operacyjnego potrzebna jest wersja 32-bitowa.

To nie wszystko, musisz pobrać i zainstalować pakiet symboli debugujących potrzebnych programowi. Nazywa się to debugowaniem symboli. Każda wersja tego pakietu jest również pobierana pod określonym systemem operacyjnym, najpierw dowiedz się, jaki masz system, a następnie pobierz. Abyś nie musiał nigdzie szukać tych symboli, oto link do pobrania. Instalację najlepiej przeprowadzić w następującej ścieżce: %systemroot%\symbols.

Teraz możesz uruchomić nasz debugger, którego okno będzie wyglądać następująco:

Przed analizą zrzutów skonfigurujemy coś w narzędziu. Najpierw musimy poinformować program, gdzie zainstalowaliśmy symbole debugowania. Aby to zrobić, kliknij przycisk „Plik” i wybierz opcję „Ścieżka pliku symboli”, a następnie wskaż ścieżkę do symboli.

Program umożliwia pobieranie symboli bezpośrednio z sieci, dzięki czemu nie trzeba ich nawet pobierać (przepraszam tych, którzy już je pobrali). Zostaną pobrane z serwera Microsoft, więc wszystko jest bezpieczne. Musisz więc ponownie otworzyć „Plik”, następnie „Ścieżka pliku symbolu” i wprowadzić następujące polecenie:

SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols

Tym samym wskazaliśmy programowi, że symbole należy pobrać z sieci. Gdy już to zrobimy, kliknij „Plik” i wybierz „Zapisz obszar roboczy”, a następnie kliknij OK.

To wszystko. Skonfigurowaliśmy program w odpowiedni sposób, teraz zaczynamy analizować zrzuty pamięci. W programie naciśnij przycisk "Plik", Następnie „Otwórz zrzut awarii” i wybierz żądany plik.

Debuggery jądra rozpoczną analizę pliku, a następnie wygenerują wynik informujący o przyczynie błędu.

W wyświetlonym oknie możesz wprowadzać polecenia. Jeśli wejdziemy !analizuj – w, wtedy otrzymamy więcej informacji.

To wszystko w tym programie. Aby zatrzymać debuger, wybierz opcję „Debuguj” i opcję „Zatrzymaj debugowanie”.

Analizowanie zrzutu pamięci za pomocą BlueScreenView

Program BlueScreenView nadaje się również do analizy różnych błędów i BSoD, ma prosty interfejs, więc nie powinno być problemów z jego opanowaniem.

Pobierz program z linku powyżej i zainstaluj. Po uruchomieniu narzędzia należy je skonfigurować. Przejdź do parametrów: „Ustawienia” - „Ustawienia zaawansowane”. Otworzy się małe okno z kilkoma przedmiotami. W pierwszym akapicie musisz wskazać lokalizację zrzutów pamięci. Zazwyczaj znajdują się one w ścieżce C:\WINDOWS\Minidump. Następnie kliknij przycisk „Domyślne”.

Co można zobaczyć w programie? Mamy pozycje menu, część okna z nazwami plików zrzutów i drugą część okna - zawartość zrzutów pamięci.

Jak powiedziałem na początku artykułu, na zrzutach mogą być przechowywane sterowniki, zrzut ekranu samego „ekranu śmierci” i inne przydatne informacje, które mogą nam się przydać.

Zatem w pierwszej części okna, w którym znajdują się pliki zrzutu, wybierz potrzebny nam zrzut pamięci. W dalszej części okna przyglądamy się zawartości. Sterowniki znajdujące się na stosie pamięci oznaczone są czerwonawym kolorem. Są właśnie przyczyną niebieskiego ekranu śmierci.

W Internecie można znaleźć wszystko na temat kodu błędu i sterownika, który może być odpowiedzialny za BSoD. W tym celu kliknij „Plik”, a następnie „Znajdź kod błędu + sterownik w Google”.

Można wyświetlić tylko sterowniki, które były obecne w momencie wystąpienia błędu. Aby to zrobić, kliknij „Ustawienia” - „Tryb dolnego okna” - „W stosie awarii znaleziono tylko sterowniki”. Lub naciśnij klawisz F7.

Aby wyświetlić zrzut ekranu BSoD, naciśnij klawisz F8.

Aby wyświetlić wszystkie sterowniki i pliki, naciśnij klawisz F6.

Cóż, to wszystko. Teraz wiesz, jak dowiedzieć się o problemie niebieskiego ekranu śmierci, a jeśli coś się stanie, znajdź rozwiązanie w Internecie lub na tej stronie. Możesz podać swoje kody błędów, a ja postaram się napisać dla każdego artykułu, aby rozwiązać problem.

Nie zapomnijcie też zadawać pytań w komentarzach.