Zadania debugera x64: od logu awarii do przetestowanej poprawki

Co robi StatusRivet

• Plikiread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep i glob działają w folderze roboczym czatu, a licznik pokazuje liczbę utworzonych, edytowanych i odczytanych plików.
• Shelluruchamia kompilacje, linter, testy i tryb konsolowy debugera na Windows, w WSL lub przez SSH na serwerze, który posiadasz; sukces jest oceniany na podstawie rzeczywistego kodu wyjścia, a niebezpieczne polecenia są blokowane.
• Siećweb_search znajduje strony, a http_get czyta jedną oficjalną stronę dokumentacji, np. aby sprawdzić znaczenie kodu wyjątku przed podjęciem działania.
• Zrzuty ekranu i obrazyodczytuje tekst z zapisanego zrzutu ekranu, np. okna błędu, a gen_image zapisuje rzeczywiste pliki obrazów.
• Orkiestracjatask uruchamia równoległe pod-agenty, run_on_model wysyła trudny krok do większego modelu, a skill przechowuje wielokrotnie używane scenariusze, w tym kontrolę wersji.
• Tryby zatwierdzaniaAuto-run działa natychmiast, Ask first pauzuje przed akcjami zmieniającymi stan, a Plan only zapisuje plan i nic nie uruchamia.
• Cronuruchamia prompt według harmonogramu, np. uruchomienie testów na maszynie laboratoryjnej, a wynik pojawia się na czacie jak każda inna akcja, z tymi samymi kartami i tym samym outputem.
• Modeledostawca AI w chmurze przez standardowy endpoint API, model na Twoim PC lub wbudowany model; przycisk Test sprawdza endpoint i pokazuje czas odpowiedzi oraz okno kontekstowe.

Cztery zadania debugowania krok po kroku

Przeczytaj stos wywołań awarii

Zadanie: Twoja aplikacja uległa awarii na maszynie testowej, a masz stos wywołań, który Twój debugger x64 zapisał jako tekst. read_file ładuje stack.txt, a grep szuka kodu wyjątku w logu, np. 0xC0000005 dla naruszenia dostępu. Następnie agent wypisuje najważniejsze ramki wątku powodującego awarię i otwiera plik źródłowy pasujący do pierwszej ramki. Każda akcja pojawia się na czacie jako karta, a możesz ją rozwinąć, aby przeczytać pełny output. Jeśli boot bsod zostawia wpis błędu jądra 41 w dzienniku zdarzeń, zrzut zapisany wokół tego czasu, jeśli istnieje, zawiera stan, którego potrzebujesz. Zacznij od początku. Przeczytaj ramki samodzielnie, ponieważ agent działa na podstawie outputu tekstowego, a następnie zaakceptuj lub odrzuć proponowany diff w trybie Ask first.

Napraw przepełnienie stosu

Zadanie: log pokazuje 0xC00000FD, kod wyjątku dla przepełnienia stosu, a chcesz znaleźć funkcję, która rekurencyjnie się wywołała. grep przeszukuje kod źródłowy pod kątem nazwy funkcji z najwyższych ramek, a read_file otwiera ją, aby agent mógł zobaczyć, jak rekurencja się kończy. edit_file proponuje minimalny diff, np. brakujący warunek stopu, i pokazuje dokładnie, które linie się zmieniają. Shell następnie uruchamia polecenie kompilacji i polecenie testu, a każda karta raportuje rzeczywisty kod wyjścia. bsod z kodem stopu zarządzania pamięcią to inna awaria, ale metoda jest taka sama: znajdź wyjątek, przeczytaj stos, testuj jedną zmianę na raz. Zachowaj każdą zmianę małą. Przeglądaj diff i wynik testu przed zapisaniem czegokolwiek i uruchom test jeszcze raz po ostatniej edycji.

Sprawdź ustawienie debugowania JIT

Zadanie: zanim polegasz na debuggerze w czasie awarii, sprawdź wartość debugowania JIT na maszynie testowej. JIT oznacza just-in-time: Windows automatycznie uruchamia debugger, gdy aplikacja ulegnie awarii, i jest to ustawienie systemowe. Shell wykonuje podane przez Ciebie polecenie do odczytu bieżącej wartości, a write_file zapisuje tę wartość do settings-before.txt, więc stara wartość jest zapisana. Zmień ją tylko na maszynie testowej, nigdy na swoim codziennym PC, i przywróć zapisaną wartość później. W trybie Ask first agent pauzuje przed każdą akcją zmieniającą stan, więc zatwierdzasz zmianę i przywrócenie osobno. Zapisz wartość. Przeczytaj zapisany plik przed rozpoczęciem i przeczytaj go ponownie przed przywróceniem wartości.

Debuguj sterownik na celu laboratoryjnym

Zadanie: sterownik, który napisałeś, powoduje awarię celu testowego i potrzebujesz funkcji powodującej awarię. Praca na poziomie jądra zwykle wymaga dwóch maszyn lub maszyny wirtualnej, jednej uruchamiającej debugger i jednej jako celu testowego, połączonych połączeniem debugowania, a cel pozostaje w laboratorium. Shell uruchamia polecenia przez SSH na maszynie laboratoryjnej, którą posiadasz, read_file czyta tekst zapisany przez debugger, a grep dopasowuje nazwę modułu do kodu źródłowego. Na nowym komputerze bsod z naruszeniem limitu czasu dpc może wynikać ze sterownika, który piszesz, więc stos utknątego wątku jest pierwszą rzeczą do przeczytania. Zachowaj to w laboratorium. Przeglądasz każde znalezisko przed zmianą linii i uruchamiasz test na celu ponownie po zakończeniu.