SOS Feature Requests for the Future

I know I have asked a similar question in the past, but what I would like to know now is, without any bounds on what it can do, what would you like to see from a troubleshooting tool for .NET?

I am thinking about doing something radically different and would like to get some suggestions from everyone as to what you would like to be able to do.  This can be anything, so don’t limit yourself to how things function now.  If you want the tool to do more work for you, or help you narrow your focus, that is the stuff I want to hear about.

For example:

I would like to be able to run a command and have it tell me if most of my memory is managed and what the largest leaking object type is and who allocated it.  Or, I want to know where I am spending the bulk of my time at in my code.

Any ideas or suggestions are welcome.  I want to get a feel for what would really help people the most and then see what I can do to get something like that working for everyone.  This could also include a GUI front-end that would allow easier interaction with either a dump or a live process.

Thanks and look forward to hearing your ideas.

Comments (15)

  1. Brian says:

    I think a GUI would be just great, but I would love the ability to be able to flag an object and track the whens, whats, and wheres of how that object was used.  It may be as simple as writing the call stack to the trace every time a flagged function is called (I may just have to try that).

  2. Clive Chinery says:

    A tool to put designer files and/or code behind files into correct relationship with their form.

  3. kpullin says:

    Here are two requests:

    1) Add the ability to track down handle and memory leaks allocated from managed code.

    2) Create a GUI that displays how objects are positioned in memory.  Highlight potential areas with manged heap fragmentation and pinned objects.

  4. Lee says:

    At the risk of sounding nitpicky, I don’t think you have to worry about anyone making feature requests *for the past*.  ;]

    I’d be happy if Visual Studio 2008, and/or beyond, was smart enough to tell me the name of the ever-mysterious object when “object reference not set to an instance of an object” (message recalled from my hazy memory).

    , Lee

  5. These are all good requests.  Please keep them coming.

  6. Bob says:

    "!analyze -v" is great, but could be better.  

    Please add…

    !analyze -v -FindTessBlogForFix

  7. Patrick says:

    How about error tracking as well in stored procedure executions? I am not sure if this is currently handled.

  8. Patrick,

    What kind of error tracking do you mean?  Just being able to see exceptions?

  9. xklaus says:

    I’d like to get a mix of dumpheap -stat and gecroot. Just parse the whole managed heap and look which objects are referenced by one object. This would help to enable browsing through the object network and find out why objects are still referenced.

  10. xklaus says:

    I’d like to browse through the complete managed heap. Where I get all types and instances like with dumpheap and also all references to other instances of an instance. This would solve my problem with the time consuming gcroot command, when I run out of memory.

  11. xklaus,

    What problem are you trying to solve?  Just where an object is referenced?  So you mean some kind of treeview?  Like where you can expand the types and see the objects that reference them?

  12. PK says:

    1) Better visual representation of what we are debugging. ie. tree heirachy so we can visually drill down, etc.

    2) Visual way of seeing what objects are eating up our memory.

    3) track objects and see their history. So if i track/tag an object that was created, i can then see how it grows or shrinks?(hmm .. maybe this is a lame idea)

    4) I suppose i would really like to see less command line stuff and more visual stuff. I suppose this means it’s dumming down winbbg? I found that when i show people how i debug memory dumps for bugfixing, they just look at me with a blank stare thinking this is crazy.


  13. xklaus says:

    Hi Tom,

    The main scenario is to find references which are forgotten to be nulled. This ends in large amounts of instances (and memory) still being referenced, because someone missed to null one reference.

    Up to now I use !dumpheap -stat and !dumpheap -mt to find the instances which should be collected by the GC. Then I try to find the right place where we missed to set a reference to null with !gcroot. This take up to 15 min per gcroot call when you have big heaps. So this solution works, but is not really usable.

    The idea is to scan the complete heap like dumpheap and figure out which types and instances are there. When I also look into every instance and find out what instances are referenced there, I end up with a complete instance network, which I can navigate through. This could also be done on an dump file so you get a instance network which you can browse through and get an idea where you missed nulling the reference.

    Did this explains my problem and idea? Feel free to ask if not.

  14. I fully agree with xklaus – this is a very good use case that i try to do all the time