Latest Microsoft Blogs

Following my post about how to troubleshoot a low CPU performance issue with VSTS Test, I will now do the same for lab 4 where we have high CPU in GC. The scenario is pretty similar in that we have a page ( http://localhost/BuggyBits/AllProducts.aspx ) that seems to be taking a lot of time to execute.  We also see that the w3wp.exe process sits at very high CPU ~100% during the time this page executes. Using Windbg in the lab, we saw that the issue here was that we were concatenating a very large string in a loop.  This was generating a lot of full collections since we were constantly exhausting the large object heap, causing us to spend a lot of time in the GC.  Check out the review for Lab 4 for more details on the issue. What...

I’ve been wanting to dig into the Test features in Visual Studio Team System for a while to “debug” issues during the test phase.  In my previous post I linked to a Swedish screen cast by Mikael Deurell, but for those of you who don’t know Swedish I thought I’d walk through troubleshooting a couple of my labs using the Visual Studio Team System Profiler and Load Tests.  Problem description The issue we will troubleshoot comes from lab 1 in my BuggyBits lab set, and the scenario here is that we see that the execution times for the page FeaturedProducts.aspx keep increasing, and under load the page even times out. Those of you who have walked through the labs will of course know what the underlying issue and resolution is, so please...

I know that perhaps not that many of you know Swedish, but for those of you who do, you might want to check out Michael Deurell’s nice screen casts about how to use visual studio test system to troubleshoot the issues in the buggybits labs along with some windbg fun…  His screen casts are called “Fräschast i Bandhagen”, just love that name (unfortunately doesn’t translate that well to English:)) http://blogs.msdn.com/deurell/archive/2008/09/30/debugga-i-produktion-eller-testa-bort-i-utveckligsfas.aspx Laters, Tess Read More...

Another thing I am curious to know is if anyone is using SOSEX and what advantages it gives you for debugging.  I have talked to the author of it and I think it has a lot of useful commands, just wanted to get everyone’s take on it. Let me know any problems you have with it also. If you don’t know what SOSEX is, take a look at: Steve’s blog Read More...

John Robbins beat me to the punch and wrote an excellent post about using .cmdtree in windbg to ease some .net debugging pain in windbg. The windbg .cmdtree command allows you to create a popup window in windbg with commands that execute when you click on the respective link...  so you no longer have to remember all the sos commands to get around in your managed dump. Read his post here and with the command tree text file he provides you will be up and running in no time...  You can also add the command .cmdtree c:\util\sos-cmdtree.txt once you have this set up, to your commands file to get it loaded automatically when you open dumps....   And of course, you can easily customize your commandtree so that you can execute any...

I have talked about a bunch of commands used to troubleshoot a managed memory problem in the past and given some situations of using them like: High memory, CPU, or other performance problems with .NET High Memory continued - Datatables High Memory part 3 - Native Heap High Memory part 4 - Managed Strings High Memory part 5 – Fragmentation There is another way that we could see a problem that involves fragmentation.  Let’s consider the situation where we see the same situation we saw before, namely: But we do see a bunch of files listed when we look in lm .  So what should this tell us about the problem?  Well, first off, since the files are showing up in lm, we know the problem isn’t the same as, Dynamic Assemblies and what to...

Here are of some of the reader emails I got this week and my answers to them... How do I troubleshoot this memory leak Debugging techniques for capturing stacks of OOMS Do you have a list of Debugging 101 links? Debugging managed code in IE Getting to dependency properties with sos let me know if this is something you find useful so I should keep doing it from time to time, or if it's only useful for the selected few who's email I happened to pick this week:) Note: some of the emails have been edited to fit better in a Q/A format, hopefully I haven't missed any important bits... Q: How do I troubleshoot this memory leak I started observing a slow leak in task manager of about 100 MB / 30 mins, in a web application consisting of WCF...

I was helping a colleague out with an OOM (OutOfMemory) situation he was dealing with.  Problem description: Their applications memory usage would grow over time until they finally ended up with an out of memory exception. First debug: They had gotten a memory dump when memory usage was really high 1.4 GB using debug diag and I opened it up in windbg.exe , loaded up sos (.loadby sos mscorwks) and ran !dumpheap -stat to get the content of the GC heaps. 0:028> !dumpheap -stat Statistics:       MT    Count    TotalSize Class Name ... 7ae77c54   59,028    1,416,672 System.Drawing.Color 663bb5a0   16,530    1,454,640 System.Web.UI.WebControls...

The debugger extension that we were working on getting out with the debugger package has hit some roadblocks and it looks like it isn't going to be shipping with the debugger anytime soon. We are looking to see if we can find an alternative method to get it out.  But for the meantime, just stay tuned and I'll let you know when I find something out. I know the additional functions will be a lot of help to everyone that uses it so hopefully we can get something to you soon.  I'll keep this blog updated with the latest. Read More...

I have probably mentioned this before, but I think it is worth mentioning again because of the frequency of this issue. When debugging a crash, we usually get customers to use a crash rule in debug diag or to use adplus -crash to get memory dumps at the point of the crash.  Both of these attach to the process and gathers dumps when the process is shutting down, which is exactly what we want... The problem is that very often we will get what I call "false-positive" dumps.  I.e. dumps when the process is shutting down, but not dumps of an actual crash, or at least not the shutdown we are trying to troubleshoot. A typical characteristic of such a memory dump is that thread 0 is in the middle of a "normal shutdown"...