Narzędzia do debugowania systemu Windows: diagnozowanie i naprawianie BSOD. Narzędzia do debugowania systemu Windows: diagnozowanie i naprawianie BSOD Tworzenie zdalnego serwera

Tego typu awarie są zwykle związane z niesprawnym sterownikiem, który może być trudny do zidentyfikowania. Jednak ulepszony system śledzenia błędów w systemie Windows Vista (i nie tylko w Viście!) może często prowadzić do problematycznego pliku. W rezultacie większość ludzi przestaje gorączkowo próbować pracować na niestabilnym komputerze, zapisując dokumenty z paranoidalną regularnością i mając nadzieję na najlepsze.

W przypadku awarii systemu Windows zwykle tworzony jest tak zwany „zrzut pamięci”. Te ostatnie można zbadać za pomocą bezpłatnych narzędzi do debugowania systemu Windows, które mogą wskazać źródło problemu. Dlatego wszystko, co musisz zrobić, to:

Pobierz sobie narzędzie do debugowania

Narzędzia debugowania systemu Windows można pobrać bezpośrednio z witryny firmy Microsoft. Program współpracuje z wieloma system operacyjny, zaczynając od Windows NT 4, a kończąc na Windows 2008, więc nie powinieneś mieć z tym problemów. Tak, nie można powiedzieć, że jest stabilny pod Windows 7 RC, ale według naszych testów nadal działa. Dlatego nawet próba zdiagnozowania problemu spod Windows 7 RC może się powieść.

Skonfiguruj swój system

Podczas awarii komputer musi tworzyć zrzuty pamięci, które później posłużą jako źródło informacji dla debugera. Dlatego ważne jest, aby system Windows był skonfigurowany do generowania zrzutów. Aby skonfigurować system operacyjny, kliknij prawym przyciskiem myszy Twój komputer (Komputer) i wybierz Właściwości (Właściwości). Następnie kliknij kartę Zaawansowane ustawienia systemu, znajdź podsekcję Ustawienia uruchamiania i odzyskiwania i upewnij się, że opcja Zapisz informacje debugowania jest ustawiona na Zrzut pamięci jądra ) lub Pełny zrzut pamięci.

Następnie kliknij Start, przejdź do Programy (Wszystkie programy), wybierz Narzędzia debugowania i uruchom WinDbg. W programie przejdź do menu Plik i wybierz Ścieżka do pliku symbolu ... Następnie wpisz następujący wiersz w oknie, które się otworzy:

SRV*c:\symbole*http://msdl.microsoft.com/download/symbols

Ta ostatnia określa ścieżkę do specjalnych danych – tak zwanych „symboli” (symboli), które mogą pomóc narzędziu debugowania w identyfikacji uszkodzonego pliku.

Po wprowadzeniu ciągu kliknij przycisk OK. Później podczas pracy z debugerem ten wiersz spowoduje pobranie symboli z witryny msdl.microsoft.com i zapisanie ich w folderze c:\symbols.

Rozwiąż swój problem

Teraz poczekaj na kolejną awarię niebieskiego ekranu, a następnie zakończenie ponownego uruchamiania komputera. Następnie ponownie uruchom WinDbg (użytkownicy Vista muszą uruchomić program jako administrator), kliknij menu Plik, wybierz Otwórz Crash Dump, otwórz plik \Windows\MEMORY.DMP, a program natychmiast zacznie go analizować.

Niestety, WinDbg dostarcza bardzo mało informacji o tym, co robi, więc możesz nawet pomyśleć, że program się zawiesił. Jednak poczekaj. Zrozum, że analiza, powiedzmy, 4 GB pamięci na niezbyt wydajnym komputerze może zająć trochę czasu, nawet do godzin. Dlatego bądź cierpliwy, ale raczej zostaw analizę na noc.

