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.

Published 21 August 08 06:00 by Tom

Filed under: ASP.NET, IIS, .NET, SOS

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Brian said on August 21, 2008 10:36 AM:

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).

# Clive Chinery said on August 21, 2008 12:39 PM:

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

# kpullin said on August 21, 2008 12:45 PM:

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.

# Lee said on August 21, 2008 1:14 PM:

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

# Tom said on August 21, 2008 1:59 PM:

These are all good requests. Please keep them coming.

# Bob said on August 21, 2008 3:31 PM:

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

Please add...

!analyze -v -FindTessBlogForFix

# Patrick said on August 21, 2008 8:35 PM:

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

# Tom said on August 21, 2008 9:06 PM:

Patrick,

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

# xklaus said on August 22, 2008 5:05 AM:

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.

# xklaus said on August 22, 2008 7:56 AM:

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.

# Tom said on August 22, 2008 10:33 AM:

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?

# PK said on August 22, 2008 8:24 PM:

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.

-me-

# xklaus said on August 25, 2008 10:42 AM:

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.

# Ran Davidovitz said on August 26, 2008 2:43 PM: