I don’t know how many of you are writing WinDbg extensions but its not that trivial to most people and especially not that robust and nice such as writing a plugin to MDbg or instrumenting it.

For managed debugging MDbg (which can help you debug both 1.1 and 2.0 frameworks) should be more than enough for all of your managed debugging needs but, AFAIK, MDbg does not handle dump files which are VERY important for post mortem debugging or for performance tuning/debugging in an environment that simply cannot be slowed down due to an attached debugger.

The only way of writing WinDbg extensions, at the moment, is to write C/C++ code. There are a lot of samples that comes with the WinDbg installation but it is not as robust or easy as writing it, say, in C#.

In addition to that, WinDbg has a built-in proprietary mini scripting language that you can use to instrument it a bit but its not standard, lack documentation (at least public one) and is not that easy to use (at least to most people).

What if you could write a WinDbg plugin in C# or in any one of your favorite .NET languages?
What if you could use JavaScript or a Monad like script? Or perhaps some C# and/or VB.NET as your “scripting language” for WinDbg?

I’m playing with the idea of writing a WinDbg extension that will enable writing WinDbg extensions in .NET.
Perhaps it will have a feature to run a special script that is not written in WinDbg’s strange scripting language.

What do you think?

Have you encountered a situation in which you needed to instrument WinDbg but didn’t know its “scripting language” or simply couldn’t do that certain thing you wanted to do?

Did you ever need some kind of functionality that is missing in WinDbg and didn’t want to spend too much time playing around with C/C++ to write it down?

I’ve started writing a prototype to see if this is fesible and it seems it is (at least for the moment ;-) ). I’ll try to find a bit more time to finish it and I’ll post my findings (and hopefully the code if it actually works).

  • Oren Itamar

    I didn’t understand a single word from what you wrote, but a blog written in English seems to be cool. I should try it out… :)

  • http://mcfunley.com Dan McKinley

    It’s a cool idea. I think the reason I stick to complex windbg commands is that just working on an extension project is a pain (you need to build it from within the DDK environment, etc).

    That being said, I’m guessing that there are going to be debugging scenarios where calling managed code from an extension will not work or might modify the experiment. Caveat emptor, I suppose. I’d definitely give it a try if you wrote it.

  • http://dotnetdebug.net Eran Sandler

    Well… don’t forget that the extensions are being loaded in WinDbg’s (or anyone of the debuggers) space, not in th debugee process.

    This means that it will not interfere with anything serious and will only make it faster and better for you to write extensions and to instrument things.

    Anyhow, its good to be getting feedback :-). Thanks!

  • Pingback: !DumpObj on multiple objects » Advanced .NET Debugging

  • Pingback: Writing the WinDbg Extension to Enable Writing WinDbg Extensions in Managed Code » Advanced .NET Debugging