Jednak zwykle wynik uzyskuje się w ciągu kilku minut. Świadczy o tym linia Bugcheck Analysis, która mówi coś w stylu „Prawdopodobnie spowodowane przez: UACReplace.sys”. W tłumaczeniu na język rosyjski oznacza to, że przyczyną problemu jest prawdopodobnie plik UACReplace.sys. Wpisz go w pasek wyszukiwania, na przykład Google, a dowiesz się jego prawdziwego pochodzenia. W szczególności, jeśli należy do jednego z zainstalowanych programów lub zainstalowany sterownik, możesz po prostu spróbować zaktualizować go lub go. Być może to rozwiąże twoje problemy.

Muszę powiedzieć, że od czasu do czasu WinDbg nie może w ogóle nazwać pliku lub po prostu wybiera jedną z bibliotek DLL systemu Windows. Jeśli tak się stało, po prostu kliknij okno poleceń nad paskiem stanu i wpisz polecenie:

Następnie naciśnij Enter. Dzięki temu uzyskasz bardziej szczegółowy raport, który może zawierać informacje o możliwe przyczyny twoje kłopoty.

Jeśli tym razem nie masz szczęścia, nie rozpaczaj. Debugowanie jest dość trudne, nawet dla ekspertów. Więc po prostu zamknij WinDbg i uruchom analizator ponownie po następnej awarii. Być może da ci to więcej informacji. Powodzenia!

Aby zidentyfikować przyczyny niebieskich ekranów (BSOD), konieczne jest przeanalizowanie zrzutu pamięci. W zdecydowanej większości przypadków wystarczy minizrzut, który jest tworzony przez system w przypadku wystąpienia błędów krytycznych.
Ten artykuł zawiera instrukcja krok po kroku do instalacji i konfiguracji WinDBG - potężnego narzędzia do debugowania, które pozwala zidentyfikować prawdziwą przyczynę BSOD.

Krok 1 — Konfiguracja nagrywania małego zrzutu pamięci

Krok 2 — Instalacja WinDBG

Aby analizować zrzuty pamięci, musisz zainstalować debugger WinDBG, który jest dołączony do zestawu Windows SDK. W chwili pisania tego tekstu najnowsze dostępne Wersje Windows SDK:

Windows 10 SDK (pobierz instalator online)
Windows 8.1 SDK (pobierz instalator online)

Krok 3 — Mapowanie plików .dmp do WinDBG

Mapuj pliki .dmp na WinDBG, aby ułatwić odczytywanie i analizowanie zrzutów pamięci. Umożliwi to otwieranie plików zrzutu z Eksploratora bezpośrednio w WinDBG, z pominięciem jego wstępnego uruchomienia.

Krok 4 — Konfiguracja serwera symboli do odbierania plików symboli debugowania

Instalacja i początkowa konfiguracja WinDBG została zakończona. Aby to zmienić wygląd zewnętrzny możesz przejść do menu pogląd- ustawienia czcionek znajdziesz wybierając element Czcionka i ustawienia okna konsoli w Opcje.

W momencie krytycznej awarii system operacyjny Windows przestaje działać i wyświetla niebieski ekran śmierci (BSOD). Zawartość pamięci RAM i wszystkie informacje o błędzie, który wystąpił, jest zapisywana w pliku stronicowania. Przy następnym uruchomieniu 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 tworzony, jeśli podsystem dyskowy uległ awarii lub wystąpił błąd krytyczny podczas początkowej fazy uruchamiania systemu Windows.

Rodzaje zrzutów awarii systemu Windows

Na przykładzie obecnego systemu operacyjnego 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 trybu jądra, obejmuje pamięć przydzieloną do jądra systemu Windows i warstwy abstrakcji sprzętu (HAL) oraz pamięć przydzieloną sterownikom i innym programom trybu 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 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ć 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 Narzędzia do debugowania dla Windows.

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.

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
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 awaryjnego w WinDBG

