Why Fiddler is like a Sonic Screwdriver

The post was going to be initially titled, why Visual Studio 2008 is like a VW Bora, in reference to the clip_image001current fun I’ve been having with my current Silverlight adventures. Unfortunately that particular episode will have to wait although I might give it as my Ignite presentation at our companies away day, watch this space as I’ll only give it if we don’t get enough other presenters. Anyway I digress, or should that be ramble, the current post has been sparked by two things, watching Doctor Who episodes with my daughter and fixing a simple connectivity problem in Silverlight.

Sonic What?

imageJust in case you’re not a Doctor Who fan, and I know it’s hard to believe that there are a number of them out there, or maybe you’re not British and been brought up with good time lord for the last 40 years (give or take a few gaps) then a little explanation is in order about imagethe sonic screwdriver. The sonic screwdriver is a plot device which allows the good Doctor to fix or interrogate any system or machine to find out information about it, fix it or damage it. Usually it’s just a flick of the wrist, a press of button and a flash of light and its job done, procedure complete, information acquired. Now unfortunately in the real world we don’t have a sonic screwdriver that can do this, but we do have fiddler.

So what has this got to do with Fiddler?

imageFiddler is a free tool that allows you to view the requests made from a browser (usually IE). It can be used to interrogate the requests and responses and to visually give you an indication about what might be wrong with a particular application. Like a sonic screwdriver it can gather information just running in the background without any interaction and can tell you how web applications work at the browser level. This can be useful to see why something might be failing in an application even though you might not have access to the code or to see what a system is requesting even though the code is not you own.

This can allow you to see exactly the information a website is sending and receiving from the browser very useful in an era where the logic is maintained within the browser as JavaScript applications or Silverlight/Flash programs. Here it is often useful to see the responses back from the server or more importantly why a request is failing and often this is to do with security issues or cross site access rights.

It’s screwdriver time!

Often the time you break fiddler out to diagnose the problem is the same time that Doctor Who breaks out the screwdriver. System calls failing, applications not working properly once installed on a remote site or map services not responding. Panic starts to set in hours go by as you try and vainly debug the application then someone (usually me) pipes up ‘have you seen what you get in fiddler’?


Now looking into fiddler is like staring into the matrix, when you have done it enough you start being able to see the woman in the red dress even though the screen just shows the weird green dots. You can start to pick out anomalies in the calls, fiddler helps you, it highlights file not found and errors in bright red and it shows you cached items in grey, both of which can give an indication of possible problems.

Authentication issues or caching problems can both cause errors that can be hard to track down, can manifest themselves in esoteric ways and can end up burning a lot of time to diagnose. Fiddler can be your sonic screwdriver in those moments.

Divining a problem.image

Now this post could equally be titled, how many times does a man need to forget to place a crossdomain.xml file on a web server before it stops being funny, but it does serve as a good example of  where fiddler could have shown a problem well before the final issues were resolved. Crossdomain.xml and its Microsoft equivalent of clientaccesspolicy.xml are used by Flash and Silverlight (which can use both) to tell their particular run time environments that they can access services and data on a particular server. This is particularly important when a rich internet application needs to access services or files from a server that it is not served (downloaded) from initially. Without these files present at the root of the server then the request will fail often with unforeseen consequences.

I must admit after going through the story the reason why there were problems becomes obvious, but the feature layer was coming from another server which I had not used before and I had no idea that there might be an issue with it. But it serves as a reasonable simple example nonetheless.

In my particular case I was using the ESRI Silverlight API in conjunction with the most excellent (and free!) Blacklight control library. Now my application was working without issue when I decided to add another layer into my map using a feature layer. I merrily put the lines of XAML into my page to add the feature class (notice server names have been changed to spare the innocent, any maps generated are done by actors).

image Having set up the right renderers and such like I proceeded to run the application. Nothing came back; I checked the code, double checked, triple checked, but nothing. The base maps came up but no features on the top. I then proceeded to add the new map service as a normal dynamic layer as such to check there wasn’t something wrong with the FeatureLayer class. The XAML looked as such:

image Now this gave me an error in Visual Studio:

imageDoh! I think. I had made the classic schoolboy error of not adding the cross domain file onto the new server. I can see this in fiddler as such, so just waving fiddler at the requests has allowed me to divine the problem, much like (in my head anyway) the sonic screwdriver.

image Now this is a good example of being able to see the problem in fiddler even though the application wasn’t reporting any issues. Being able to diagnose problems in this way should often be the first port of call with any issue that doesn’t get picked up by Visual Studio, especially when calling remote services.

Adding the following cross domain file to the server (it’s internal so it doesn’t require too much security, but don’t use this in the wild verbatim) allowed the application to work fine with both the dynamic layer and the feature layer, problem solved, Daleks defeated (again in my head).


Every time I use fiddler it saves me time, the key is remembering to use it earlier in the problem solve! That way you can save time being burnt on things that have simple solutions and concentrate on the other time killers like getting agreement on the UI design, as we know everyone’s a critic!

So where do I get my screwdriver?

Whilst fiddler is written by a Microsoft employee (Eric Lawrence) it’s not actually a Microsoft product ‘per imagesey’, but it does have some good information about how to use it here (msdn) and here (msdn).

If fiddler isn’t your thing, or you just think that pointing a glowing blue light at a computer might be able to fix any communication problem even in the real world, then you can get your own from Amazon here, in fact if I could get a Wi-Fi one maybe I could hook them both up <goes off to tinker in the shed>.

Leave a Reply

Your email address will not be published. Required fields are marked *