New PowerDbg – I Need Your Help
First, let me fix the title. It should be: “New PowerDbg – We Need Your Help”.
I explain, a few weeks ago I received an e-mail from Piers Williams, a developer from Australia. Piers mentioned his blog article related to PowerDbg where he makes some constructive criticism.
When reading the article I was like: “Why haven’t I thought about that before?” Piers have some simple yet awesome ideas to make PowerDbg much easier to use. Right after reading the article I invited him to be my partner and implement his ideas.
So here are some of the planned features for the new version:
- No more PowerDbg for most of the cmdlets. Current cmdlets will have aliases. For example, Send-PowerDbgCommand can be called by Invoke-WinDbgCommand.
- No more CSV files. It means no more Convert-PowerDbgCSVToHashTable.
- No more Parse cmdlets. It means fewer commands to create scripts.
- Greater PowerShell experience.
- Compatible with previous version so your scripts should continue to run fine.
- More cmdlets compatible with 64 bits. Not all cmdlets are 64 bits compatible.
- Auto-detect location of Debugging Tools.
- Provide command outputs as pipeline objects.
- When debugging a dump, caches command output.
Here is a comparison between the way you use PowerDbg nowadays and how you’re going to use it for the next version.
Current version:
Send-PowerDbgCommand “!do 0x353433”
Parse-PowerDbgDUMPOBJECT
$output = Convert-PowerDbgCSVToHashTable
For the new version all you need to do is:
Dump-Object “0x353433”
There’ll be cmdlets like:
dd = Display-DWord
db = Display-Bytes
dps = Display-PointerSymbols
!DumpDomain = Dump-Domain
!DumpObj = Dump-Obj
!runaway = Run-Away
Because WinDbg has some cryptic command names not all commands are going to have a corresponding name.
We need to think about the best approach for:
~
~*
!address
. . .
. . .
. . .
If you have suggestions and want to share them put them here.
From the developer perspective, I mean, people extending PowerDbg, here are some changes:
- The regular expressions are now in one place, thus reducing the size of the cmdlets, besides it’s easier to change the regular expressions.
- For people working on the PowerDbg code there’re files for each cmdlet, so the maintenance is easier. To ship the code we concatenate the files into one single file. (Piers, thanks for doing that!)
- No more global variables to save state.
The goal for the next version is simple: The new PowerDbg will be much easier to use and extend!
That said, Piers and I are very interested to have more partners who can help us to make this goal a reality.
I’ve got to tell you the number one excuse I hear when inviting PowerDbg users to help me. It’s always a variation of: “I’m new to PowerShell/I’m new to debugging/I don’t know enough about PowerShell/I don’t know enough about debugging”.
Guys, c’mon! I’m a PowerShell hobbyist and PowerDbg was my “Hello world!” application, my very first PowerShell code. Unfortunately the only opportunity I have to use PowerShell is when creating PowerDbg code or when creating PowerDbg scripts for debugging. I wished to know more about PowerShell, but I’m getting better. In fact, I wouldn’t be surprised to know that Lee Holmes when looking at my source code put his hands over his head and screams like crazy. J
So my point here is: I don’t care about your lack of knowledge. I’m interested in your ideas, in your creativity. At the end this is what matters most. PowerShell? You learn it when creating cmdlets, don’t worry.
Here is an example: my colleague Clint Huffman isn’t a developer, he works with infrastructure, specifically Windows, Biztalk and IIS administration but almost everyone that I know, knows or have been using his very helpful PAL tool. By the way, the next PAL version will be based on PowerShell.
In case you’re in doubt and need more thinking let me give you a few reasons to join Piers and myself on the next PowerDbg version:
- If you want to learn more about PowerShell this is a great opportunity.
- If you know a lot about PowerShell and think the PowerDbg code could be more optimized we’d love to have you implementing your optimizations!
- If you want to know more about debugging you can improve your knowledge creating and testing code for PowerDbg. Remember, PowerDbg works for Kernel Mode debugging, managed code debugging and User Mode debugging. Also for live debugging and post-mortem debugging.
- If you don’t want to write code but have some cool ideas to improve PowerDbg, we’d love to know them. How can we create something easier to use? Something you’d like to use? Let’s know, here.
Interested? You can contact me using this blog or writing a comment below. Or yet go to the CodePlex website here.