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?


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?


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.


I’d love to hear your thoughts.  Let me know!

Comments (17)

  1. Paul says:

    As a Java convert, I would really like to see something like Eclipse’s Memory Analyzer

    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.

  2. rakhinelay says:

    i want to know about computer what i do not know..esp  network.

  3. Mike says:

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

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

  5. Mike,

    Can you tell me what you use the source for?  How does it help you troubleshoot problems with your code?

  6. James Hancock says:

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

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

  8. Rick says:

    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 !!!

  9. Francois Ward says:

    At a minimum, SOS for .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 that ships with WinDBG. I read somewhere that in the .NET 4.0 version they were planning on having the nifty features like clickable links and stuff. Definately good if that is true.

    Some features of the 1.1 version, like having strings dumped automatically in a dump heap really must be there.

    Second, something like the memory analyzer that was mentionned, or in the .NET world, SoSAssist, is really needed. I am comfortable with windbg and sos, most are not, and the learning curve is extremely steep for someone not familiar with the low level working of it. SOSAssist is slick, but its nowhere production ready yet.

    DebugDiag, if I remember well, can already tap into .NET if you use SOS in your scripts… I never tried, but i read somewhere that you could use the sos commands. Then its fine as it is (maybe a few more sample scripts). We, however, desperately need a 64 bit version. I’d say most users of WinDBG would be in large enterprise environments, and 64 bit is probably standard, or soon to be standard in a year or two. DebugDiag was 32 bit only last time i tried it.

    Finally, a very dead simple , standard, supported way of plugging into SOS, either with C# or with Powershell (assuming it doesn’t already exist) to extend powershell (and in a way that doesn’t require GAC deploy or any configuration… so ideally loading the plugins should be dynamic at the command line).

  10. Sean says:

    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.

  11. Dave Black says:

    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 $.02

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

  13. Yes a Mat for .Net would be really great. Though there's Yourkit for .NET which offers similar features

  14. Toilet Paper says:

    thanks for sharing this Debugging .NET apps for .NET 4.0 tips i am new to this and this was very helpful for me.

  15. Hire software programmer says:

    Really useful post..


  16. <a href="www.avignaseosolutions>hire seo experts </a> says:

    really good thank for shearning clearly the concept

  17. wordpress developer says:

    nice article.dubugging is not easy's realy tough to find the problems.anyway thanks for sharing such an interesting post with us.:)

    <a href="">wordpress developer</a>

Skip to main content