Oct 24, 2010 at 4:03 PM
Edited Oct 24, 2010 at 4:14 PM
Interesting idea actually. But sending the CTRL-Break / CTRL-C isn't the problem - being in a position to send it is .
(I'm principally talking about v6 here - but I think this mostly applies to v5 as well)
Say you attach PowerDbg v6 to the debugger, and execute the Send-DbgGo command. PowerDbg sends the command, and - like it does for all commands - starts streaming back the debugger output *until it gets to the next command prompt*. Which may never happen
of course, because your program may not throw or hit an assigned breakpoint.
So you hit CTRL-C and PowerShell aborts the current command. At this point you'd expect to be able to use something like this:
...to send CTRL-C to the debugger, and hit the next command prompt (this is the undocumented Send-DbgBreak cmdlet in v6). But wierdly what happens is that when you
originally hit CTRL-C, that somehow got sent to the attached debugger, so its
already sat at the command prompt, just PowerDbg doesn't know (because the CTRL-C also stopped the execution of the current function - Send-DbgGo). If this seems odd to you, you are not alone.
Now potentially the problem here is that Send-DbgGo is implemented like all the other commands: it's essentially request/response, and won't come back until it's good and ready. Maybe Send-DbgGo should send a 'g'
and return to the prompt. You could then use Send-DbgBreak at your leasure to stop the debugger, and all would (probably) be well. We'd have to prevent you using any other commands during this period, but that's manageable.
What's a bit less great is that because we've returned from the command, we're no longer in a position to stream debugger output to the console - PowerShell
is going to own the prompt until the user enters another command, and even if it was possible to write to the console 'from the background' as it were, it would be really disconcerting for the user, so I don't think that's a great direction.
Do we need this debugger output? I don't know - I guess it depends what you're doing.
Could we give the user the choice: Send-DbgGo vs
Send-DbgGo -nowait for example. Maybe. Is it too confusing? I don't know.
I guess the bottom line is that the interactive debugging experience isn't our top focus for this release, so some questions like this may have to wait for v6.5 to be answered (and would presumably go hand in hand with providing good cmdlet wrappers
for setting breakpoints and suchlike). I spent an evening looking at it, and it was unfortunately apparent it wasn't going to 'just work' as-is.
In the meantime, with both v5 and v6 probably the best workaround would be to run everything in attached/UI mode (attach PowerDbg to a WinDbg process in server mode (the v5 model), rather than attach PowerDbg 'directly' to the dump / process like you can
in v6) then you can always hit CTRL-Break in the WinDbg window to force a breakpoint in a way that PowerDbg will halt at.
Hope this helps.
 unless you run your DebugBreakProcess from another window / process, in which case PowerDbg not accepting input doesn't really bother you. But it's still hardly ideal that you'd have to do that at all.