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
Anonymous
August 21, 2008
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).Anonymous
August 21, 2008
A tool to put designer files and/or code behind files into correct relationship with their form.Anonymous
August 21, 2008
Here are two requests:
- Add the ability to track down handle and memory leaks allocated from managed code.
- Create a GUI that displays how objects are positioned in memory. Highlight potential areas with manged heap fragmentation and pinned objects.
Anonymous
August 21, 2008
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). , LeeAnonymous
August 21, 2008
These are all good requests. Please keep them coming.Anonymous
August 21, 2008
"!analyze -v" is great, but could be better. Please add... !analyze -v -FindTessBlogForFixAnonymous
August 21, 2008
How about error tracking as well in stored procedure executions? I am not sure if this is currently handled.Anonymous
August 21, 2008
Patrick, What kind of error tracking do you mean? Just being able to see exceptions?Anonymous
August 21, 2008
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.Anonymous
August 21, 2008
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.Anonymous
August 22, 2008
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?Anonymous
August 22, 2008
The comment has been removedAnonymous
August 25, 2008
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.Anonymous
August 26, 2008
I fully agree with xklaus - this is a very good use case that i try to do all the timeAnonymous
August 27, 2008
Useful functionality http://blogs.msdn.com/debuggingtoolbox/archive/2008/08/22/powershell-script-chart-and-statistics-from-top-20-objects-leaking.aspx