As many of you know, a debugger is an invaluable tool for a software developer. A good debugger really helps when tracking down some problem with the software you (or someone else) has written.

On the other hand, when you don’t have the ability to single-step the code through a debugger, or when you get poor, non-descriptive error messages, it can really be a nuisance. In this blog posting, I will go through the second of these cases (i.e. non-descriptive error messages).

When working with WCF services, the error messages can sometimes be really unintelligible. Or rather: they don’t tell you very much about the problem. This is the error message I got today when using a WCF service from within a Silverlight 3 application:

Allright. Let’s peek into the View Detail box, shall we? This is what it looked like, after expanding some InnerExceptions:

The stack trace looked like this:

{System.Net.WebException: The remote server returned an error: NotFound.
   at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
   at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
   at System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)}

Not very descriptive, huh? So, maybe there is a way to get more information about this exception somehow, but… for the sake of this blog posting, let’s assume that it actually is impossible. :-)

It is my impression that sometimes (for some odd reason…) the real error message is “hidden” within the WCF layer. But, luckily for us, there is an easy way to poke around in the actual communication between the WCF client and the server. Its name is Fiddler, and it’s actually a freeware tool developed by a Microsoft employee. Fiddler works as an HTTP proxy, letting you intercept the traffic between any HTTP client and server (this includes WCF, if you are using one of the http binding types as the binding for your WCF client, which is often the case). When the program is started, it automatically takes over all traffic from most HTTP clients on your client machine (including WCF clients and Internet Explorer). It does so by modifying the the Internet Explorer proxy settings. When Fiddler is closed, it automatically changes the proxy settings back for you, so it’s very convenient to use in that sense.

Here is what the program looks like when you start it up:

As you see, Fiddler itself has performed an update check to see if any new version of the program is available. If you click this line in the Web Sessions list, you are able to inspect how this specific request/response looked.

Now, let’s get back to our real-world debugging scenario. We assume that the client has run, and the illegal operation above has been performed. This is what our Fiddler console looks like now.

As you see, even Fiddler itself realizes there something wrong with this request. I guess this is because of the HTTP 500 result code that was sent by the server (HTTP result code 500 means “Internal Server Error”). Let’s click this red-marked row:

We are now shown some basic information about the session, which we are not very interested in right now but which could be more interesting if you were size-optimizing a web site (or just checking how heavy it would be to load over different kind of Internet connections/geographic locations). Let’s open the Inspectors tab (marked with red above).

We are now shown an overview of the HTTP headers involved in this request. Still, we are not getting really what we where aiming for. Let’s open the TextView for both the request and the response (marked with red above).

Now we’re talking! Quite a lot more useful than the “NotFound” error we got earlier. A stack trace is always a lot more useful; as you see, we can even see the line number in the source code file where the error appeared, giving us the opportunity to debug the server and place a breakpoint there (for example).

Well, that’s basically it. In this blog posting, you have been introduced to a WCF scenario where no real clue was found in the exception details as to what the real problem was. You’ve learned the basic concepts of how Fiddler works, and how you can use it to debug WCF services (and web services, and really any kind of web-related scenario – web browsing, AJAX, you name it…). For those of you who already very skilled in these areas, too bad; you may not have learned very much from this. But relax, take it easy, I’ll write about something more technically challenging some other time. I promise. :-)