Informal poll on debugger feature requests?


What new feature requests do you want in the managed debugging services? In other words, if you could spend $100 on the following debugger-related items, how would it break down:
1) Support for debugging a managed dump file (without needing SOS)
2) Data breakpoints on managed objects.
3) Better managed (C#) wrappers for everything.
4) Making MDbg the worlds’ best sample. Fixing all the warts, making perfectly clean, documented, ideal code, fxcop clean, etc.
5) Ability to write a profiler in managed code. (This is basically impossible; but I’m curious how much people would like it)
6) More Edit-and-Continue support. If you’ve used EnC, you’ve probably noticed there are a set of “rude edits” where you need to restart. This items is reducing the set of rude edits. For example, letting you add a new class with EnC.
7) Better documentation on ICorDebug and related APIs.
8) More scriptable debugger. For example, being able to put IronPython statements behind breakpoints
9) Better visualizers
10)  Being able to debug light-weight codegen.
11) Improving warts on the ICorDebug API itself.
12) debugging optimized managed code.
13) other debugging features?


I’d also be interested in what your technical scenarios are so I can look for patterns between feature requests and users.


I realize that this is focused on a very small subset of the overall Visual Studio feature set. For example, I intentionally avoided listed IDE features.


I need to emphasize this is an informal poll for my own curiosity only. I’m not making any promises on behalf of Microsoft.

