2.9.26
Rilasciato il 2 nov 2026
Sito ufficiale StatusRivet
Windows debugging: dal log di crash al diff revisionato
StatusRivet 2.9.26 è un agente AI per Windows 10/11 che esegue i comandi di build e test, legge i log di crash e gli stack di chiamate, e propone ogni fix come un diff che puoi accettare o rifiutare.
Leggi lo stack di chiamate in stack.txt, trova l'eccezione e proponi una correzione.
- 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
in attesa della tua approvazione prima del passaggio successivoRifiutaAccetta
34 MB
Il pulsante di download fornisce questo installer
25 MB
Esiste anche un singolo exe
13
Lingue dell'interfaccia dell'app
Windows 10/11
64-bit (x64)
Nessuno
Non serve un account per eseguire
Windows debugging con strumenti reali e un diff revisionabile
Windows debugging significa scoprire perché un programma si comporta male interrompendolo, leggendo il suo stato e testando una correzione. Compila con i simboli. StatusRivet 2.9.26 esegue poi i comandi di build e test, legge i log testuali e gli stack di chiamate che il tuo debugger scrive, e mostra ogni modifica proposta come un diff da accettare o rifiutare.
Correggi un controllo null mancante
Attività: un'app che hai scritto crasha con una violazione di accesso, 0xC0000005, e sospetti un controllo null mancante. L'agente usa grep per trovare il codice di eccezione e il nome della funzione nel tuo log, poi read_file per aprire il file di origine in quella funzione. Propone la riparazione con edit_file come diff. Ask first fa una pausa prima di quella modifica, così leggi le 3 righe modificate prima di accettare. Shell esegue poi il comando di build e il comando di test, e la scheda mostra il codice di uscita reale. Esegui di nuovo il test.
Traccia dello strumento
grep 0xC0000005 crash.log → 1 match
read_file src/parser.cpp → read
edit_file src/parser.cpp → +3
Shell your test command → exit 0Trasforma uno stack di chiamate dal tuo debugger win in una correzione
Attività: hai un dump di crash dal tuo build di test e hai bisogno della funzione che causa il fault. Shell esegue il tuo debugger win in modalità riga di comando sul dump e salva lo stack di chiamate del thread in fault su un file di testo, poi read_file carica quel testo e l'agente fa corrispondere i primi 3 frame alle righe di origine. I simboli sono importanti. Con il PDB corrispondente lo stack mostra nomi di funzioni, file di origine e numeri di riga, mentre senza di esso vedi solo gli indirizzi. L'agente propone un diff minimo e tu lo revisioni in modalità Ask first prima che cambi qualcosa.
Traccia dello strumento
Shell your debugger on app.dmp > stack.txt → exit 0
read_file stack.txt → read
grep ParseHeader → 2 matchesPrepara un crash del driver su un target di laboratorio
Attività: un driver che hai scritto fa crashare una macchina di test e vuoi trovare il modulo responsabile. Una configurazione di debugging del kernel richiede 2 macchine o una macchina virtuale, una che esegue il debugger e una come target di test, collegate da una connessione di debug. Tienilo in un lab. Non usare mai il tuo PC quotidiano come target. Shell esegue comandi via SSH su una macchina di laboratorio di tua proprietà, read_file legge il testo che il tuo debugger ha salvato, e grep fa corrispondere il nome del modulo con la tua origine. Le impostazioni di connessione cambiano il target, quindi annota i vecchi valori e mantieni Ask first attivo mentre lavori.
Trova il modulo dietro un codice di stop
Attività: una macchina di test mostra un codice di stop e hai bisogno del modulo dietro di esso. Esegui il tuo debugger sul minidump o sul tuo log, poi lascia che grep cerchi nel testo salvato per il codice di eccezione e il nome del modulo, e read_file mostra le righe intorno a ogni corrispondenza. Quando una discussione su un forum chiede aiuto per i dump bsod, il solito gap è la mancanza di simboli, quindi fai corrispondere il PDB giusto al build prima di leggere qualsiasi frame. Controlla tu stesso i 2 risultati. L'agente segnala cosa ha trovato e tu decidi quale scoperta seguire.
Come StatusRivet differisce da un assistente chat tipico
I tuoi strumenti di debugging per Windows mantengono il controllo. StatusRivet 2.9.26 legge il loro output testuale, esegue i comandi di build e test e mostra il risultato reale di ogni azione. Il controllo resta tuo.
| Assistente chat tipico | StatusRivet | |
|---|---|---|
| Azione | Descrive il comando che potresti eseguire | Esegue il comando e mostra il suo output |
| Risultato | Scrive un riassunto di ciò che potrebbe accadere | Mostra il codice di uscita reale, il file o il diff |
| Controllo | Copi, incolli ed esegui ogni passaggio tu stesso | Ask first fa una pausa prima delle azioni che modificano qualcosa |
| File | Lavora dal testo che incolli nella chat | Legge e modifica i file nella cartella di lavoro |
Come iniziare in quattro passaggi
- Scarica il programma di installazione, di circa 34 MB, ed eseguilo su Windows 10 o 11.
- Confronta il checksum SHA-256 dell'installer con il manifesto pubblicato, perché l'installer non è ancora firmato digitalmente.
- Scegli un modello: un endpoint di un provider AI cloud, un modello sul tuo PC o il modello integrato.
- Scegli la cartella del progetto, passa a Ask first e descrivi il crash che vuoi indagare.
Chi lo usa e quando
Gli sviluppatori di applicazioni vengono prima: hai scritto il programma, crasha su una macchina di test e il log si estende per centinaia di righe. StatusRivet legge quel log, trova il codice di eccezione e abbozza un diff, così la tua attenzione va all'unica domanda che conta, ovvero se la modifica è corretta. Leggi il diff.
Gli sviluppatori di driver ottengono lo stesso loop su un target di laboratorio. Un codice di stop che legge kmode exception not handled in netio.sys significa che un driver in modalità kernel ha generato un'eccezione che nulla ha gestito, e lo stack di chiamate del thread in fault nomina la funzione. Solo macchine di laboratorio.
Tester e ingegneri di supporto che ricevono un crash da un build di un collega possono chiedere lo stack di chiamate e la riga di origine più vicina. Un dump da 1 build richiede il PDB da quello stesso build. Tieni entrambi i file insieme.
Domande frequenti
Cos'è windows debugging?
Windows debugging è scoprire perché un programma si comporta male su Windows interrompendolo, esaminando il suo stato e testando una correzione. Ci sono 2 tipi: debugging in modalità utente delle applicazioni e debugging in modalità kernel dei driver e del sistema. Un debugger mostra breakpoint, lo stack di chiamate, i registri e le variabili. Entrambi si basano sui simboli PDB. StatusRivet legge l'output testuale e abbozza la correzione.
windowsdebugging.com è il sito ufficiale di StatusRivet?
Sì, windowsdebugging.com è il sito ufficiale di StatusRivet. Il pulsante di download fornisce il programma di installazione originale e puoi confrontare il suo checksum SHA-256 con il manifesto pubblicato prima di eseguirlo. Verifica prima di eseguire. Se qualcosa sembra sbagliato, usa il pulsante Send feedback all'interno dell'app per comunicarlo a noi.
StatusRivet sostituisce il mio debugger?
No. StatusRivet lavora dal testo: esegue la modalità riga di comando del tuo debugger, il comando di build e il comando di test, poi legge l'output e abbozza un diff. Per il controllo interattivo, i breakpoint e i registri, continua a usare il tuo debugger e consegna l'output all'agente. Entrambi gli strumenti rimangono utili.
Come esamino i file .dmp dopo un crash?
Un file .dmp è un dump di crash che memorizza lo stato di un programma quando è fallito. Per esaminarlo, esegui la modalità riga di comando del tuo debugger su di esso, salva lo stack di chiamate del thread in fault su un file di testo e chiedi a StatusRivet di leggere quel file con read_file e cercarlo con grep. Tieni il PDB corrispondente.
Cosa significa "windows dbg"?
Windows dbg è una scorciatoia di ricerca per un debugger che gira su Windows. Non è un nome di prodotto qui. StatusRivet non fornisce un debugger. Esegue quello che già possiedi in modalità riga di comando e lavora dal testo che quel debugger scrive, quindi mantieni il tuo debugger installato.
I risultati sono sempre corretti?
No. StatusRivet mostra l'output reale di ogni azione, ma non può promettere che una diagnosi, un diff o una correzione siano corretti. Un log con simboli mancanti o righe mancanti porta a risposte più deboli. Leggi ogni diff, ricompila ed esegui di nuovo il tuo comando di test prima di mantenere una modifica. Testa prima.
I miei file lasciano il PC?
La risposta dipende dal modello che scegli. Con un provider AI cloud, il prompt, incluso il testo di qualsiasi file che l'agente legge per quello step, va a quel provider. Con un modello in esecuzione sul tuo PC, nulla lascia la macchina. Le chiavi restano locali. I segreti nell'output degli strumenti vengono oscurati prima di raggiungere il modello.
Inizia a fare debugging del tuo software
Scarica StatusRivet 2.9.26, un programma di installazione di circa 34 MB per Windows 10/11, e puntalo su un progetto di tua proprietà. Inizia con Plan only. Poi rivedi ogni diff che l'agente propone.
Scarica StatusRivet per Windows ↗Altro su StatusRivet
Ogni pagina di questo sito web è disponibile in 20 lingue, mentre l'interfaccia dell'app ha 13 lingue.
Funzionalità del prodotto e modalità di approvazione ↗ Connetti un modello cloud, locale o integrato ↗ Flusso di lavoro di debugging remoto per macchine di laboratorio ↗ Scarica e verifica il programma di installazione ↗ Domande su crash, dump e privacy ↗ Cosa registrano il sito web e l'app ↗
