powerdbg Forum Rss Feed

New Post: Support for windows 8 and WDK in PowerDbg

manukahn — Wed, 10 Oct 2012 11:44:07 GMT

In windows 8 debugging tools for windows comes in a new form called WDK.

The home directory of the good old tools is now : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64 (for the 64 bit version) and C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86 (for the 32 bit version)Unfortunately the PowerDbg module does not know that.

When loading the module it looks for the home directory of "debugging tools for windows" and put it in a global variable. ($debuggerRoot)

We have to change the module file and add the correct directories.

So open the module file (PowerDbg.psm1) and change the function Get-DbgToolsLocation (line 428) so serach path will include the correct folders:

$searchPaths = "$env:programfiles\Debugging Tools for Windows (x64)",
"$env:programfiles\Debugging Tools for Windows (x86)",
"$env:programfiles (x86)\Windows Kits\8.0\Debuggers\x64", #windows 8
"$env:programfiles (x86)\Windows Kits\8.0\Debuggers\x86", #windows 8
"C:\debuggers" # for Microsoft internal installs

As we can see from the code PowerDbg works with only one version at a time. (The first folder in the list)
To switch between x64 and x86 we have to change the order of the folder in the list. I think that a parameter should control that. (TBD)

Manu

New Post: CDB process exited with the error code -1073741502

kbninja13 — Fri, 08 Jun 2012 17:51:01 GMT

Hello Everyone,

first post and am a bit of a noob with powerdbg (but am seriously loving it, i have used windbg for years so automating debugging is pretty fun).

I am seeing some inconsistent behaviour when i am using powerdbg. when i open a powershell console, periodically when i attempt to execute my powerdbg scripts i get the following error returned:

CDB process exited with error code -1073741502
At C:\Users\sbanks\Documents\WindowsPowerShell\Modules\PowerDbg\PowerDbg.psm1:144 char:14
+         throw <<<< "CDB process exited with error code $($SCRIPT:windbgProcess.ExitCode)"
    + CategoryInfo          : OperationStopped: (CDB process exi...ode -1073741502:String) [], RuntimeException
    + FullyQualifiedErrorId : CDB process exited with error code -1073741502

sometimes if i rerun the script it works, but more often than not i need to launch a new powershell in order to run my script.

Is there something i am not doing that is causing this error? or if anyone has encountered this what have they done to work around it? i am considering maybe putting in some conditional logic to launch a new powershell when this occurs but before i do that just wanted to see if others have this issue

New Post: Send-PowerDbgCTRL-BREAK

rogerb — Fri, 23 Sep 2011 19:03:43 GMT

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

New Post: Send-PowerDbgCTRL-BREAK

piers7 — Sun, 24 Oct 2010 15:03:53 GMT

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.

New Post: Send-PowerDbgCTRL-BREAK

DonovanS — Sun, 17 Oct 2010 18:09:19 GMT

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

New Post: Send-PowerDbgCTRL-BREAK

piers7 — Sun, 17 Oct 2010 17:28:29 GMT

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.

New Post: Send-PowerDbgCTRL-BREAK

DonovanS — Wed, 15 Sep 2010 07:34:40 GMT

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.

New Post: Suggest Features for vNext

piers7 — Thu, 22 Apr 2010 13:55:13 GMT

Roberto has very kindly asked me to help out on the project, and together we are planning a v6 release of PowerDBG.

Our main focus with this release is going to be making PowerDBG (and by extension WinDBG) really easy to use. We're going to try provide a much more 'PowerShell'y experience, and really play to the strengths of PowerShell as a host.

At the same time, we're just two guys, and we know next-to-nothing about what you need. So please tell us. If there are things you don't like, or scenarios where getting an answer out of WinDBG is particularly laborious (and believe me, I feel your pain), shout it out. We want to know.

Put your suggestions for the next release as Proposed / Feature issues in the issue tracker.