Debuger WinDBG otwiera plik zrzutu i ładuje niezbędne symbole do debugowania z folder lokalny 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 zawsze jest podany w wartości szesnastkowej i wygląda tak: 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 dostarcza szczegółowych informacji potrzebnych do rozpoczęcia analizy.
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 (jak w naszym przykładzie ntkrnlmp.exe), ten plik najprawdopodobniej nie jest przyczyną problemu. Bardzo często okazuje się, że problem leży w sterowniku urządzenia, ustawieniach BIOS-u lub awarii 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ę.

Narzędzia do debugowania dla Windows- Narzędzia do debugowania kodu operacyjnego Systemy Windows. Jest to zestaw swobodnie dystrybuowanych programów firmy Microsoft przeznaczonych do debugowania kodu trybu użytkownika i trybu jądra: aplikacji, sterowników, usług, modułów jądra. Zestaw narzędzi zawiera debugery konsoli i GUI, narzędzia do pracy z symbolami, plikami, procesami, narzędzia do zdalnego debugowania. Zestaw narzędzi zawiera narzędzia, za pomocą których można znaleźć przyczyny awarii w różnych komponentach systemu. Narzędzia do debugowania dla Windows od pewnego momentu nie są dostępne do pobrania w formie samodzielnej dystrybucji i są częścią Windows SDK (Windows Software Development Kit). Zestaw instrumentalny Narzędzia Windows Z kolei pakiet SDK jest dostępny w ramach programu subskrypcji MSDN lub można go bezpłatnie pobrać jako osobną dystrybucję ze strony msdn.microsoft.com. Według twórców najnowsze i najlepsze obecna wersja Narzędzia debugowania dla systemu Windows są zawarte w Windows SDK.

Narzędzia debugowania dla systemu Windows są dość często aktualizowane i udostępniane publicznie, a proces ten nie zależy od wydania systemów operacyjnych. Dlatego okresowo sprawdzaj dostępność nowych wersji.

Zobaczmy teraz, co w szczególności umożliwiają nam narzędzia debugowania dla systemu Microsoft Windows:

Debugowanie lokalnych aplikacji, usług (usług), sterowników i jądra;
Debuguj zdalne aplikacje, usługi (usługi), sterowniki i jądro przez sieć;
Debuguj działające aplikacje w czasie rzeczywistym;
Analizuj pliki zrzutu pamięci aplikacji, jądra i systemu jako całości;
Praca z systemami opartymi na architekturach x86/x64/Itanium;
Debuguj programy trybu użytkownika i trybu jądra;

Dostępne są następujące wersje narzędzi debugowania dla systemu Windows: 32-bit x86, Intel Itanium, 64-bit x64. Potrzebujemy dwóch z nich: x86 lub x64.

Istnieje kilka sposobów instalacji narzędzi debugowania dla systemu Windows, w tym artykule rozważymy tylko te główne:

Instalacja za pomocą instalatora internetowego.
Instalowanie narzędzi debugowania dla systemu Windows z systemu Windows SDK ISO.
Instalowanie narzędzi debugowania dla systemu Windows bezpośrednio z pakietów dbg_amd64.msi /dbg_x86.msi.

Nie jest jasne, w którym momencie, dlaczego powinienem instalować narzędzia do debugowania na komputerze? Często w końcu spotykasz się z sytuacją, w której interwencja w środowisku pracy jest wyjątkowo niepożądana! A tym bardziej, że instalacja nowego produktu, czyli wprowadzanie zmian w plikach rejestru/systemowych, może być całkowicie nie do zaakceptowania. Przykładami są serwery o znaczeniu krytycznym. Dlaczego programiści nie biorą pod uwagę przenośnych wersji aplikacji, które nie wymagają instalacji?
Od wersji do wersji proces instalacji pakietu Debugging Tools for Windows ulega pewnym zmianom. Przejdźmy teraz od razu do procesu instalacji i przyjrzyjmy się sposobom instalacji zestawu narzędzi.

