PowerDbg Version 6

With this release we're really focusing on making PowerDbg (and by extension WinDbg) as easy to use as possible, whilst at the same time enabling a much richer debugging experience that really leverages the power of PowerShell.


Grab the release from Downloads, or grab a 'bleeding edge' build from source control under .\dev\out\Modules

New Features

  • Wherever possible we now returned structured (PSObject) data from commands, that can be filtered, pilelined etc... The CSV file is depricated. The raw output from a command can always be retrieved with the -raw switch.
  • Cmdlet aliases to reflect the WinDbg experience as closely as possible
  • Both 32 and 64 bit support for implemented cmdlets (nb: WOW64 not supported this release)
  • Bundled sample debugging scenarios, that can be built and used for training purposes (these actually form the basis of our integration tests)
  • PowerDbgConsole - provides a really easy way to get a PowerDbg session up and running against a process or an existing memory dump. Optional whether WinDbg UI is shown (remote mode) or whether whole session runs against (hidden) CDB process.
  • (TODO) Caching when debugging against a dump, so re-executing the same command is much faster.

We've also now got a 'build' process that makes it easier for us to develop new commands, but that's more a housekeeping thing.

Backwards Compatibility

It's the intent that all existing v5 scripts should still run as-is. This will need testing however...

CmdLet Naming

After a bit of tooing and fro-ing over this we are going to genuinely PowerShell-ize the cmdlet names (so !dumpobject = Get-DbgObject, !threads = Get-DbgClrThreads). As much as anything there is considerable advantage in being able to type 'help *Dgb' and see all the cmdlets that we've exposed.
The cmdlet names will still reflect (as much as possible) the underlying SOS / PSSCOR2 command names, in many cases just with the 'dump' prefix stripped off.

Internal functions (not exposed on the module interface) will tend to reflect more the name of the WinDBG command / extension that they are operating with. For example Get-DbgObject uses a function called Parse-DumpObject, Get-DbgArray uses Parse-DumpArray


(get-command -module WinDbg)

Anything without a hyperlink is proposed and has not been implemented. This list may change, and reflects us doing our laundry in public.

Basic commands

These map 1:1 with an underlying WinDbg / SOS command, and will typically have an alias that matches the original WinDbg command.

CmdLet SOS command
Get-DbgArray !dumparray
Get-DbgClrHeap !dumpheap
Get-DbgClrThreads !clrthreads
Get-DbgComState !comstate
Get-DbgModules lm k
Get-DbgObject !dumpobject
Get-DbgValueClass !dumpvc
Get-DbgRunaway !runaway
Get-DbgStackObjects !dumpstackobjects
Get-DbgSyncBlocks !synkblk
Get-DbgMethodDesc !dumpmd
Get-DbgMethodTable !dumpmt
Get-DbgException !printexception
Get-DbgObjectSize !objsize

Composite Commands

These combine multiple debugger commands to save time and facilitate analysis.

CmdLet Description
Get-DbgDictionaryContents was Dump-Dictionary Gets the objects contained in a managed dictionary, by traversing the backing array
Get-DbgListContents Gets the objects contained in a managed List<T>, by traversing the backing array
* Get-DbgThreadAnalysis Provides more detail on thread activity, including CPU time, locks held, COM apartment model and current state

Last edited Nov 15, 2010 at 1:59 PM by piers7, version 20


No comments yet.