Source is available for MDbg Winforms GUI!


The source for the Winforms GUI extension to MDbg is now available as a sample. (Sorry it took so long).

The download is available here.

 

I’ve also updated the original post with this link.

 

Here’s a screenshot of the updated gui:

 

Comments (21)

  1. Martin Platt says:

    I’m interested in your opinion of what implementing support for debugging custom languages (e.g. a code generator input language or a server-side scripting language) would entail. A bit like JSR-45 for the .NET platform essentially.

    JSR-45 is here:

    http://www.jcp.org/en/jsr/detail?id=45

    Martin

  2. Mike Stall says:

    Martin – the CLR already supports cross-language debugging (as part of .NET’s overall cross-language interopability story).

    Basically, anything you can compile to IL, we can debug for free.

    I recently posted an example of this for reflection-emit: http://blogs.msdn.com/jmstall/archive/2005/02/03/366429.aspx

  3. Martin Platt says:

    Hi Mike,

    Thanks for the link. The code is very interesting especially considering your comment that it would work even with v1.0. That is _very_ important for my use cases.

    I have a related query because I don’t [always] generate IL code – dynamically or otherwise. One of my input "languages" is a YACC-like grammar. In this case, I generate C# source file(s). These are then compiled by users of my tool (and linked to a required runtime assembly).

    Would it be possible to implement similar debugging support so that the input grammar is recognized as the input source?. By this I mean that while debugging the user steps thru/over the input grammar file and not the intermediary C# source files (although an option to see the C# would be nice).

    All of this should work in the presence of calls into methods exposed by the [code gen’ed for] grammar and calls from the [code gen’ed for] grammar to other methods in the project.

    Martin

    I use the #line directive in C# currently but, it’s not pretty. The debugger is just debugging the generated C# file(s). It is unaware of the original source grammar.

  4. Mike Stall says:

    Martin: that’s an excellent question.

    What you want is the ability to debug an arbitrary table-driven state-machine, right?

    So the current source file / callstack (and maybe even locals, etc) would be calculated based off the state machine’s current state, and not the actual underlying code that the state machine was running, right?

  5. Martin Platt says:

    Mike,

    > Martin: that’s an excellent question.

    > What you want is the ability to debug an arbitrary table-driven state-machine, right?

    Well, yes and no. Conceptually the generated code can be viewed as state machines but they aren’t always table-driven or at least there aren’t explicit "tables"). They might be recursive descent parsers for instance. Comparable to your C# code for Blue. 😉

    > So the current source file / callstack (and maybe even locals, etc)

    > would be calculated based off the state machine’s current state,

    > and not the actual underlying code that the state machine was running, right?

    In a manner, yes. The source file (& line/col)/call stack/locals would refer to the source grammar not the intermediate gen’d C# code.

    Martin

  6. This question likely reflects a lack of understanding on my part. When I use MDbg Winforms GUI to attach to a running process, I can the list of loaded modules (some of them which say symbols loaded) but I always get the message "No source for current thread". What am I missing to be able to debug? Ideally I’d like to "IL-debug" if that’s possible.

  7. Mike Stall says:

    Notre –

    1) The process is stopped, right? If not, try "Debug | Break".

    2) Are there symbols loaded for the modules that you want to see source for on the stack?

    3) Can you get a stack trace from the command prompt in the gui?

    Note that the gui doesn’t support debugging at the IL-level.

  8. 1) No, the process is not stopped. The "Debug|Break" option is grayed out. Beneath the Debug menu, after attaching to the appropriate process, only the Detach and Kill menu items are enabled.

    2) Yes, according to "View|Modules".

    3) Running the "Where" command gives the following results:

    Thread [#:0]

    No source for current thread #0

    Note that the source I’m trying to debug is managed code. Maybe that’s my problem?

    Do you have any pointers to documentation or blog entries that show how to use MDbg (without the GUI) to do debugging at the IL-Level? This is what I’d really like to do.

  9. Mike Stall says:

    Notre –

    Note that the MDbg gui doesn’t provide IL-level debugging. MDbg has a command line extension for primitive IL-level debugging (maybe I’ll try to blog more about it. A small peek is at http://blogs.msdn.com/jmstall/archive/2005/02/19/376666.aspx )

    Perhaps the thread you’re inspecting just doesn’t have any managed code on the stack? Try looking at the other threads. Perhaps "foreach where", or using the gui’s thread window.

  10. Thanks Mike! I figured out what was wrong and it was a user error; after attaching to the process and setting my breakpoints, I failed to issue the "go" command. After this, managed debugging worked just fine. Ironically, I figured out what I was doing wrong by playing with MDbg itself rather than using the GUI; I was able to apply the same principles in the GUI after figuring it out in MDbg.

    I will review your small peak blog. I’d love to see anything else you write about IL debugging in the future.

  11. I had a sample GUI extension for Mdbg Beta 1. However, it doesn’t build with Mdbg Beta 2 because:   …

  12. I had a sample GUI extension for Mdbg Beta 1. However, it doesn’t build with Mdbg Beta 2 because:   …

  13. I had a sample GUI extension for Mdbg Beta 1. However, it doesn’t build with Mdbg Beta 2 because:   …

  14. ICorDebug (ICD) is a com-classic interface. In terms of COM threading models, ICorDebug is technically…

  15. Here’s my first Silverlight 1.1 (which has .NET support) app. It bounces various shapes around the canvas.