Instalowanie narzędzi do debugowania w systemie Windows za pomocą instalatora internetowego

Przejdź do strony archiwum Windows SDK i znajdź sekcję o nazwie Windows 10 i poniżej pozycji „Windows 10 SDK (10586) i Microsoft Windows 10 Mobile Device Emulator (wersja 10586.11)”.

Kliknij przedmiot ZAINSTALUJ SDK. Po kliknięciu pobierz i uruchom plik sdksetup.exe, który inicjuje proces instalacji online Windows SDK. Na początkowym etapie instalator sprawdzi, czy pakiet .NET Framework jest zainstalowany w systemie Ostatnia wersja(obecnie 4,5). Jeśli brakuje pakietu, zostanie zaoferowana instalacja, a po zakończeniu stacja zostanie ponownie uruchomiona. Zaraz po ponownym uruchomieniu, na etapie autoryzacji użytkownika, proces instalacji rozpoczyna się bezpośrednio z Windows SDK.

Często przy wyborze wszystkich składników pakietu bez wyjątku mogą wystąpić błędy podczas procesu instalacji. W takim przypadku zaleca się selektywne instalowanie komponentów, minimalnego wymaganego zestawu.

Po zakończeniu instalacji narzędzi debugowania dla systemu Windows lokalizacja plików debugowania przy użyciu tej metody instalacji będzie następująca:

Wersje 64-bitowe: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x64
Wersje 32-bitowe: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x86

* gdzie x.x to konkretna wersja zestawu deweloperskiego;
Czy zauważyłeś, że w wersjach 8 i wyższych ścieżki instalacji wyraźnie różnią się od klasycznych dla wszystkich poprzednich wersji narzędzi do debugowania?

Ogromną zaletą tej metody instalacji Debigging Tools for Windows jest instalacja wersji narzędzi debugowania dla wszystkich architektur jednocześnie.

Instalowanie narzędzi do debugowania dla systemu Windows z systemu Windows SDK ISO

Ta metoda polega na zainstalowaniu narzędzi debugowania dla systemu Windows przy użyciu pełnego obrazu instalacyjnego zestawu Windows SDK (Software Developers Kit). Do pewnego czasu można było pobrać obraz ISO dla odpowiedniego systemu na stronie archiwum Windows SDK. Jednak w tej chwili możesz uzyskać obraz ISO zestawu SDK, uruchamiając instalator internetowy sdksetup.exe i wybierając element Pobierz zestaw programistyczny dla systemu Windows w oknie startowym instalatora:

Jak się okazało, poprzednia metoda instalacji za pomocą instalatora internetowego jest dość kapryśna i często kończy się niepowodzeniem. W czystych systemach instaluje się bez problemów, ale w wystarczająco obciążonych systemach pojawiają się liczne problemy. Jeśli tak jest w Twoim przypadku, użyj tej metody.

W związku z tym na stronie należy wybrać wymagany pakiet dystrybucyjny, dla mnie (a myślę, że dla wielu) w tej chwili jest to „Windows SDK dla Windows 7 i .NET Framework 4” i nieco niżej kliknij link „Pobierz Obraz ISO DVD” .

Podczas pracy z witryną msdn.microsoft.com radzę korzystać z przeglądarki Internet Explorer, ponieważ zaobserwowano przypadki niedziałania konkurencyjnych produktów!

W związku z tym należy wybierać tylko w razie potrzeby. Zazwyczaj bitowość narzędzi debugowania dla systemu Windows jest taka sama jak bitowość systemu. Moje systemy testowe są w większości 64-bitowe, więc w większości przypadków pobieram obraz dla systemu 64-bitowego GRMSDKX_EN_DVD.iso .
Następnie po pobraniu obrazu musimy jakoś popracować z istniejącym obrazem ISO. Tradycyjnym sposobem jest oczywiście wypalenie płyty CD, ale jest to dość długa i czasami kosztowna metoda. Proponuję użyć darmowe narzędzia do tworzenia wirtualnych urządzeń dyskowych w systemie. Osobiście wolę używać do tego celu programu DEAMON Tools Lite. Ktoś może mieć inne preferencje, bardziej bezpośrednie lub lekkie narzędzia, smak i kolor, jak mówią. Po zainstalowaniu DAEMON Tools Lite, po prostu klikam dwukrotnie plik obrazu GRMSDKX_EN_DVD.iso i mam nowy wirtualny dysk kompaktowy:

