After further experimentation it looks writing a WinDbg extension that will let one write WinDbg extensions in .NET is actually feasible. If you remember, I’ve talked about it in my previous post on the subject.

I could have gone the easy way and written some code in .NET exposed as a COM object and make my WinDbg extension call that managed code which will do all the rest, but that would be too easy and a lot less fun :-)

Therefore, I’ve decide to gain some experience and knowledge in the .NET CLR hosting API.

I’m using the hosting API to bind and start the CLR, call the rest of my .NET code and pass the various interfaces that WinDbg is passing me back to the .NET code.

The challenge is to convert the interface definitions of the various WinDbg interface used to interact with WinDbg to .NET. It’s a bit of a tedious job, but someone has to do it… don’t you think?! :-)

Anyhow, once I’ll finish the part about the CLR hosting APIs I’d write a long post about this subject and what I’ve learned while using this API so stay tuned!

Oh, one last thing. In that previous post tinkered with the idea of using some other way of instrumenting WinDbg instead of using its archaic and strange scripting language (actually that’s WinDbg’s command line interface turned into a scripting language).

Anyhow, technically I can enable any language, compile the script at runtime and run the assembly, but its a bit annoying. There is the ability of using IronPython or some other .NET dynamic language (maybe JScript .NET).

What do you think? would you like to be able to script WinDbg in your favorite .NET scripting language?

  • http://mcfunley.com Dan McKinley

    How do you plan on publishing the extensions that people write, given that extension commands are implemented as exported dll functions? I guess all of the managed commands will have to go through the same stub !command?

    Also, one thing that would definitely be useful would be managed code that takes advantage of SOS commands. Parsing the output of !do and providing a managed API for looking at objects would go a long way towards usability.

    My thinking there is that it’s a little difficult to write something useful for managed code here unless you’re willing to dig through the SSCLI and get a feel for CLR internals. I’m willing to do that, as I imagine you are, but the vast majority of people are not.

    Anyway, if you want to put this project on sourceforge or gotdotnet I’d be willing to contribute.

  • Ikas

    Did this ever come out successfully ?
    Anything on the 5th anniversary since this was published ?

  • http://dotnetdebug.net Eran Sandler

    I had something very basic working but never had time to finish it and it eventually didn’t happen. I hope someone else picked (or will pick) the glove.