2.9.26
Wydano 2 lis 2026
Oficjalna strona StatusRivet
Windows debugging od logu awarii do zatwierdzonego diffa
StatusRivet 2.9.26 to agent AI dla Windows 10/11, który uruchamia polecenia kompilacji i testów, czyta logi awarii i stosy wywołań oraz proponuje każdą poprawkę jako diff, który akceptujesz lub odrzucasz.
Przeczytaj stos wywołań w stack.txt, zidentyfikuj wyjątek i zaproponuj poprawkę.
- Shell
your debugger on app.dmp > stack.txtexit 0 - read_file
stack.txtread - grep
0xC0000005 stack.txt1 match - edit_file
src/parser.cpp+3 - Shell
your build commandexit 0 - Shell
your test commandexit 0
oczekiwanie na Twoją zgodę przed wykonaniem kolejnego krokuOdrzućAkceptuj
34 MB
Przycisk pobierania udostępnia ten instalator
25 MB
Dostępny jest również pojedynczy plik exe
13
Języki interfejsu aplikacji
Windows 10/11
64-bit (x64)
Brak
Nie jest wymagane konto do uruchomienia
Windows debugging z prawdziwymi narzędziami i diffem do weryfikacji
Windows debugging oznacza ustalenie, dlaczego program zachowuje się nieprawidłowo, poprzez jego zatrzymanie, odczyt stanu i przetestowanie poprawki. Buduj z symbolami. StatusRivet 2.9.26 uruchamia następnie polecenia kompilacji i testów, czyta tekstowe logi i stosy wywołań zapisywane przez debugger oraz pokazuje każdą proponowaną zmianę jako diff do Twojej akceptacji lub odrzucenia.
Napraw brakujące sprawdzenie null
Zadanie: aplikacja, którą napisałeś, ulega awarii z naruszeniem dostępu 0xC0000005, a podejrzewasz brakujące sprawdzenie null. Agent używa grep do znalezienia kodu wyjątku i nazwy funkcji w Twoim logu, a następnie read_file do otwarcia pliku źródłowego w tej funkcji. Proponuje naprawę za pomocą edit_file jako diff. Ask first zatrzymuje się przed tą edycją, więc czytasz 3 zmienione linie przed akceptacją. Shell uruchamia następnie polecenie kompilacji i polecenie testu, a karta pokazuje rzeczywisty kod wyjścia. Uruchom test ponownie.
Śledzenie narzędzi
grep 0xC0000005 crash.log → 1 match
read_file src/parser.cpp → read
edit_file src/parser.cpp → +3
Shell your test command → exit 0Przekształć stos wywołań z Twojego debuggera Windows w poprawkę
Zadanie: masz zrzut awarii z własnej kompilacji testowej i potrzebujesz funkcji powodującej awarię. Shell uruchamia Twój debugger Windows w trybie wiersza poleceń na zrzucie i zapisuje stos wywołań wątku powodującego awarię do pliku tekstowego, a następnie read_file ładuje ten tekst, a agent dopasowuje pierwsze 3 ramy do linii źródłowych. Symbole mają znaczenie. Przy dopasowanym PDB stos pokazuje nazwy funkcji, pliki źródłowe i numery linii, podczas gdy bez niego widzisz tylko adresy. Agent proponuje minimalny diff, a Ty przeglądasz go w trybie Ask first przed jakąkolwiek zmianą.
Śledzenie narzędzi
Shell your debugger on app.dmp > stack.txt → exit 0
read_file stack.txt → read
grep ParseHeader → 2 matchesPrzygotuj awarię sterownika na maszynie laboratoryjnej
Zadanie: sterownik, który napisałeś, powoduje awarię maszyny testowej i chcesz zidentyfikować moduł powodujący awarię. Konfiguracja debuggera jądra wymaga 2 maszyn lub maszyny wirtualnej, jednej uruchamiającej debugger i jednej jako celu testowego, połączonych połączeniem debugowania. Trzymaj to w laboratorium. Nigdy nie używaj swojego codziennego PC jako celu. 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 Twojego źródła. Ustawienia połączenia zmieniają cel, więc zapisz stare wartości i włącz Ask first podczas pracy.
Znajdź moduł stojący za kodem stopu
Zadanie: maszyna testowa pokazuje kod stopu i potrzebujesz modułu stojącego za nim. Uruchom debugger na minizrzucie lub własnym logu, a następnie pozwól grep wyszukać w zapisanym tekście kodu wyjątku i nazwy modułu, a read_file pokaże linie wokół każdego dopasowania. Kiedy wątek na forum pyta o pomoc z dumpami bsod, typową luką są brakujące symbole, więc dopasuj odpowiedni PDB do kompilacji przed odczytaniem jakiejkolwiek ramy. Sprawdź te 2 wyniki samodzielnie. Agent raportuje, co znalazł, a Ty decydujesz, którą wskazówkę podążyć.
Jak StatusRivet różni się od typowego asystenta czatu
Twoje narzędzia do debugowania Windows zachowują krok. StatusRivet 2.9.26 czyta ich wyjście tekstowe, uruchamia polecenia kompilacji i testów oraz pokazuje rzeczywisty wynik każdej akcji. Krok pozostaje Twój.
| Typowy asystent czatu | StatusRivet | |
|---|---|---|
| Akcja | Opisuje polecenie, które mógłbyś uruchomić | Uruchamia polecenie i pokazuje jego wyjście |
| Wynik | Pisze podsumowanie tego, co może się zdarzyć | Pokazuje rzeczywisty kod wyjścia, plik lub diff |
| Kontrola | Kopiujesz, wklejasz i uruchamiasz każdy krok samodzielnie | Ask first zatrzymuje się przed akcjami zmieniającymi coś |
| Pliki | Pracuje na tekście wklejonym do czatu | Czyta i edytuje pliki w folderze roboczym |
Jak zacząć w czterech krokach
- Pobierz program instalacyjny, około 34 MB, i uruchom go na Windows 10 lub 11.
- Porównaj sumę kontrolną SHA-256 instalatora z opublikowanym manifestem, ponieważ instalator nie jest jeszcze podpisany kodowo.
- Wybierz model: punkt końcowy dostawcy AI w chmurze, model na Twoim PC lub wbudowany model.
- Wybierz folder projektu, przełącz się na Ask first i opisz awarię, którą chcesz zbadać.
Kto z tego korzysta i kiedy
Programiści aplikacji są na pierwszym miejscu: napisałeś program, ulega awarii na maszynie testowej, a log ma setki linii. StatusRivet czyta ten log, znajduje kod wyjątku i tworzy wstępny diff, więc Twoja uwaga koncentruje się na 1 pytaniu, które ma znaczenie, czyli czy zmiana jest poprawna. Przeczytaj diff.
Twórcy sterowników otrzymują ten sam loop na maszynie laboratoryjnej. Kod stopu czytający kmode exception not handled w netio.sys oznacza, że sterownik trybu jądra zgłosił wyjątek, który nic nie obsłużył, a stos wywołań wątku powodującego awarię wskazuje funkcję. Tylko maszyny laboratoryjne.
Testerzy i inżynierowie wsparcia, którzy otrzymują awarię od kolegi z kompilacji, mogą poprosić o stos wywołań i najbliższą linię źródłową. Zrzut z 1 kompilacji wymaga PDB z tej samej kompilacji. Trzymaj oba pliki razem.
Najczęściej zadawane pytania
Czym jest windows debugging?
Windows debugging to ustalenie, dlaczego program zachowuje się nieprawidłowo w systemie Windows poprzez jego zatrzymanie, przyjrzenie się jego stanowi i przetestowanie poprawki. Istnieją 2 rodzaje: debugowanie trybu użytkownika aplikacji i debugowanie trybu jądra sterowników i systemu. Debugger pokazuje punkty przerwania, stos wywołań, rejestry i zmienne. Oba polegają na symbolach PDB. StatusRivet czyta wyjście tekstowe i tworzy wstępną poprawkę.
Czy windowsdebugging.com to oficjalna strona StatusRivet?
Tak, windowsdebugging.com to oficjalna strona StatusRivet. Przycisk pobierania udostępnia oryginalny program instalacyjny, a przed jego uruchomieniem możesz porównać jego sumę kontrolną SHA-256 z opublikowanym manifestem. Zweryfikuj przed uruchomieniem. Jeśli coś wygląda nie tak, użyj przycisku Send feedback wewnątrz aplikacji, aby nas poinformować.
Czy StatusRivet zastępuje mój debugger?
Nie. StatusRivet pracuje na tekście: uruchamia tryb wiersza poleceń Twojego debuggera, polecenie kompilacji i polecenie testu, a następnie czyta wyjście i tworzy wstępny diff. Do interaktywnego krokowania, punktów przerwania i rejestrów kontynuuj używanie własnego debuggera i przekaż wyjście agentowi. Oba narzędzia pozostają przydatne.
Jak badać pliki .dmp po awarii?
Plik .dmp to zrzut awarii, który przechowuje stan programu w momencie jego niepowodzenia. Aby go zbadać, uruchom tryb wiersza poleceń swojego debuggera na nim, zapisz stos wywołań wątku powodującego awarię do pliku tekstowego i poproś StatusRivet o odczyt tego pliku za pomocą read_file oraz wyszukanie go za pomocą grep. Zachowaj odpowiedni PDB.
Co oznacza "windows dbg"?
Windows dbg to skrót wyszukiwania dla debuggera uruchamianego w systemie Windows. Nie jest to nazwa produktu tutaj. StatusRivet nie dostarcza debuggera. Uruchamia ten, który już posiadasz w trybie wiersza poleceń i pracuje na tekście, który ten debugger zapisuje, więc zachowaj własny debugger zainstalowany.
Czy wyniki są zawsze poprawne?
Nie. StatusRivet pokazuje rzeczywiste wyjście każdej akcji, ale nie może zagwarantować, że diagnoza, diff lub poprawka są poprawne. Log z brakującymi symbolami lub brakującymi liniami prowadzi do słabszych odpowiedzi. Czytasz każdy diff, kompilujesz ponownie i uruchamiasz polecenie testu ponownie przed zachowaniem zmiany. Przetestuj najpierw.
Czy moje pliki opuszczają komputer?
Odpowiedź zależy od wybranego modelu. Przy dostawcy AI w chmurze prompt, w tym tekst dowolnego pliku odczytanego przez agenta dla tego kroku, idzie do tego dostawcy. Przy modelu uruchamianym na Twoim PC nic nie opuszcza maszyny. Klucze pozostają lokalne. Sekrety w wyjściu narzędzi są maskowane przed dotarciem do modelu.
Rozpocznij debugowanie własnego oprogramowania
Pobierz StatusRivet 2.9.26, program instalacyjny o wielkości około 34 MB dla Windows 10/11, i wskaż mu projekt, którym posiadasz. Zacznij od Plan only. Następnie przeglądaj każdy diff proponowany przez agenta.
Pobierz StatusRivet dla Windows ↗Więcej o StatusRivet
Każda strona tej witryny jest dostępna w 20 językach, podczas gdy interfejs aplikacji ma 13.
Funkcje produktu i tryby zatwierdzania ↗ Połącz model w chmurze, lokalny lub wbudowany ↗ Zdalny przepływ pracy debugowania dla maszyn laboratoryjnych ↗ Pobierz i zweryfikuj program instalacyjny ↗ Pytania o awarie, zrzuty i prywatność ↗ Co rejestruje witryna i aplikacja ↗
