chevron_left chevron_right
Login Register invert_colors photo_library

Stay updated and chat with others! - Join the Discord!

DbgShell A PowerShell front-end for the Windows debugger engine. filter_list
DbgShell A PowerShell front-end for the Windows debugger engine. #1
The main impetus for DbgShell is that it's just waaaay too hard to automate anything in the debugger. There are facilities today to assist in automating the debugger, of course. But in my opinion they are not meeting people's needs.
  • Using the built-in scripting language is arcane, limited, difficult to get right, and difficult to get help with.
  • DScript is kind of neat, but virtually unknown, and it lacks a REPL, and it's too low-level.
  • Writing a full-blown debugger extension DLL is very powerful, but it's a significant investment—way too expensive for solving quick, "one-off" problems as you debug random, real-world problems. Despite the cost, there are a large number of debugger extensions in existence. I think there should not be nearly so many; I think the only reason there are so many is because there aren't viable alternatives.
  • Existing attempts at providing a better interface (such as PowerDbg) are based on "scraping" and text parsing, which is hugely limiting (not to mention idealogically annoying) and thus are not able to fulfill the promise of a truly better interface (they are only marginally better, at best).
  • Existing attempts to provide an easier way to write a debugger extension are merely a stop-gap addressing the pain of developing a debugger extension; they don't really solve the larger problem. (for instance, two major shortcomings are: they are still too low-level (you have to deal with the dbgeng COM API), and there's no REPL)
  • The debugger team has recently introduce Javascript scripting. Javascript is a much better (and more well-defined) language than the old windbg scripting language, but I think that PowerShell has some advantages, the largest of which is that nobody really uses a Javascript shell--PowerShell is much better as a combined shell and scripting language.

Why PowerShell?

Let me be clear: it took me approximately 4 years to "warm up" to PowerShell. I feel it has sharp edges, aspects that are just plain difficult, and plenty of bugs, both in design and implementation. Sometimes it really irritates me. However, the benefits of PowerShell are compelling, and have convinced me that it's the best thing to use for this project:

It is both a scripting environment and a CLI environment. The fact that it has to do both leads to some negative things like a steeper learning curve, but in the end it is extremely handy, because you want to be able to both do stuff quickly in a command-line REPL, as well as write full-featured, robust scripts.
It is very discoverable—things like Get-Command, tab completion, the ability to expose hierarchical data like a filesystem, the facilities for providing and synthesizing help, are very good.
Tab completion. I know I mentioned it in the previous bullet, but it's awesome enough to get its very own bullet.
The object pipeline: the object-oriented nature of the PowerShell pipeline is so much more powerful and easy to use than the bad old days of string-parsing-based scripting that it's not even funny. Imagine doing "dt" to "dump" an "object", and actually getting an object. DbgShell does that.
People know it: I estimate that the number of people who know PowerShell and/or C# is at least a handful of orders of magnitude larger than the people who know windbg scripting techniques. That means more people will be able to easily "pick up" a PowerShell-based debugger; and it also means that when people need help, the pool of potential helpers is much larger (for scripting-related issues, anyway).
PowerShell is still a general-purpose shell: when using DbgShell, you have access to not just debugger commands, but you can "cd" over to the filesystem, registry, AD, etc.; you can execute Send-MailMessage, Get-WmiObject, Invoke-WebRequest, Invoke-RestMethod, run arbitrary programs, etc.

[Image: screenshot_01.png]

[Image: screenshot_02.png]

[Image: Vs4P58c.png]


Users browsing this thread: 1 Guest(s)