Sesja zdalnego debugera Windows łączy debugger na jednym komputerze z programem na drugim przez sieć i należy wyłącznie do Twoich własnych komputerów laboratoryjnych. Symbole są priorytetem. Nazwij jeden komputer hostem, a drugi celem. Zbuduj program z symbolami debugowania i zachowaj pasujący PDB dla tej konkretnej kompilacji, ponieważ niezgodny PDB daje błędne nazwy funkcji, a stos bez symboli pokazuje tylko adresy. Zainstaluj StatusRivet na hoście, gdzie pracujesz, a cel pozostaw wyłącznie dla programu testowanego. Zapisz każdą zmianę ustawień na obu komputerach, aby móc je przywrócić później. Odtwórz awarię przy użyciu najmniejszego możliwego wejścia, ponieważ krótki przypadek daje krótki stos i łatwiejszą różnicę. Sprawdź, czy host i cel mogą się nawzajem osiągnąć, zanim poprosisz agenta o działanie, ponieważ nieudane połączenie wygląda jak awaria debugera.
Wybierz folder ze źródłami i plikami kompilacji jako folder roboczy czatu, ponieważ narzędzia do plików czytają i edytują tylko wewnątrz niego. Umieść tam również zapisany stos i notatki, aby cały przypadek znajdował się w jednym miejscu i agent mógł go przeczytać w całości.
Ask first pauzuje przed akcjami, które coś zmieniają, więc możesz przeczytać każdą z nich przed uruchomieniem. Użyj Plan only, gdy chcesz najpierw zobaczyć kroki i nie uruchamiać niczego. Plan przetrwa restart, więc możesz wrócić do niego później.
Podaj nazwę programu, komputery host i cel oraz objaw i powiedz, że komputery są Twoje. Podaj szczegóły połączenia z własnych notatek laboratoryjnych i nie zgaduj ich. Podaj, która kompilacja działa na celu i który PDB do niej należy.
Przeczytaj różnicę, zbuduj ponownie za pomocą polecenia kompilacji i uruchom ponownie polecenie testowe na celu. Zachowaj notatki o zmianach w liście kontrolnej i zachowaj stary zrzut, jeśli nowy test nadal się nie powiedzie, aby następna próba zaczynała się od dowodów, a nie z pamięci.
attach your debugger to the targetpołączonosave the dump on the targetzapisanowrite the call stack to stack.txtzapisanostack.txtprzeczytano0xC0000005 stack.txt1 dopasowanie# Debug session checklist
1. Build the app with debug symbols and keep the PDB
2. Note the build the crash happened on
3. Start the debugger on the host machine
4. Attach to the app running on the target
5. Reproduce the crash with the smallest input
6. Save a crash dump on the target
7. Save the faulting thread's call stack to stack.txt
8. Read the exception code and the top frames
9. Match the first frame to a source line
10. Propose a minimal fix and rebuild
11. Run the test again and note what changedProsta lista kontrolna w formacie tekstowym dla jednej sesji debugowania między dwoma komputerami laboratoryjnymi. Obejmuje budowanie z symbolami, podłączanie, odtwarzanie awarii przy użyciu najmniejszego wejścia, zapisywanie zrzutu i stosu wywołań, czytanie najważniejszych ramek i kończy się uruchomieniem testu po poprawce, z notatkami o zmianach. Skopiuj go do folderu projektu i edytuj, aby pasował do Twojego laboratorium. Skopiuj i edytuj.
Zadanie: podłącz się z komputera hosta do własnego programu działającego na komputerze docelowym w laboratorium. Najpierw się podłącz. Otwórz folder projektu w StatusRivet, przełącz na Ask first i opisz konfigurację. Shell uruchamia tryb wiersza poleceń debugera z podanymi szczegółami połączenia, a karta pokazuje, czy podłączenie powiodło się na podstawie rzeczywistego kodu wyjścia. Agent nie wymyśla ustawień połączenia, więc pobierz host, cel i port z własnych notatek laboratoryjnych. Debugowanie zdalne dotyczy wyłącznie własnych komputerów laboratoryjnych, nigdy komputera, którego nie posiadasz. Przeczytaj kartę przed kolejnym krokiem. Jeśli podłączenie się nie powiodło, nic innego nie powinno działać, a najpierw naprawiasz połączenie, a potem prosisz ponownie. Karta również przechowuje dokładne polecenie, więc możesz je powtórzyć później.
Zadanie: po odtworzeniu awarii na celu przy użyciu najmniejszego wejścia zapisz dowody. Zapisz oba pliki. Shell prosi debugger o zapisanie zrzutu awarii i zapisanie stosu wywołań wątku powodującego awarię do pliku tekstowego, a karty pokazują oba wyniki. wpis debugera JIT systemu Windows na komputerze docelowym uruchamia debugger automatycznie po awarii aplikacji. Jest to ustawienie systemowe, więc zmieniaj je tylko na komputerze testowym, zapisz poprzednią wartość i przywróć ją później. Aby znaleźć przyczynę awarii systemu z minizrzutu, zacznij od zapisanego stosu wywołań. Zatwierdzasz każdy krok w Trybie Ask first i zachowasz oba pliki z listą kontrolną dla następnej osoby czytającej przypadek. Nazwij pliki według kompilacji, aby nikt ich nie pomylił.
Zadanie: połącz najwyższą ramkę ze swoim kodem. Zacznij od symboli. read_file otwiera stack.txt, grep wyszukuje w projekcie nazwę funkcji i kod wyjątku, taki jak 0xC0000005 dla naruszenia dostępu, a read_file otwiera plik źródłowy w tej linii. Przy pasującym PDB stos pokazuje nazwy funkcji, pliki źródłowe i numery linii, podczas gdy bez niego widzisz tylko adresy. Zamarzający komputer kończący się BSOD z błędem sprawdzania bezpieczeństwa jądra to przypadek dla dokładnie tego samego procesu: zrzut, stos, źródło. Przeczytaj dowody samodzielnie, zanim agent cokolwiek edytuje, ponieważ agent pracuje na tekście i nie może krokowo przechodzić przez program dla Ciebie. Do krokowania użyj własnego debugera i powiedz agentowi, co widziałeś.
Zadanie: zamień ustalenia w zmianę. edit_file proponuje minimalną różnicę, na przykład brakujące sprawdzenie null lub zły indeks, a w Trybie Ask first agent pauzuje, abyś mógł przeczytać zmienione linie. Shell następnie uruchamia polecenie kompilacji z symbolami i polecenie testowe, a karty raportują rzeczywiste kody wyjścia. Awaria BSOD z uszkodzeniem sterty w trymie jądra w sterowniku, który napisałeś, może pojawić się długo po złym zapisie, więc sprawdź bufory zapisane wcześniej w stosie, a nie tylko ostatnią ramkę. Nieoczekiwany wyjątek store BSOD na Twoim komputerze docelowym w laboratorium jest obsługiwany w ten sam sposób. Przyjmij różnicę tylko po przejściu testu i zapisz, co się zmieniło. Przetestuj przed przyjęciem. Jeśli test nadal się nie powiedzie, zachowaj nowy stos i rozpocznij pętlę ponownie od drugiego kroku.
