Latest Microsoft Blogs

For all of you who have been asking me if there is a 64bit version of Debug Diag (used to debug 64 bit processes), I am happy to say that yes, Debug Diag 1.1 64bit is now released. You can download it here: http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en#filelist And an updated whitepaper talking about how to use it is available here: http://www.microsoft.com/downloads/details.aspx?familyid=4A2FBD0D-0635-440C-A08B-ED81BDBB5960&displaylang=en Neither this version (nor the 32bit one) officially support debugging/analyzing on Vista/2008/Win7 because of some known compatibility issues (being looked at for future versions), however for a lot of tasks it works quite well on those...

Is it a plane, is it a bird, is it a UFO? Before you can delve into any kind of troubleshooting of an issue you need to thoroughly define it.  If you don’t you’ll probably end up spending a lot of time randomly gathering and looking at data that is probably not even relevant to the issue at hand.  More importantly, how do you even know that your problem is fixed if you don’t have a good definition of the problem? This might sound like common sense, but having worked with troubleshooting the better part of the last 10 years I can tell you that it is extremely common that people start looking at data before really understanding the problem.  More often than not this is because people are stressed and want to fix the problem fast...

I know that for a lot of you this is a bit far into the future, but I thought it would be nice to run through a few of my lab scenarios to show off some of the new features in Visual Studio 2010.  I am sure that I will miss a bunch of cool features here as this post is just based on my first experience with this, but I will likely post more about these features as we get closer to RTM.  As we are only in Beta, anything and everything may change before RTM and the below is just based on my own impressions so there may be other better ways of doing things. Why debug dumps with Visual Studio .NET I love WinDbg and will probably continue using it for many years to come since it is a very simple and clean and powerful debugger.  I...

Since a .net exception is a .NET object like any other, it gets stored on the GC heap when you (or some code you call) calls new XXException().  This means that if you have a memory dump of a process you can dump out all the recent exceptions that have occurred, or rather all exceptions that have not yet been garbage collected, which will give you a good feel for what exceptions occurred recently.  Doing this is pretty easy if you have sos loaded (.loadby sos mscorwks) in windbg 0:015> !dumpheap -type Exception ------------------------------ Heap 0 Address       MT     Size 02ea6b0c 79330a80       72     02ea75f0 7930eab4      ...

Spike in our data access support team has a really good blog talking about data access related issues in .net. Recently he wrote a really good post about what you should gather to troubleshoot a connectivity issue effectively such as Connection strings SQL Server logs The exact error message (with stack trace and other details) Netmon traces Memory dumps File version info along with what you should look for in each… I would recommend both that post and the blog as a whole to anyone dealing with data access related issues. Read More...

... and here are the slides for the interactive session Read More...

I still have to figure out a way to host the video from the break-out session but until then, here are the slides for my presentations (attached). And here are a list of some of the tools and resources I used for the presentations Tool/Resource Comment Download Link Debugging Tools for windows Windbg, adplus etc. http://www.microsoft.com/whdc/devtools/debugging/default.mspx Debug Diag 1.1 Analyzes dumps, good for native memory leaks http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en Cmdtree Command and textfile to get a treeview with commands in windbg http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/09/17/windbg-cmdtree-file-that-eases-some-sos-pain.aspx Tinyget Poor mans...

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

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