Następnie, klikając dwukrotnie, aktywuję automatyczne ładowanie i rozpoczynam instalację Windows SDK:

Gdy przychodzi kolej na wybranie z listy komponentów do zainstalowania, wyłączamy absolutnie wszystkie opcje poza zaznaczonymi na zrzucie ekranu. Pomoże nam to już teraz uniknąć niepotrzebnych błędów.

Zgadza się, zrzut ekranu pokazuje dwie opcje: „Windows Performance Toolkit” i „Debugging Tools for Windows”. Wybierz oba, ponieważ Windows Performance Toolkit z pewnością przyda się w Twojej pracy! Ponadto po kliknięciu przycisku „Dalej” instalacja jest kontynuowana w trybie normalnym. A na końcu zobaczysz napis „Instalacja zakończona”.
Po zakończeniu instalacji katalogi robocze zestawu Debugging Tools for Windows będą wyglądać następująco:

Dla wersji x86:
Dla wersji x64:

To kończy instalację narzędzi debugowania dla systemu Windows.

Instalowanie narzędzi do debugowania dla systemu Windows za pomocą pliku .msi

W przypadku problemów podczas instalacji Debugging Tools for Windows na dwa poprzednie sposoby, wciąż mamy jeszcze jeden, najbardziej niezawodny i sprawdzony w czasie, który pomogł, że tak powiem, nie raz. Kiedyś, przed integracją z Windows SDK, Debugging Tools for Windows był dostępny jako osobny instalator .msi, który wciąż można znaleźć, ale już w trzewiach dystrybucji Windows SDK. Ponieważ mamy już pod ręką obraz ISO Windows SDK, nie możemy go zamontować w systemie, ale po prostu otworzyć go za pomocą znanego archiwizatora WinRAR lub dowolnego innego produktu, który współpracuje z zawartością dysków ISO.

Po otwarciu obrazu musimy przejść do katalogu „Setup” znajdującego się w katalogu głównym, a następnie wybrać jeden z katalogów:

Aby zainstalować wersję 64-bitową: \Setup\WinSDKDebuggingTools_amd64 i rozpakuj plik dbg_amd64.msi z tego katalogu.
Aby zainstalować wersję 32-bitową: \Setup\WinSDKDebuggingTools i rozpakuj plik dbg_x86.msi z tego katalogu.

Po zakończeniu instalacji katalogi robocze zestawu Debugging Tools for Windows będą wyglądać następująco:

Dla wersji x86: C:\Program Files (x86)\Debugging Tools for Windows (x86)
Dla wersji x64: C:\Program Files\Debugging Tools for Windows (x64)

W tym momencie instalację narzędzi debugowania dla systemu Windows można uznać za zakończoną.

Dodatkowe informacje

Nie wiem z czym się to wiąże, może z mojej nieuwagi, ale po zainstalowaniu Debugging Tools for Windows instalator nie ustawia ścieżki do katalogu z debuggerem w zmiennej Path system path. Nakłada to pewne ograniczenia na uruchamianie różnych zadań debugowania bezpośrednio z konsoli. Dlatego w przypadku braku ścieżki sam piszę w oknie Zmienne środowiskaścieżka do narzędzi debugowania:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

* W Twoim przypadku ścieżki mogą się różnić zarówno ze względu na użycie systemu operacyjnego o innej bitowości, jak i ze względu na użycie SDK w innej wersji.

