Dowiedz się, jak podejście Marka Russinovicha z Windows Internals ukształtowało Sysinternals, workflowy WinDbg i praktyczną obserwowalność do debugowania i zwiększania niezawodności na Windows.
Jeśli uruchamiasz Windows w produkcji — na laptopach, serwerach, VDI lub VM w chmurze — prace Marka Russinovicha nadal mają wpływ na codzienne operacje. Nie dlatego, że to kwestia osobowości czy nostalgii, lecz dlatego że spopularyzował podejście „evidence-first” do rozwiązywania problemów: najpierw sprawdź, co system naprawdę robi, a potem wyjaśnij symptomy dowodami.
Obserwowalność oznacza, że potrafisz odpowiedzieć „co się dzieje teraz?” korzystając z sygnałów, które system generuje (zdarzenia, śledzenia, liczniki). Gdy usługa zwalnia albo logowania wiszą, obserwowalność to różnica między zgadywaniem a wiedzą.
Debugowanie to przekształcenie nieokreślonego problemu ("zawiesił się") w konkretny mechanizm ("ten wątek oczekuje na I/O", "ten proces intensywnie korzysta z pliku wymiany", "wstrzyknięcie DLL zmieniło zachowanie").
Niezawodność to zdolność do pracy pod obciążeniem i przewidywalnego odzysku — mniej incydentów, szybsze przywrócenia i bezpieczniejsze zmiany.
Większość „tajemniczych awarii” wcale nie jest tajemnicami — to zachowania Windows, których jeszcze nie zmapowałeś: wycieki uchwytów, rozbiegające się procesy potomne, zablokowane sterowniki, opóźnienia DNS, uszkodzone wpisy auto-start, albo narzędzia zabezpieczające dodające narzut. Podstawowe rozumienie wewnętrzności Windows (procesy, wątki, uchwyty, usługi, pamięć, I/O) pomaga szybko rozpoznać wzorce i zebrać właściwe dowody zanim problem zniknie.
Skoncentrujemy się na praktycznych, przyjaznych dla operacji workflowach z użyciem:
Celem nie jest uczynić z Ciebie inżyniera jądra. Chodzi o to, by incydenty Windows były krótsze, spokojniejsze i łatwiejsze do wytłumaczenia — dzięki temu poprawki są bezpieczniejsze i powtarzalne.
„Internals” Windows to po prostu zbiór mechanizmów, za pomocą których Windows wykonuje pracę: planowanie wątków, zarządzanie pamięcią, uruchamianie usług, ładowanie sterowników, obsługa plików i rejestru oraz egzekwowanie granic bezpieczeństwa. Praktyczna obietnica jest prosta: gdy rozumiesz, co system robi, przestajesz zgadywać i zaczynasz wyjaśniać.
To ważne, ponieważ większość objawów operacyjnych jest pośrednia. „Maszyna jest wolna” może oznaczać konkurencję o CPU, pojedynczy gorący wątek, burzę przerwań sterownika, presję stronicowania lub filtr antywirusowy blokujący I/O. „Zawiesza się” może być skutkiem zakleszczenia, zablokowanego wywołania sieciowego, timeoutu magazynu lub usługi czekającej na zależność. Problemy z rozruchem to często uszkodzony wpis autorun, nieudane ładowanie sterownika lub skrypt polityki, który nigdy się nie kończy. Wiedza o internals zmienia niejasne skargi w testowalne hipotezy.
Na ogólnym poziomie tryb użytkownika to miejsce, gdzie działają większość aplikacji i usług. Gdy się wywracają, zwykle zabierają tylko siebie. Tryb jądra to miejsce, gdzie działa sam Windows i sterowniki; problemy tam mogą zamrozić cały system, sprowokować bugcheck (blue screen) lub cicho pogarszać niezawodność.
Nie potrzebujesz głębokiej teorii, by użyć tej dychotomii — wystarczy tyle, by wybrać dowody. Aplikacja mocno obciążająca CPU to często tryb użytkownika; powtarzające się resetowanie urządzeń pamięci masowej lub problemy ze sterownikiem sieci często wskazują na jądro.
Myślenie Russinovicha — widoczne w narzędziach Sysinternals i w książce Windows Internals — to „najpierw dowód”. Zanim zmienisz ustawienia, zresetujesz maszynę na ślepo czy przeinstalujesz, zarejestruj, co system robi: który proces, który wątek, który uchwyt, który klucz rejestru, jakie połączenie sieciowe, który sterownik, jakie zdarzenie.
Gdy potrafisz odpowiedzieć „co Windows robi teraz i dlaczego”, naprawy stają się mniejsze, bezpieczniejsze i łatwiejsze do uzasadnienia — a praca nad niezawodnością przestaje być gaśnicą pożarów.
Sysinternals najlepiej rozumieć jako zestaw narzędzi do widoczności Windows: małe, przenośne narzędzia, które ujawniają, co system naprawdę robi — proces po procesie, uchwyt po uchwycie, klucz rejestru po kluczu. Zamiast traktować Windows jako czarną skrzynkę, Sysinternals pozwala obserwować zachowanie kryjące się za objawami typu „aplikacja jest wolna”, „CPU jest wysokie” czy „serwer traci połączenia”.
Wiele problemów operacyjnych bierze się z rozsądnie brzmiących przypuszczeń: to musi być DNS, pewnie antywirus, Windows Update znowu utknął. Podejście Sysinternals jest proste: zrób hipotezę, ale zweryfikuj ją dowodami.
Gdy widzisz, który proces zużywa CPU, który wątek czeka, jaka ścieżka pliku jest eksploatowana lub która wartość rejestru jest ciągle nadpisywana, przestajesz debatować nad opiniami i zaczynasz zawężać przyczyny. Ta zmiana — z narracji na pomiar — sprawia, że wiedza o internals staje się praktyczna, nie akademicka.
Narzędzia te są stworzone na moment „wszystko płonie":
To ważne, gdy nie możesz sobie pozwolić na długi cykl konfiguracji, rozsyłanie ciężkich agentów czy reboot tylko po to, by zebrać lepsze dane.
Sysinternals jest potężny i wymaga zasad:
Stosowane w ten sposób, narzędzia Sysinternals stają się zdyscyplinowaną metodą: obserwuj niewidoczne, mierz prawdę i wprowadzaj zmiany uzasadnione, nie oparte na nadziei.
Jeśli w zestawie admina trzymasz tylko dwa narzędzia Sysinternals, niech to będą Process Explorer i Process Monitor. Razem odpowiadają na najczęstsze pytania „co Windows robi teraz?” bez agenta, rebootu czy ciężkiej konfiguracji.
Process Explorer to Menedżer zadań z rentgenem. Gdy maszyna jest wolna lub niestabilna, pomaga ustalić który proces jest odpowiedzialny i z czym jest powiązany.
Szczególnie przydatny do:
Ten ostatni punkt to siła niezawodności: „dlaczego nie mogę usunąć tego pliku?” często odpowiada „ta usługa trzyma uchwyt do niego”.
Process Monitor (Procmon) przechwytuje szczegółowe zdarzenia w zakresie systemu plików, rejestru i aktywności procesów/wątków. To narzędzie do pytań typu: „co się zmieniło, gdy aplikacja zawiesiła się?” lub „co powoduje tłuczenie dysku co 10 minut?”
Przed włączeniem Capture sformułuj pytanie:
Procmon może przytłoczyć, jeśli nie filtrujesz agresywnie. Zacznij od:
Typowe, praktyczne wyniki: zidentyfikowanie usługi, która nieprawidłowo pyta o brakujący klucz rejestru; wykrycie „real-time” skanera dotykającego tysięcy plików; znalezienie nieudanego ładowania DLL („NAME NOT FOUND”), które tłumaczy dlaczego aplikacja nie uruchamia się na jednej maszynie, a na innej tak.
Gdy maszyna Windows „nie działa jak trzeba”, często nie potrzebujesz pełnego stosu monitoringu, by ruszyć z miejsca. Mały zestaw narzędzi Sysinternals szybko odpowie na trzy praktyczne pytania: co startuje automatycznie? co rozmawia w sieci? gdzie podziała się pamięć?
Autoruns to najszybszy sposób, by zrozumieć wszystko, co może uruchomić się bez interwencji użytkownika: usługi, zadania zaplanowane, rozszerzenia powłoki, sterowniki i więcej.
Dlaczego to ważne dla niezawodności: elementy startowe są częstym źródłem wolnego rozruchu, przerywanych zawieszeń i spike’ów CPU pojawiających się po zalogowaniu. Jeden niestabilny updater, pomocnik starego sterownika czy uszkodzone rozszerzenie powłoki może pogorszyć działanie całego systemu.
Praktyczna wskazówka: skup się na wpisach niepodpisanych, ostatnio dodanych lub błędnie ładujących się. Jeśli wyłączenie pozycji stabilizuje maszynę, przekształciłeś niejasny objaw w konkretny komponent do aktualizacji, usunięcia lub zastąpienia.
TCPView daje natychmiastową mapę aktywnych połączeń i portów nasłuchu, powiązanych z nazwami procesów i PID. To idealne narzędzie do szybkich kontroli zdrowia:
Nawet w przypadku śledztw nie-szpiegowskich, może to ujawnić rozbiegające się agenty, źle skonfigurowane proxy lub „burze retryów”, gdzie aplikacja wydaje się wolna, a przyczyną jest zachowanie sieciowe.
RAMMap pomaga zinterpretować presję pamięci, pokazując gdzie RAM jest faktycznie alokowany.
Przydatne rozróżnienie:
Jeśli użytkownicy zgłaszają „mało pamięci”, a Menedżer zadań wygląda myląco, RAMMap potwierdzi, czy masz rzeczywisty wzrost procesów, duży cache plików czy sterownik zużywający pamięć niepaged.
Jeśli aplikacja zwalnia w ciągu dni, Handle pokaże rosnące liczby uchwytów (klasyczny wzorzec wycieku). VMMap pomaga, gdy użycie pamięci jest dziwne — fragmentacja, duże zarezerwowane regiony lub alokacje, które nie pojawiają się jako proste „private bytes”.
Operacje na Windows często zaczynają się od najłatwiejszych do złapania rzeczy: Podglądu zdarzeń i kilku zrzutów z Menedżera zadań. To dobre na okruszki, ale rzetelna reakcja na incydenty potrzebuje trzech typów sygnałów: logów (co się stało), metryk (jak bardzo to było złe) i śledzeń (co system robił krok po kroku).
Dzienniki zdarzeń Windows są doskonałe dla tożsamości, cykli życia usług, zmian polityk i błędów aplikacji. Są też nierównomierne: niektóre komponenty logują obficie, inne oszczędnie, a tekst komunikatów bywa niejasny ("The application stopped responding"). Traktuj je jako oś czasu, nie cały obraz.
Typowe sukcesy:
Liczniki wydajności odpowiadają „czy maszyna jest zdrowa?” Podczas awarii zacznij od:
Metryki nie powiedzą ci dlaczego wystąpił spike, ale powiedzą kiedy się zaczął i czy się poprawia.
Event Tracing for Windows (ETW) to wbudowany rejestrator systemu. Zamiast ad-hoc wiadomości tekstowych, ETW emituje ustrukturyzowane zdarzenia z jądra, sterowników i usług z wysoką częstotliwością — aktywność procesów/wątków, I/O plików, dostęp do rejestru, TCP/IP, planowanie i więcej. Na tym poziomie wiele „tajemniczych zacięć” staje się wytłumaczalnych.
Praktyczna zasada:
Unikaj „włączania wszystkiego na zawsze”. Trzymaj mały, zawsze włączony baseline (kluczowe logi + podstawowe metryki) i używaj krótkich, ukierunkowanych przechwyceń ETW podczas incydentów.
Najszybsze diagnozy pochodzą z wyrównania trzech zegarów: raportów użytkowników ("10:42 zawiesiło się"), punktów zwrotnych metryk (spike CPU/dysk) i zdarzeń/logów/ETW z tym samym znacznikiem czasu. Gdy Twoje dane mają spójny czas, awarie przestają być zgadywaniem i stają się narracją, którą możesz zweryfikować.
Domyślne dzienniki Windows są użyteczne, ale często nie pokazują „dlaczego teraz?” — detali operatorom potrzebnych, gdy coś zmienia się niespodziewanie. Sysmon (System Monitor) wypełnia tę lukę, rejestrując zdarzenia o wyższej rozdzielczości dotyczące aktywności procesów i systemu — zwłaszcza uruchomień, mechanizmów trwałości i zachowań sterowników.
Siła Sysmon to kontekst. Zamiast samego „usługa uruchomiona”, często widzisz który proces ją uruchomił, z pełną linią poleceń, procesem nadrzędnym, hashami, kontem użytkownika i czystymi znacznikami czasu do korelacji.
To przydatne dla niezawodności, bo wiele incydentów zaczyna się od „małych” zmian: nowe zadanie zaplanowane, cichy updater, niechciany skrypt lub sterownik, który zachowuje się źle.
Konfiguracja „loguj wszystko” rzadko jest dobrym pierwszym krokiem. Zacznij od minimalnego, niezawodnościowego zestawu i rozszerzaj tylko gdy masz jasne pytania.
Dobre wczesne kandydatury:
Dostosuj z ukierunkowanymi regułami include (kluczowe ścieżki, konta usługowe, ważne serwery) i starannie dobranymi exclude (hałaśliwe updatery, zaufane agentury zarządzające), by sygnał pozostał czytelny.
Sysmon często pomaga potwierdzić lub wykluczyć scenariusze „tajemniczej zmiany”:
Testuj wpływ na reprezentatywnych maszynach. Sysmon może zwiększyć I/O dysku i wolumen zdarzeń, a centralne zbieranie może szybko stać się kosztowne.
Traktuj też pola takie jak linie poleceń, nazwy użytkowników i ścieżki jako wrażliwe. Stosuj kontrolę dostępu, limity retencji i filtrowanie przed szerokim wdrożeniem.
Sysmon najlepiej traktować jako wartościowe okruszki. Używaj go wraz z ETW do głębokich pytań wydajnościowych, metryk do wykrywania trendów i zdyscyplinowanych notatek incydentowych, żeby móc połączyć co się zmieniło z tym, co się zepsuło i jak to naprawiłeś.
Gdy coś „po prostu pada”, najcenniejszym artefaktem bywa często plik zrzutu: migawka pamięci plus stan wykonania, pozwalające odtworzyć, co proces (lub OS) robił w momencie awarii. W przeciwieństwie do logów, zrzuty nie wymagają przewidzenia właściwego komunikatu — rejestrują dowód po fakcie.
Zrzuty mogą wskazać konkretny moduł, ścieżkę wywołań i typ błędu (naruszenie dostępu, korupcja sterty, deadlock, błąd sterownika), co trudno wywnioskować na podstawie samych objawów.
WinDbg zmienia zrzut w opowieść. Najważniejsze:
Typowy workflow: otwórz zrzut → wczytaj symbole → uruchom automatyczną analizę → zweryfikuj najwyższe stosy i zaangażowane moduły.
„Zawiesiło się” to objaw, nie diagnoza. Dla hangów zrób zrzut, gdy aplikacja jest nieodpowiedzialna i sprawdź:
Często możesz samodzielnie zdiagnozować oczywiste problemy (powtarzalne crashy w jednym module, ewidentne deadlocki, silna korelacja z konkretną DLL/sterownikiem). Eskaluj, gdy zrzuty wskazują sterowniki firm trzecich, komponenty jądra lub gdy brakuje symboli/dostępu do kodu źródłowego — wtedy może być potrzebny dostawca (lub Microsoft), by odczytać pełny łańcuch przyczyn.
Wiele „tajemniczych” problemów Windows powtarza te same wzorce. Różnica między zgadywaniem a naprawą to zrozumienie, co system robi — a model mentalny Internals/Sysinternals pomaga to zobaczyć.
Gdy ludzie mówią „aplikacja wycieka pamięć”, często mają na myśli dwóch rzeczy.
Working set to fizyczna pamięć aktualnie przypisana procesowi. Może się ona wahać, gdy Windows przycina jej część pod presją.
Commit to ilość pamięci wirtualnej, którą system obiecał zrealizować RAMem lub plikiem wymiany. Jeśli commit rośnie wciąż w górę, masz realne ryzyko wycieku: doprowadzi to do osiągnięcia limitu commit i błędów alokacji lub niestabilności hosta.
Częsty objaw: Menedżer zadań pokazuje „dostępną pamięć”, ale maszyna i tak zwalnia — bo ograniczeniem jest commit, nie wolna pamięć.
Uchwyt to referencja do obiektu OS (plik, klucz rejestru, event, sekcja itd.). Jeśli usługa przecieka uchwyty, może działać godziny lub dni, a potem zaczyna się sypać dziwnymi błędami (nie można otworzyć plików, nie można utworzyć wątków, nie można zaakceptować połączeń), gdy liczba uchwytów na proces rośnie.
W Process Explorer obserwuj trend liczby uchwytów w czasie. Stały wzrost to silna wskazówka, że usługa „zapomina zamykać” coś.
Problemy ze storage nie zawsze objawiają się wysokim przepływem; często widzisz duże opóźnienia i retry. W Process Monitorze szukaj:
Zwróć też uwagę na filter drivers (AV, backup, DLP). Mogą wstrzykiwać się w ścieżkę I/O i dodawać opóźnienia lub błędy bez żadnej winy po stronie aplikacji.
Pojedynczy gorący proces jest prosty: jeden wykonywalny spala CPU.
Systemowa konkurencja jest trudniejsza: CPU wysokie, bo wiele wątków jest gotowych i walczy o blokady, dysk lub pamięć. Myślenie internals skłania do pytania: „Czy CPU wykonuje użyteczną pracę, czy kręci się w miejscu czekając na coś innego?”
Gdy występują timeouty, zamapuj proces → połączenie za pomocą TCPView lub Process Explorer. Jeśli zła aplikacja ma socket, masz konkretną przyczynę. Jeśli właściwy proces ma socket, patrz na wzorce: próby SYN, długie połączenia bez aktywności lub lawina krótkich połączeń sugerują problemy DNS/firewall/proxy, a nie „aplikacja nie działa”.
Praca nad niezawodnością staje się łatwiejsza, gdy każdy incydent podąża tą samą ścieżką. Celem nie jest „uruchomić więcej narzędzi”, lecz podejmować lepsze decyzje z konsekwentnymi dowodami.
Zapisz, jak wygląda „źle” w jednym zdaniu: „Aplikacja zawiesza się na 30–60 sekund przy zapisie dużego pliku” albo „CPU skacze do 100% co 10 minut”. Jeśli możesz odtworzyć, rób to; jeśli nie, zdefiniuj wyzwalacz (okno czasowe, obciążenie, akcja użytkownika).
Zanim zbierzesz ciężkie dane, potwierdź objaw i zakres:
Szybkie kontrole (Task Manager, Process Explorer, podstawowe liczniki) pomagają wybrać, co przechwycić dalej.
Zbieraj dowody jakbyś miał przekazać je koledze, który nie był na miejscu. Dobry plik sprawy zwykle zawiera:
Trzymaj przechwyty krótkie i ukierunkowane. 60-sekundowy ślad obejmujący okno awarii bije 6-godzinny zapis, którego nikt nie otworzy.
Przetłumacz zebrane dane na prostą narrację:
Jeśli nie potrafisz prosto wyjaśnić, prawdopodobnie potrzebujesz czystszego przechwycenia lub węższej hipotezy.
Zastosuj najmniejszą bezpieczną poprawkę, a potem potwierdź ją tymi samymi krokami reprodukcji i „przed vs po” przechwyceniami.
Aby zmniejszyć MTTR, ustandaryzuj playbooki i zautomatyzuj nudne czynności:
Po rozwiązaniu zapytaj: „Jaki sygnał sprawiłby, że to byłoby oczywiste wcześniej?” Dodaj ten sygnał — zdarzenie Sysmon, provider ETW, licznik wydajności lub lekki health check — żeby następny incydent był krótszy i spokojniejszy.
Sens pracy z internals nie polega na „wygranej” w debugowaniu — chodzi o przekształcenie obserwacji w zmiany, które zapobiegają powrotowi incydentu.
Narzędzia internals zwykle zawężają problem do małego zestawu dźwigni. Tłumacz wyniki jasno:
Zapisz „bo dlatego”: „Zmieniliśmy X, ponieważ w Process Monitor / ETW / zrzutach zaobserwowaliśmy Y.” To zdanie zapobiega rozmyciu wiedzy.
Dopasuj proces zmiany do potencjalnego zasięgu wpływu:
Nawet gdy przyczyna jest specyficzna, trwałość często pochodzi z powtarzalnych wzorców:
Zachowaj to, co potrzebne, i chroń to, czego nie powinieneś zbierać.
Ogranicz filtry Procmon do podejrzanych procesów, zamaskuj ścieżki/użytkowników przed udostępnieniem, ustaw retencję dla ETW/Sysmon i unikaj ciężkich przechwyceń sieciowych, jeśli nie są konieczne.
Gdy masz powtarzalny workflow, kolejny krok to opakowanie go, żeby inni mogli go uruchamiać konsekwentnie. Tutaj platforma vibe-codingowa jak Koder.ai może być przydatna: przekształcisz checklistę incydentu w małą wewnętrzną aplikację (React UI, backend w Go z PostgreSQL), która poprowadzi reagujących przez „observe → capture → explain”, przechowa znaczniki czasu i artefakty oraz ustandaryzuje nazewnictwo i strukturę plików sprawy.
Ponieważ Koder.ai buduje aplikacje przez chat z agentową architekturą, zespoły mogą szybko iterować — dodając przycisk „start ETW session”, bibliotekę szablonów filtrów Procmon, snapshot/rollback zmian czy generator eksportowalnych runbooków — bez przebudowy całego pipeline’u deweloperskiego. Jeśli dzielisz praktyki niezawodności, Koder.ai wspiera też eksport kodu źródłowego i plany od darmowego do enterprise, więc możesz zacząć mało i skalować zarządzanie później.
Raz w tygodniu wybierz jedno narzędzie i 15-minutowe ćwiczenie: prześledź wolne uruchamianie aplikacji z Procmon, przejrzyj drzewo usług w Process Explorer, sprawdź wolumen zdarzeń Sysmon albo pobierz jeden zrzut i zidentyfikuj moduł, który zawodzi. Małe powtórzenia budują pamięć mięśniową, która sprawia, że prawdziwe incydenty są szybsze — i bezpieczniejsze.
Mark Russinovich spopularyzował podejście „evidence-first” do rozwiązywania problemów w Windows i dostarczył (oraz wpłynął na powstanie) narzędzi, dzięki którym system stał się praktycznie obserwowalny.
Nawet jeśli nigdy nie czytałeś książki Windows Internals, prawdopodobnie polegasz na workflowach kształtowanych przez Sysinternals, ETW i analizę zrzutów, które skracają czas reakcji i sprawiają, że poprawki są powtarzalne.
Obserwowalność to zdolność odpowiedzenia na pytanie „co się dzieje teraz?” na podstawie sygnałów systemowych.
Na Windowsie zwykle oznacza to połączenie:
Znajomość wewnętrznej budowy Windows pozwala zmienić niejasne objawy w testowalne hipotezy.
Na przykład „serwer jest wolny” można zawęzić do mechanizmów: konfliktów CPU, presji stron pamięci, opóźnień I/O czy narzutu sterowników/filtrów. To przyspiesza triage i pomaga zebrać właściwe dowody, zanim problem zniknie.
Użyj Process Explorer, gdy chcesz szybko ustalić kto odpowiada za problem.
Jest przydatny do szybkich odpowiedzi, np.:
Process Monitor sprawdza się, gdy potrzebujesz śledzenia aktywności w systemie plików, rejestrze i operacjach procesów/wątków.
Przykłady praktyczne:
Filtruj agresywnie i przechwytuj tylko okno, w którym występuje błąd.
Dobry workflow startowy:
Mały, analizowalny ślad jest lepszy niż ogromny, którego nikt nie otworzy.
Autoruns odpowiada na pytanie „co uruchamia się automatycznie?” — usługi, zadania zaplanowane, rozszerzenia powłoki, sterowniki i więcej.
Szczególnie przydatne do:
Skup się najpierw na wpisach , lub , i wyłączaj po jednym z notatką.
ETW (Event Tracing for Windows) to wbudowany rejestrator zdarzeń systemu.
Użyj ETW, gdy logi i metryki mówią, że coś jest nie tak, ale nie wyjaśniają dlaczego — np. zatory powodowane przez opóźnienia I/O, opóźnienia planowania, zachowanie sterowników czy timeouty zależności. Trzymaj przechwyty krótkie, ukierunkowane i skorelowane w czasie z raportowanym objawem.
Sysmon dodaje kontekst wysokiej wartości (proces nadrzędny/dziecko, linia poleceń, skróty, hashe, ładowania sterowników), który pomaga odpowiedzieć „co się zmieniło?”
Dla niezawodności przydatne jest potwierdzenie:
Zacznij od minimalnej konfiguracji i dostosowuj include/exclude, by kontrolować objętość zdarzeń.
Zrzut pamięci często jest najcenniejszym artefaktem dla crashy i hangów — to migawka pamięci i stanu wykonania w momencie awarii.
WinDbg przekształca zrzut w historię: symbole, stosy i identyfikację komponentu, który zawiódł. Poprawne symbole są kluczowe.
