Are there plans to bring Send-PowerDbgCTRL-BREAK back or add equivalent functionality in v6?  I have a couple of scenarios where it would come in handy.  Thanks.

Not yet, but I bumped into a couple myself last week, so I hear you.

There's actually something wierd going on, because when in a PowerDbg session if you send CTRL-break the debugger is getting that (as well as PowerShell aborting the current command). So we kinda get it for free (if we can rely on that). However PowerDbg gets really confused afterwards because it doesn't know what happened, and its buffers are all wrong.

We are unfortunately victim here to the mis-match between the request/response nature of a command shell and the fully interactive nature of the debugger in 'run' mode, so the syntax may end up being a bit odd.

I've created a feature request for this, for tracking.

While experimenting for a workaround, I added a hack to call DebugBreakProcess for the debugee.  So far its worked out quite well.

Interesting idea actually. But sending the CTRL-Break / CTRL-C isn't the problem - being in a position to send it is [1].

(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:

Invoke-DbgCommand "\x3"

...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.

[1] 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.

Hi Piers,

I don't think that you truly appreciate the need to enable the Ctrl-Break/Ctrl-C functionality. I'm working on a project that will use the PowerDbg module to enable me to write a tool that will monitor a system while a functional test is running, and if the system hangs; to force the debugger to break into the malfunctioning system, force dumpfile to be created, and then to reboot the system. In this case, having the entire test run and not break into the debugger would be a good thing. This use case requires the ability to start and stop the debugger programmatically from a tool. The use of the C-B/C-C functionality isn't just for interactive use. I think that it's very normal to think that a Send-DbgGo command would return without waiting for a response, and to then expect that a Send-DbgBreak would stop the debugger that has been running in an open-loop fashion. This functionality is important enough to me that I'll add the functionality myself. If you would like to look at the results and roll them into the released version, then so much the better. I would rather have the capability rolled up into the release, that way I don't have to patch every new release to add my changes.

Regards,

Roger