Narzędzia pakietu Debugging Tools for Windows mogą działać jako aplikacje przenośne, wystarczy skopiować katalog z działającego systemu Zestaw narzędzi wydajności systemu Microsoft Windows i używać go jako wersji przenośnej na serwerze produkcyjnym. Ale nie zapomnij wziąć pod uwagę pojemności systemu !! Nawet jeśli wykonałeś pełną instalację pakietu w krytycznym systemie, możesz rozpocząć pracę zaraz po instalacji, nie jest wymagane ponowne uruchomienie.

Narzędzia do debugowania dla Windows

A teraz wreszcie, oto skład narzędzi debugowania dla systemu Windows:

Plik	Zamiar
adplus.doc	Dokumentacja narzędzia ADPlus.
adplus.exe	Aplikacja konsolowa, która automatyzuje pracę debuggera cdb w celu tworzenia zrzutów, plików dziennika dla jednego lub więcej procesów.
agestore.exe	Narzędzie do usuwania przestarzałych plików z pamięci używanej przez serwer symboli lub serwer źródłowy.
breakin.exe	Narzędzie, które umożliwia wysyłanie niestandardowej kombinacji przerw do procesów, podobnie jak naciśnięcie CTRL+C.
cdb.exe	Debuger konsoli trybu użytkownika.
convertstore.exe	Narzędzie do konwersji postaci z dwupoziomowej na trzypoziomową.
dbngprx.exe	Ripiter (serwer proxy) do zdalnego debugowania.
dbgpc.exe	Narzędzie do wyświetlania informacji o stanie wywołania RPC.
dbgsrv.exe	Proces serwera używany do zdalnego debugowania.
dbh.exe	Narzędzie do wyświetlania informacji o zawartości pliku symboli.
dumpchk.exe	Narzędzie do weryfikacji zrzutu. Narzędzie do szybkiego sprawdzania pliku zrzutu.
dumpexam.exe	Narzędzie do analizy zrzutu pamięci. Wynik jest wyprowadzany do %SystemRoot%\MEMORY.TXT .
gflags.exe	Edytor globalnych flag systemowych. Narzędzie zarządza kluczami rejestru i innymi ustawieniami.
i386kd.exe	Opakowanie dla kd. Czy tak nazywało się kiedyś kd dla systemów opartych na Windows NT/2000 dla maszyn x86? Prawdopodobnie pozostawiony ze względu na kompatybilność.
ia64kd.exe	Opakowanie dla kd. Czy tak nazywało się kiedyś kd dla systemów opartych na Windows NT/2000 dla maszyn ia64? Prawdopodobnie pozostawiony ze względu na kompatybilność.
kd.exe	Debuger konsoli trybu jądra.
kdbgctrl.exe	Narzędzie do zarządzania debugowaniem jądra. Narzędzie do zarządzania i konfigurowania połączenia debugowania jądra.
kdsrv.exe	Serwer połączeń dla KD. Narzędzie to mała aplikacja, która działa i czeka na połączenia zdalne. kd działa na kliencie i łączy się z tym serwerem w celu zdalnego debugowania. Zarówno serwer, jak i klient muszą pochodzić z tego samego zestawu narzędzi debugowania.
kill.exe	Użyteczność do zakończenia procesów.
list.exe	Narzędzie do wyświetlania zawartości pliku na ekranie. To miniaturowe narzędzie zostało dołączone do jednego celu - przeglądania dużych plików tekstowych lub dzienników. Zajmuje mało miejsca w pamięci, ponieważ ładuje tekst w częściach.
logger.exe	Mały debugger, który może działać tylko z jednym procesem. Narzędzie wstrzykuje plik logexts.dll do przestrzeni procesu, która rejestruje wszystkie wywołania funkcji i inne działania badanego programu.
logviewer.exe	Narzędzie do przeglądania dzienników napisanych przez debuger logger.exe.
ntsd.exe	Debuger symboliczny Microsoft NT (NTSD). Debuger, który jest identyczny z cdb, z tą różnicą, że podczas uruchamiania tworzy okno tekstowe. Podobnie jak cdb, ntsd może debugować zarówno aplikacje konsolowe, jak i aplikacje graficzne.
pdbcopy.exe	Narzędzie do usuwania prywatnych symboli z pliku symboli, kontrolujące publiczne symbole zawarte w pliku symboli.
remote.exe	Narzędzie do zdalnego debugowania i zdalnego sterowania dowolnym debuggerem konsoli KD, CDB i NTSD. Umożliwia zdalne uruchamianie wszystkich tych debugerów konsoli.
rtlist.exe	Zdalna przeglądarka zadań. Narzędzie służy do wyświetlania listy uruchomionych procesów za pośrednictwem procesu serwera DbgSrv.
symchk.exe	Narzędzie do pobierania symboli z serwera symboli firmy Microsoft i tworzenia lokalnej pamięci podręcznej symboli.
symstore.exe	Narzędzie do tworzenia sieci lub lokalnego przechowywania symboli (2-warstwa/3-warstwa). Magazyn symboli to wyspecjalizowany katalog na dysku, który jest zbudowany zgodnie z określoną strukturą i zawiera symbole. W głównym katalogu symboli tworzona jest struktura podfolderów z nazwami identycznymi z nazwami komponentów. Z kolei każdy z tych podfolderów zawiera zagnieżdżone podfoldery o specjalnych nazwach uzyskanych przez haszowanie plików binarnych. Narzędzie symstore skanuje foldery komponentów i dodaje nowe komponenty do magazynu symboli, skąd każdy klient może je pobrać. Mówi się, że symstore jest używany do pobierania symboli z magazynu warstwy 0 i umieszczania ich w magazynie 2-warstwowym/3-warstwowym.
tlist.exe	Przeglądarka zadań. Narzędzie do wyświetlania listy wszystkich uruchomionych procesów.
umdh.exe	Narzędzie sterty zrzutu trybu użytkownika. Narzędzie do analizy stosów wybranego procesu. Pozwala wyświetlić różne opcje sterty.
usbview.exe	Przeglądarka USB. narzędzie do przeglądania Urządzenia USB podłączony do komputera.
vmdemux.exe	Demultiplekser maszyn wirtualnych. Tworzy wiele nazwanych potoków dla jednego połączenia COM. Kanały służą do debugowania różnych komponentów maszyny wirtualnej
windbg.exe	Debuger trybu użytkownika i trybu jądra z graficznym interfejsem użytkownika.

