CLR - a little bit of everything, now including error reporting

Debugging Silverlight with SOS.dll

vipul — Tue, 26 Aug 2008 01:13:00 GMT

Tess just posted an article on how to debug Silverlight application using sos.dll.

If you have been using sos.dll to debug your silverlight as well as desktop applications and are stuck, contact me through the contact page and I can try to help you out.

Dr Watson and the Common Language Runtime

vipul — Mon, 22 Jan 2007 20:41:00 GMT

A lot of time has passed since my introductory post and I was really felling guilty that I could not spend some time to share on what I had promised.

Now that I have got some time to post, let me talk about the CLR error reporting infrastructure.

With .NET 2.0, CLR shipped with a shim which, when an application fails, would pop up the (un)famous "Send this error report to Microsoft" dialog.

Why is this important? For multiple reasons:

It provides a consistent interface to the user. If a native application allows to create a Watson report, why should a managed application not allow me to do the same?
It allows you to report possible bugs in the CLR, as well as your/third party's code. If you look at the Watson UI, you will notice that it pops up a dialog to send this information to Microsoft. If you do opt to do this, on Vista, the Watson application will check to see if this is a known problem, If yes, it will take you to the page containing the information on how to resolve the problem. If not, the information uploaded (at your consent) might be a minidump of the process, which is then analyzed for the cause of the failure by running different heuristics. Vendors who sign up to look at their watson reports will be able to see the common (and possibly uncommon) reasons for the failure of the application.
Every report you send to microsoft helps us to make our application better and bug-free. So next time you see THE dialog, dont hesitate to send the report. As mentioned in the one of the dialogs, no confidential information is being sent to Microsoft.

Let's write a test application which crashes(Code is attached).

using System;

class Test

{

public static void Main()

{

throw new Exception();

}

When you click on the "What data does this error report contain" link on the above dialog, you get the details. Here, it tells that the failure was due to System.Exception.

If you like to dig deeper, and which I would encourage you to go, you can click in the "View the contents of the error report" link on the above dialog. This will pop up a dialog with a lot of information, most of which might confuse you (it did to me when I first saw it). This dialog contains some of the technical information needed to diagonize the failure. I will go into more details in some other post. But just to give you a glimpse, besides other information, this dialog contains the information on which modules were loaded when the process crashed.

Welcome post and introduction

vipul — Wed, 06 Dec 2006 01:47:00 GMT

Console.WriteLine("Hello World!");

Hi everyone, I am Vipul, a tester in the CLR team (Developer Services team, to be more . My areas of work include Managed Error Reporting a.k.a. Watson and SOS. Earlier, I was a Microsoft MVP , before Microsoft hired me full-time. I have written a few articles on LINQ earlier (Anonymous types, Extension methods, Lambda expressions, Type inference, Object Initialization and creation and Collection initialization) and I had a blog here.

Though I am a new face here (only 6 months into the team), you must already be knowing my team members by name - Mike Stall, Rick Byers, Thomas Lai, Jonathan Keljo, Jan Stranik and Mithun Shanbhag.

I plan to ramble about how to debug managed applications using tools like windbg and what happens when my managed application crashes. Since I love many features of the CLR besides the others I work on, you should probably hear me talking about other stuff as well.

Stay tuned for my upcoming posts on such topics.

These postings are provided "AS IS" with no warranties, and confer no rights.