A remote windows debugger session attaches a debugger on one machine to a program on another over a network, and it belongs between your own lab machines only. Symbols come first. Name one machine the host and one the target. Build the program with debug symbols and keep the matching PDB for that exact build, because a mismatched PDB gives wrong function names and a stack without symbols shows addresses only. Install StatusRivet on the host, where you work, and keep the target to the program under test and nothing else. Write down any setting you change on either machine so you can restore it afterwards. Reproduce the crash with the smallest input you can find, because a short case produces a short stack and an easier diff. Check that the host and the target can reach each other before you ask the agent to do anything, since a failed connection looks like a failed debugger.
Choose the folder with your source and build files as the chat's working folder, because the file tools read and edit only inside it. Put the saved stack and notes there too, so the whole case sits in one place and the agent can read all of it.
Ask first pauses before actions that change something, so you can read each one before it runs. Use Plan only when you want to see the steps first and run nothing. A plan survives a restart, so you can come back to it later.
Name the program, the host and the target machine and the symptom, and say the machines are yours. Give the connection details from your own lab notes and do not guess any of them. Say which build is running on the target, and which PDB belongs to it.
Read the diff, rebuild with your build command and run your test command again on the target. Keep the notes of what changed with the checklist, and keep the old dump if the new test still fails, so the next attempt starts from evidence and not from memory.
attach your debugger to the targetattachedsave the dump on the targetsavedwrite the call stack to stack.txtsavedstack.txtread0xC0000005 stack.txt1 match# 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 changedA plain-text checklist for one debugging session between two lab machines. It covers building with symbols, attaching, reproducing the crash with the smallest input, saving a dump and a call stack, reading the top frames, and ends with a test run after the fix, with notes of what changed. Copy it into your project folder and edit it to match your own lab. Copy it and edit.
Task: attach from the host machine to your own program running on the lab target. Attach first. Open the project folder in StatusRivet, switch to Ask first and describe the setup. Shell runs your debugger's command-line mode with the connection details you give it, and the card shows whether it attached through the real exit code. The agent does not invent connection settings, so take the host, the target and the port from your own lab notes. Remote debugging is for your own lab machines only, never for a computer you do not own. Read the card before the next step. If the attach failed, nothing else should run, and you fix the connection first, then ask again. The card also keeps the exact command, so you can repeat it later.
Task: after you reproduce the crash on the target with the smallest input, save the evidence. Save both files. Shell asks your debugger to write a crash dump and to save the call stack of the faulting thread to a text file, and the cards show both results. A windows jit debugger entry on the target starts a debugger automatically when an application crashes. That is a system setting, so change it only on a test machine, write down the previous value and restore it afterwards. To find the cause of a system crash from a minidump, start from the saved call stack. You approve each step in Ask first mode, and you keep both files with the checklist for the next person who reads the case. Name the files after the build so nobody mixes them up.
Task: connect the top frame to your code. Start with symbols. read_file opens stack.txt, grep searches the project for the function name and for the exception code, such as 0xC0000005 for an access violation, and read_file opens the source file at that line. With the matching PDB the stack shows function names, source files and line numbers, while without it you see addresses only. A freezing machine that ends in a bsod with a kernel security check failure is a case for exactly this routine: dump, stack, source. Read the evidence yourself before the agent edits anything, because the agent works from text and cannot step through the program for you. For stepping, use your own debugger and tell the agent what you saw.
Task: turn the finding into a change. edit_file proposes a minimal diff, for example a missing null check or a bad index, and in Ask first mode the agent pauses so you can read the changed lines. Shell then runs your build command, with symbols, and your test command, and the cards report the real exit codes. A kernel mode heap corruption bsod in a driver you wrote can show up long after the bad write, so check the buffers written earlier in the stack, not only the last frame. An unexpected store exception bsod on your lab target is handled the same way. Accept the diff only after the test passes, and write down what changed. Test before accepting. If the test still fails, keep the new stack and start the loop again from the second step.