Comments (23)

  1. Sameer says:

    #1 : $50

    #3 : $3

    #4 : $20

    #7 : $10

    #11: $7

    #12: $10

    I wish I had more to spend, Basically #1 & #12 are very important for me, as it’ll allow us to debug dumps from production environments.

    #3 – Better C# wrapper will encourage people to write tools around Mdbg API

    #4 – I love Mdbg, more liberal licensing would help!!!

    #5 – it’ll be fun.

  2. Chui Tey says:

    Being able to debug as fast as VB6 would be good. VB6 had the advantage of running the debugger in-process, so no overhead of starting up a new process and then attaching to it.

    Couldn’t that be done with a good class unloader, and some appdomain magic?

  3. barrkel says:

    #12: $55

    #10: $30

    #4: $15 – this is nearly the same but better than #7.

    #2: $10

    Other things:

    Less interference with WinForms when debugging: i.e. don’t install a new window procedure etc.

    For example, if an unhandled exception in an event occurs but is handled in Application.ThreadException, the behaviour is different whether or not you’re running in the debugger: the debugger causes the application to terminate, while outside the debugger the application can continue (feedback item FDBK27500).

    Another thing: LWCG has almost no verification. But that’s not debug related.

  4. Themes says:

    $40

    3) Better managed (C#) wrappers for everything

    $30

    4) Making MDbg the worlds’ best sample

    $20

    6) More Edit-and-Continue support

    $10

    7) Better documentation on ICorDebug

  5. Brien says:

    1. $50

    13. $50

    The killer feature for me would be integration with a decompiler tool like .NET Reflector. It would be awesome if you could step through code without having source code. There should be a window that tracks the decompiled source for the method you are in. The local variables window should track state for the decompiled method. Along these lines, debugging at the IL level may also be viable, depending on how hard it is to do the full decompiled source implementation.

  6. barrkel – you spent $110. 🙂

    All – make your friends come back and fill this out too. I want more data to look at.

    I’ll go over the specific comments in a little bit.

  7. Dan McKinley says:

    1 – $30

    8 – $10

    12 – $60

    What I really want is better live and postmortem debugging of managed code using the windows debuggers (ie, a better SOS). It would be great to get some source-level debugging of release code, though.

  8. Sean Chase says:

    All $100 on #6 (E&C) – especially for ASP.NET!!!!

  9. Matt Garven says:

    1) $20

    3) $10

    5) $50 (C# has made me lazy hehe)

    7) $20

    I agree with Brien about an in-built reflector – or alternatively just put the source for the .NET Framework up on your symbol server 🙂 I’d spend all $100 on that if I could (and it would still be a bargain).

  10. FWIW, As a pet project, I’ve wanted to merge reflector (a decompiler) into the MDBg gui for a while. The problem was that 1) reflector didn’t have enough information in it, and 2) I haven’t had time. I think it would be a very cool thing to do.

    The point is there’s nothing stopping any of you from doing this as your own pet project 🙂

    Maybe if I add IL-debugging support to the MDbg gui, somebody will pick up the torch and add a decompiler.

  11. alex says:

    That one not in the list, but… local variable names, and msil-source mapping in metadata. But may be you already asked concerned peoples. 🙂

    I am willing to pay 200$ for that.

  12. Kevin Dente says:

    1) $30

    9) $10

    $50 – a completely xcopy deployable, no-install debugger. And a related item, a no-install remote debug server – something we can have our customers or QA department to run and we attach to remotely to debug code with no install impact on the remote system.

    $10 – better support for debugging generated code, like XmlSerializer assemblies.

  13. Colin Burn says:

    I would like to be able to programmatically create a dump file from within a managed application i.e. from an unhandled exception handler.

  14. This is great feedback. Keep it coming!

    Alex – fwiw, we’ve found a lot of people, particularly around dynamic languages, asking for that.

    Kevin – MDbg is a completely xcopy-deployable no install command-line debugger. (Same with Cordbg) But it’s also pretty primitive.

    Re "better support for debugging generated code", can you elaborate on your scenario? This is particularly interesting because any random person can generate code, and so it becomes a very broad problem.

    Colin – you may be in luck. Check out MiniDumpWriteDump in MSDN:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/minidumpwritedump.asp

  15. Kevin Dente says:

    Er..OK, completely xcopy deployable no-install GUI debugger, to be more specific 😉 Something akin to dbgclr, but requiring no install. I can’t stress enough how valuable this would be.

    The scenario for "generated code" I was thinking of specifically was XmlSerializer assemblies. Numerous times I’ve had problems with XML serialization (including finding bugs in the framework), and I’ve had to resort to the config file "leave the temp files after compile" trick to debug the code. In all fairness this isn’t really a debugger thing – it’s more about how the framework generates it’s code. It’s just not a very seamless debugging experience. Honestly, I haven’t given much thought to how I would prefer it to work – it’s just a general "less painful" request.

    BTW, +1 on the integrated decompiler idea. That would be fantastic.

  16. NickG says:

    1) $20

    4) $40

    7) $10

    12) $30

  17. BTannenbaum says:

    My #1 request is better support for mixed (managed/unmanaged) debugging. When both debuggers are used, things slow to a crawl, especially if the app is writing alot of output to the Debug Output window.

    Yeah, it’s better in VS2005, but it’s still too slow.

  18. Marc Eaddy says:

    $60

    6) More Edit-and-Continue support

    => Cleanly separate EnC and debugging functionality so I can still use a "real" debugger (VS) when I need to and so that the JITer can perform aggressive optimization.

    => Supporting use of EnC for non-debugging scenarios and commerical applications, e.g., end-user customization ("moding"), dynamic AOP. Enabling EnC should have low overhead (< 5%). Applying an EnC update should have low update latency (~1 sec) so that it can be used interactively. EnC should work with optimized code and allow optimized code-gen. EnC’d methods should be inlineable.

    => Adding classes at runtime is needed to support Aspect-Oriented Programming

    => Ability to produce IL and metadata deltas needed by EnC using CodeDOM, Phoenix or some other managed API

    => Ability to easily attach (and detach) and perform EnC on code already loaded. The program should only endure EnC overhead when attached.

    => Pitch unused methods. A dynamic AOP solution can result in thousands of replaced methods which a commercial server cannot afford to leak.

    => Ability to add public methods/fields. Needed by AOP so that aspect classes can access newly added public members.

    $30

    13) Other debugging features

    => Co-locating line numbers and local variable names with the assembly instead of putting them in a separate PDB file

    $9

    12) debugging optimized managed code

    => Would be very nice!

    $1

    3) Better managed (C#) wrappers for everything

    => This is currently such a pain! 🙂

  19. akraus2 says:

    Its not a bug its a feature. But sometimes a feature can get in your way if you cannot turn it off. The unhandled Exception Handler in the Whidbey Beta 2 Debugger is one such thing. If I intentionally throw exceptions across COM components which can be managed or unmanaged I would like to be able to debug the exception propagation process. But sometimes I cannot get past the exception window in the debugger which says that the exception was not handled. I looks like the debugger cannot catch all cases where the exception is handled in the application.

  20. Kevin,

    You can do this with the VS 2005 remote debugger (msvsmon.exe).

    Gregg Miskelly

  21. John Lewicki says:

    2) $45

    3) $35

    6) $15

  22. tonyt says:

    1. $35

    2. $30

    3. $25

    7. $10

  23. Ian Ringrose says:

    1) Support for debugging a managed dump file (without needing SOS)

    $10

    2) Data breakpoints on managed objects.

    $30

    3) Better managed (C#) wrappers for everything.

    $20

    4) Making MDbg the worlds’ best sample. Fixing all the warts, making perfectly clean, documented, ideal code, fxcop clean, etc.

    0$

    5) Ability to write a profiler in managed code. (This is basically impossible; but I’m curious how much people would like it)

    5$

    6) More Edit-and-Continue support.

    0$ -> I must write a test before the code thereforee Edit-and-Continue has no value

    7) Better documentation on ICorDebug and related APIs.

    0$

    8) More scriptable debugger. For example, being able to put IronPython statements behind breakpoints

    10$

    9) Better visualizers

    10$

    10) Being able to debug light-weight codegen.

    10$

    11) Improving warts on the ICorDebug API itself.

    0$

    12) debugging optimized managed code.

    5$

    13) other debugging features?