Welcome to MSDN Blogs Sign in | Join | Help

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:

 

Published Friday, February 04, 2005 7:50 PM by jmstall
Filed under: ,

Comments

# Winforms gui on top of Managed debugger sample.

Friday, February 04, 2005 7:51 PM by Mike Stall's .NET Debugging Blog

# re: Source is available for MDbg Winforms GUI!

Saturday, February 05, 2005 10:09 AM by p2p
Good job.

# re: What would it take to implement JSR-45 style debugging support

Tuesday, February 08, 2005 5:02 PM by Martin Platt
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

# re: Source is available for MDbg Winforms GUI!

Tuesday, February 08, 2005 10:52 PM by Mike Stall
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

# re: Debugging generated code in the manner of JSR-45

Wednesday, February 09, 2005 2:34 AM by Martin Platt
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.

# re: Source is available for MDbg Winforms GUI!

Wednesday, February 09, 2005 3:14 AM by Mike Stall
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?

# re: Debugging generated code in the manner of JSR-45

Wednesday, February 09, 2005 4:56 AM by Martin Platt
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

# Managed Debugger Sample

Friday, February 11, 2005 12:38 PM by Mike Stall's .NET Debugging Blog

# Winforms Mdbg threading issue

Saturday, February 12, 2005 12:16 AM by Mike Stall's .NET Debugging Blog

# re: Source is available for MDbg Winforms GUI!

Thursday, March 03, 2005 4:06 PM by Notre Poubelle
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.

# re: Source is available for MDbg Winforms GUI!

Thursday, March 03, 2005 5:58 PM by Mike Stall
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.

# re: Source is available for MDbg Winforms GUI!

Friday, March 04, 2005 3:31 PM by Notre Poubelle
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.

# re: Source is available for MDbg Winforms GUI!

Friday, March 04, 2005 4:31 PM by Mike Stall
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.

# re: Source is available for MDbg Winforms GUI!

Friday, March 04, 2005 4:57 PM by Notre Poubelle
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.

# Debugging SQL Server 2005 (Yukon) CLR Stored Procedures and Functions

Wednesday, March 09, 2005 11:18 AM by Cipherdelic

# Updating MDbg GUI for Beta 2

Friday, June 03, 2005 1:27 AM by Mike Stall's .NET Debugging Blog
I had a sample GUI extension for Mdbg Beta 1. However, it doesn’t build with Mdbg Beta 2 because:   ...

# Updating MDbg GUI for Beta 2

Wednesday, August 10, 2005 4:09 PM by Mike Stall's .NET Debugging Blog
I had a sample GUI extension for Mdbg Beta 1. However, it doesn’t build with Mdbg Beta 2 because:   ...

# Updating MDbg GUI for Beta 2

Thursday, August 18, 2005 4:56 PM by Mike Stall's .NET Debugging Blog
I had a sample GUI extension for Mdbg Beta 1. However, it doesn’t build with Mdbg Beta 2 because:   ...

# ICorDebug, MTA, STA.

Thursday, September 15, 2005 1:18 AM by Mike Stall's .NET Debugging Blog
ICorDebug (ICD) is a com-classic interface. In terms of COM threading models, ICorDebug is technically...

# Mike Stall's .NET Debugging Blog : MDbg Linkfest

Monday, June 19, 2006 2:57 AM by Mike Stall's .NET Debugging Blog : MDbg Linkfest

# My first Silverlight 1.1 app

Friday, May 18, 2007 9:51 PM by Mike Stall's .NET Debugging Blog

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

New Comments to this post are disabled
 
Page view tracker