Repository navigation
A command that fails keeps what the engine printed - #198
Merged
Merged
Conversation
`DbgEngError::CommandFailedWithOutput`, read through `DbgEngError::output()`. The five calls that capture output -- `execute_command`, `execute_command_bounded`, `execute_and_wait`, `settle` and `run_to_address` -- answer with it where they answered `CommandFailed`, when `Execute` refuses the text or the wait after it fails. The message is unchanged. The capture used to be dropped on that path, and the code alone says little: `0x80040205` is the answer to a mistyped command, to an argument naming nothing, to `g` on a dump and to `||1s` on a system not yet loaded. Measured (`examples/failed_command_output.rs`) on dbgeng 10.0.29617.1000 and 10.0.26100.1742, ARM64, alike: the engine's own line saying which is printed into this call's capture -- `Couldn't resolve error at 'ntdll!Nope'`, `^ No runnable debuggees error in 'g'`, `^ Illegal debuggee error in '||1s'` -- beside whatever earlier segments of the command printed. Some failures never take this road: `dt` of a missing type and an extension command that does not exist print their complaint and return success. `test_a_refused_command_keeps_what_the_engine_printed` drives the three paths a caller's text takes against a launched process; it passes on the inbox 10.0.26100.1 and fails at each path with that path's change backed out. The wait-failure half (`settle`, and the pump in `execute_and_wait` and `run_to_address`) has no test: a wait that fails with the target still present and no break raised is not something a test can arrange. Asked for by windbg-mcp `FOLLOWUPS.md` item 126. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H7Gnmok17PyEYbcc3aHUm5
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For windbg-mcp
FOLLOWUPS.mditem 126: whenExecutefails, this crate returns theHRESULTalone and drops the output it captured for the call.What changed
DbgEngError::CommandFailedWithOutput { source, output }, read throughDbgEngError::output(). The five calls that capture output now answer with it where they answeredCommandFailed. That happens whenExecuterefuses the text or the wait after it fails. The five areexecute_command,execute_command_bounded,execute_and_wait,settleandrun_to_address.CommandFailed's word for word. A caller that renders errors as text sees no change until it asks foroutput().CommandFailedstays. It still covers the failures that had no capture: setting the callbacks, a status read, and the pump inside an open. So branches already open against the old variant keep compiling.examples/failed_command_output.rsis the measurement record.Measured before it was written
The item's open question was whether the engine's reason reaches this call's capture at all.
cdbprinting the line shows the engine emits it, not that it lands in aDEBUG_OUTCTL_THIS_CLIENTcapture. It does land there.The readings were taken against a user-mode dump on ARM64, with dbgeng 10.0.29617.1000 and 10.0.26100.1742. Both builds answered byte for byte alike, and every failure below is
0x80040205:zzzzCouldn't resolve error at 'zzz'? ntdll!Nope,u ntdll!Nope,dd ntdll!NopeCouldn't resolve error at 'ntdll!Nope'.echo before the failure; zzzzbefore the failure, then the line aboveg(throughexecute_and_wait)^ No runnable debuggees error in 'g'||1s, after.opendumpof a second dump^ Illegal debuggee error in '||1s'Some failures never take this road. These print their complaint and return success:
dt ntdll!_NOPEprintsSymbol ntdll!_NOPE not found.!nosuchextensionprintsNo export nosuchextension found.dd 0 L4prints????????.x ntdll!Nopeandlm m nopeprint no match.The variant is for the failures that do return an error.
Tests
test_a_refused_command_keeps_what_the_engine_printeddrives.echo before the failure; ? nowhere!Nopethroughexecute_command,execute_command_boundedandexecute_and_waitagainst a launched process. For each path it asserts two things are in the capture: the earlier segment's output, and the engine'sCouldn't resolveline.settle, and the pump inexecute_and_waitandrun_to_address. It needs a wait that fails with the target still present and no break raised, which is not something a test can arrange.🤖 Generated with Claude Code
https://claude.ai/code/session_01H7Gnmok17PyEYbcc3aHUm5