Aby zidentyfikować przyczyny niebieskich ekranów (BSOD), konieczne jest przeanalizowanie zrzutu pamięci. W zdecydowanej większości przypadków wystarczy minizrzut, który jest tworzony przez system w przypadku wystąpienia błędów krytycznych.
Ten artykuł zawiera instrukcje krok po kroku dotyczące instalowania i konfigurowania WinDBG, potężnego narzędzia do debugowania, które pozwala zidentyfikować prawdziwą przyczynę BSOD.

Krok 1 — Konfiguracja nagrywania małego zrzutu pamięci

Krok 2 — Instalacja WinDBG

Aby analizować zrzuty pamięci, musisz zainstalować debugger WinDBG, który jest dołączony do zestawu Windows SDK. W chwili pisania tego tekstu najnowsze dostępne wersje Windows SDK to:

Windows 10 SDK (pobierz instalator online)
Windows 8.1 SDK (pobierz instalator online)

Krok 3 — Mapowanie plików .dmp do WinDBG

Krok 4 — Konfiguracja serwera symboli do odbierania plików symboli debugowania

Instalacja i początkowa konfiguracja WinDBG została zakończona. Aby zmienić jego wygląd, możesz przejść do menu pogląd- ustawienia czcionek znajdziesz wybierając element Czcionka i ustawienia okna konsoli w Opcje.