Debugging .NET apps for .NET 4.0
With Visual Studio 2010 and .NET 4.0 getting ready to be shipped sometime in the next year, I wanted to see what were peoples ideas for how to debug applications that were written with them. Are you happy in production with what you are currently doing? Do you use SOS.dll to troubleshoot problems?
SOS
The main place I am really interested in is production debugging. Is SOS a sufficient tool to get the data that you need? If you had another version of SOS for .NET 4.0, would you be happy with the features it has or would you want something more?
Debugger
I understand that using a typical debugger can be very difficult for people. If you don’t know what you are looking at, it can be very difficult to understand what is a problem and what is normal. It is also very difficult to see typical problems. For example, if you know your program is crashing due to running out of memory, what do you do to see what is taking up memory? How do you tell if it is fragmentation? What types of fragmentation are there that you would need to look for?
I wanted to see what the interest is in a different way of looking at the data, something more along the lines of DebugDiag.
Opinions
I’d love to hear your thoughts. Let me know!
Comments
Anonymous
September 02, 2009
As a Java convert, I would really like to see something like Eclipse's Memory Analyzer http://www.eclipse.org/mat/ It takes a standard java heap dump, and allows you to graphically analyze it, and even perform SQL-like queries against it. It really is an amazing piece of software. You can take a heap dump from a production VM with little impact, copy it to another machine and spend as much time analyzing it you need.Anonymous
September 02, 2009
i want to know about computer what i do not know..esp network.Anonymous
September 02, 2009
Stepping into framework source is a problem, because the .NET 4.0 source is not available, and something as simple as a hotfix makes it impossible to use (framework versions no longer match, so the server thinks it doesn't have the source for your version of the framework).Anonymous
September 03, 2009
Paul, That is a good idea, I have been thinking of something like that but not sure if I will be able to make that happen, but I'll see what can be done.Anonymous
September 03, 2009
Mike, Can you tell me what you use the source for? How does it help you troubleshoot problems with your code?Anonymous
September 03, 2009
I just want the debugger to handle edit and continue with Linq. It kills my productivity right now to the point where moving from datatables to linq is causing major slow downs. (and linq really really really needs to work in the immediate window!)Anonymous
September 03, 2009
James, I am looking more at the production debugging stage, where we are looking at dumps and things like that. Visual Studio debugging is something that I'd like to discuss as well, but it isn't really something that I am looking to affect at the moment. But thanks for your feedback. I will pass it along to the visual studio debugger team.Anonymous
September 03, 2009
I HEAVILY use SOS.dll and psscor.dll .... The .NET 4.0 version needs to be updated to include all of the nice features that were left out of .NET 2.0... !aspxpages !!!Anonymous
September 03, 2009
The comment has been removedAnonymous
September 03, 2009
for ASP.NET WebForms debugging - it would EXTREMELY helpful for experienced and non-experienced developers alike if somehow, during the debug process, VS could should a chart, tree or some other visual tool that showed the order of the events as they related to the Page Life Cycle. My first request would be that they revamp the whole Page Life Cycle or else give the developers more control over the order events are executed - but since that is not likely to happen - giving the developers a visual tool to show when the order the events will occur and where they are currently in the debug process on that chart would be most helpful.Anonymous
September 04, 2009
DebugDiag is a great tool and intuitive. It makes it easy to create a crash dump when needed. The problem is taking the crash dump and trying to analyze it. I have used WinDbg and SOS a small number of times to debug some particularly difficult problems and have hobbled along by spending a great deal of time searching for documentation and examples. The biggest challenge for me, as well as plenty of others I've spoke to, is that there is no comprehensive and well-put together source of documentation and examples for working with WinDbg and SOS. The best resource I've found is Tess' MSDN blog (which is extremely helpful). But her posts are specific to certain examples and aren't comprehensive. Documentation on all the commands, WHEN each should be used, and examples of how to use it in a real-world example is seriously needed for these tools to be as useful as they could be. This is especially frustrating since WinDbg and SOS have been around for so long! One additional option is to add a GUI on WinDbg that makes the tool more usable and intuitive to use. Just my $.02Anonymous
February 18, 2010
The article is good provides useful information & .NET 4.0 should have all the features of the CLR 2.0 version as well as the features of the CLR 1.1 version it was helpful as well.I like the article very much as it is very informative and hope to see more of such articles.Anonymous
May 30, 2010
Yes a Mat for .Net would be really great. Though there's Yourkit for .NET which offers similar featuresAnonymous
February 14, 2011
thanks for sharing this Debugging .NET apps for .NET 4.0 tips i am new to this and this was very helpful for me.Anonymous
April 10, 2011
Really useful post.. thanks...Anonymous
February 02, 2012
really good thank for shearning clearly the conceptAnonymous
February 10, 2013
nice article.dubugging is not easy task.it's realy tough to find the problems.anyway thanks for sharing such an interesting post with us.:) <a href="www.xithi.com/">wordpress developer</a>