2.9.26
Released 2 Nov 2026
StatusRivet 2.9.26 is an AI agent for Windows 10/11 that runs your build and test commands, reads crash logs and call stacks, and proposes each fix as a diff you accept or reject.
your debugger on app.dmp > stack.txtexit 0stack.txtread0xC0000005 stack.txt1 matchsrc/parser.cpp+3your build commandexit 0your test commandexit 0Released 2 Nov 2026
The download button gives this installer
A single exe also exists
App interface languages
64-bit (x64)
No account needed to run
Windows debugging means finding out why a program misbehaves by stopping it, reading its state and testing a fix. Build with symbols. StatusRivet 2.9.26 then runs your build and test commands, reads the text logs and call stacks that your debugger writes, and shows every proposed change as a diff for you to accept or reject.
Task: an app you wrote crashes with an access violation, 0xC0000005, and you suspect a missing null check. The agent uses grep to find the exception code and the function name in your log, then read_file to open the source file at that function. It proposes the repair with edit_file as a diff. Ask first pauses before that edit, so you read the 3 changed lines before accepting. Shell then runs your build command and your test command, and the card shows the real exit code. Run the test again.
grep 0xC0000005 crash.log → 1 match
read_file src/parser.cpp → read
edit_file src/parser.cpp → +3
Shell your test command → exit 0Task: you have a crash dump from your own test build and need the faulting function. Shell runs your win debugger in its command-line mode on the dump and saves the call stack of the faulting thread to a text file, then read_file loads that text and the agent matches the first 3 frames to source lines. Symbols matter. With the matching PDB the stack shows function names, source files and line numbers, while without it you see addresses only. The agent proposes a minimal diff, and you review it in Ask first mode before anything changes.
Shell your debugger on app.dmp > stack.txt → exit 0
read_file stack.txt → read
grep ParseHeader → 2 matchesTask: a driver you wrote crashes a test machine and you want the faulting module. A kernel debugging windows setup needs 2 machines or a virtual machine, one running the debugger and one as the test target, linked by a debug connection. Keep it in a lab. Never use your daily PC as the target. Shell runs commands over SSH on a lab machine you own, read_file reads the text your debugger saved, and grep matches the module name against your source. Connection settings change the target, so write down the old values and keep Ask first on while you work.
Task: a test machine shows a stop code and you need the module behind it. Run your debugger on the minidump or your own log, then let grep search the saved text for the exception code and the module name, and read_file shows the lines around each match. When a forum thread asks for bsod dumps help, the usual gap is missing symbols, so match the right PDB to the build before you read any frame. Check the 2 results yourself. The agent reports what it found, and you decide which finding to follow.
Your debugging tools for Windows keep the stepping. StatusRivet 2.9.26 reads their text output, runs your build and test commands, and shows the real result of each action. Stepping stays yours.
| Typical chat assistant | StatusRivet | |
|---|---|---|
| Action | Describes the command you could run | Runs the command and shows its output |
| Result | Writes a summary of what might happen | Shows the real exit code, file or diff |
| Control | You copy, paste and run each step yourself | Ask first pauses before actions that change something |
| Files | Works from text you paste into the chat | Reads and edits files in the working folder |
Application developers come first: you wrote the program, it crashes on a test machine, and the log runs to hundreds of lines. StatusRivet reads that log, finds the exception code and drafts a diff, so your attention goes to the 1 question that matters, which is whether the change is right. Read the diff.
Driver writers get the same loop on a lab target. A stop code that reads kmode exception not handled in netio.sys means a kernel-mode driver raised an exception that nothing handled, and the call stack of the faulting thread names the function. Lab machines only.
Testers and support engineers who receive a crash from a colleague's build can ask for the call stack and the nearest source line. A dump from 1 build needs the PDB from that same build. Keep both files together.
Windows debugging is finding out why a program misbehaves on Windows by stopping it, looking at its state and testing a fix. There are 2 kinds: user-mode debugging of applications and kernel-mode debugging of drivers and the system. A debugger shows breakpoints, the call stack, registers and variables. Both rely on PDB symbols. StatusRivet reads the text output and drafts the fix.
Yes, windowsdebugging.com is the official StatusRivet website. The download button gives the original setup program, and you can compare its SHA-256 checksum with the published manifest before you run it. Verify before running. If anything looks wrong, use the Send feedback button inside the app to tell us.
No. StatusRivet works from text: it runs your debugger's command-line mode, your build command and your test command, then reads the output and drafts a diff. For interactive stepping, breakpoints and registers, keep using your own debugger and hand the output to the agent. Both tools stay useful.
A .dmp file is a crash dump that stores the state of a program when it failed. To examine one, run your debugger's command-line mode on it, save the call stack of the faulting thread to a text file, and ask StatusRivet to read that file with read_file and search it with grep. Keep the matching PDB.
Windows dbg is a search shorthand for a debugger that runs on Windows. It is not a product name here. StatusRivet ships no debugger. It runs the one you already own in its command-line mode and works from the text that debugger writes, so keep your own debugger installed.
No. StatusRivet shows the real output of every action, but it cannot promise that a diagnosis, a diff or a fix is correct. A log with missing symbols or missing lines leads to weaker answers. You read every diff, rebuild, and run your test command again before you keep a change. Test first.
The answer depends on the model you pick. With a cloud AI provider, the prompt, including the text of any file the agent reads for that step, goes to that provider. With a model running on your PC, nothing leaves the machine. Keys stay local. Secrets in tool output are redacted before they reach the model.
Download StatusRivet 2.9.26, a setup program of about 34 MB for Windows 10/11, and point it at a project you own. Start with Plan only. Then review each diff the agent proposes.
Download StatusRivet for Windows ↗Every page of this website is available in 20 languages, while the app interface itself has 13.
Product features and approval modes ↗ Connect a cloud, local or built-in model ↗ Remote debugging workflow for lab machines ↗ Download and verify the setup program ↗ Questions about crashes, dumps and privacy ↗ What the website and the app record ↗