DbgShell v0.8.26-beta releases: PowerShell front-end for the Windows debugger engine

by do son · Published May 10, 2019 · Updated November 4, 2024

DbgShell

A PowerShell front-end for the Windows debugger engine.

The goal of the DbgShell project is to bring the goodness of the object-based PowerShell world to the debugging world. When you do ‘dt’ to dump an ‘object’, you should get an actual object. Scripting should be as easy as writing a PowerShell script.

The DbgShell project provides a PowerShell front-end for dbgeng.dll, including:

a managed “object model” (usable from C# if you wished), which is higher-level than the dbgeng COM API,
a PowerShell “navigation provider”, which exposes aspects of a debugging target as a hierarchical namespace (so you can “cd” to a particular thread, type “dir” to see the stack, “cd” into a frame, do another “dir” to see locals/registers/etc.),
cmdlets for manipulating the target,
a custom PowerShell host which allows better control of the debugger CLI experience, as well as providing features not available in the standard powershell.exe host (namely, support for text colourization using ANSI escape codes (a la ISO/IEC 6429))

The custom host is still a command-line (conhost.exe-based) program (analogous to ntsd/cdb/kd), but it can be invoked from windbg (!DbgShell).

In addition to making automation much easier and more powerful, it will address other concerns as well, such as ease of use for people who don’t have to use the debuggers so often. (one complaint I’ve heard is that “when I end up needing to use windbg, I spend all my time in the .CHM”)

For seasoned windbg users, on the other hand, another goal is to make the transition as seamless as possible. So, for instance, the namespace provider is not the only way to access data; you can still use traditional commands like “~3 s“, “k“, etc.

Notable Features

Color: support for text colourization using ANSI escape codes (a la ISO/IEC 6429)
Custom formatting engine: Don’t like .ps1xml stuff? Me neither. In addition to a standard table, list, and custom views, you can define “single-line” views which are very handy for customizing symbol value displays.
Custom symbol value conversion: For most variables, the default conversion and display are good. But sometimes, you’d like the debugger to do a little more work for you. The symbol value conversion feature allows, for instance, STL collection objects to be transformed into .NET collection objects that are much easier to deal with.
Derived type detection: For when your variable is an IFoo, but the actual object is a FooImpl.
Rich type information: exposed for your programmatic pleasure.
Q: Does it work in WinDbg? I will only use WinDbg. A: Yes–load up the DbgShellExt.dll extension DLL, and then run “!dbgshell” to pop open a DbgShell console.

Changelog v0.8.26-beta

Updated debugger engine binaries (dbgeng.dll et al).
lmvm command for windbg muscle memory compat.
Alternate formatting engine:
- initial support for calculated properties (“lm | ft Name, SymbolStatus” will now use the alternate formatting engine).
- Got rid of a lot of slow -CaptureContext stuff (thanks @Zhentar!).
- other performance improvements (thanks @Zhentar!).
New command: ForEach-DbgDumpFile.
Can now display const statics.
Added a per-target, per-module caching facility (Get-DbgTargetCacheItem).
Better handling of native/wow64 ntdll and TEB (thanks @Zhentar!).
ColorString interpolated string support (thanks @Zhentar!).
Added a Remove-Color command.
Work around a few dbgeng bugs.
Many other enhancements and bugfixes.