Using Fiddler To Prove It’s Not Your Fault

I look after end-user computing devices – the laptops, desktops, mobile devices across corporate environments. One common theme for anyone providing IT support in this area should know something already: You really need to know how to lay on the evidence when something is not a desktop issue. I’ve heard many desktop support staff complain about this over the years. My view is get over it, that’s life, it happens. Learn to use tools that can find the root cause rapidly.

In this case we were looking at call logging application, used across multiple capital cities in Australia – Perth & Sydney. The users in Perth reported poor performance.

Their description of the issue, in my mind, straight away sounded like an application performance issue:

  • The problem is intermittent
  • When it occurs, everybody seems to be affected
  • Opening pages goes from <1 second to 5 seconds or more
  • Issue occurred on XP+IE7, XP+IE8 and Win7+IE8 machines
  • When Sydney goes offline, our performance improves

However application support had responded:

We’ve checked the performance of our application we can’t find any issues.

And network team responded:

We’ve checked for packet drops and didn’t find any.

Onsite support in Perth had been kind enough to capture Wireshark logs of the issue. However there were no obvious network issues there – and as the traffic was HTTPS (i.e. encrypted) we couldn’t really get any performance data out of it. Note if it had been HTTP traffic (non-encrypted) we could have used Microsoft Network Monitor to convert the WireShark log to .CAP format, then process using the Virtual Roundtrip Analyzer

It’s at this time application support came up with another idea:

Did you delete your web cache? We recommend clearing your cache once daily.

Let me translate this:

I have no idea what is causing this problem so here is some random thing you can do to make you feel better.

To me this was a bit illogical primarily because I would think clearing cache would introduce performance problems as data would have to be re-cached. If pages shouldn’t be cached the application should be telling the browser no-cache

It was evidence collecting time, bring on Fiddler ( king of web-debugging proxies.

However we got the following error message when running Fiddler

15:11:40:3771 !WARNING: Fiddler has detected that system policy ProxySettingsPerUser = 0. Unless run as Administrator, Fiddler may not be able to capture traffic from Internet Explorer and other programs.”

This is because the machine had IE7, and IE7 by default used per-machine proxy settings. ( This can be changed either through group policy or setting the following registry key:


Internet Settings]

Value Name: ProxySettingsPerUser

Data Type: REG_DWORD (DWORD Value)

Value Data: (0 = whole machine, 1 = per user)

Then we enabled Decrypt HTTPS option in Fiddler and started capturing the traffic. What we found were examples like this:


So we saw two things:

  • 7 seconds from Server Got Request to Server Begin Response, this is in line with the type of delay being experienced
  • The page is set to no-cache, so it doesn’t get cached. So clearing cache does absolutely nothing.

Sending the Fiddler reports to application support we then received the message:

We’ve engaged the vendor and it seems there are some performance issues related to heavy customization of product. We are working with vendor to find a resolution.

Now that being said I did also notice the pages were super-heavy in JavaScript so going to Windows 7 + IE9 would also get a significant performance boost…but if server takes long time to serve page, even that won’t be enough to make it snappy.

About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in Fiddler, Internet Explorer and tagged . Bookmark the permalink.

3 Responses to Using Fiddler To Prove It’s Not Your Fault

  1. ericlaw1979 says:

    FWIW, the KB Article in question isn’t actually correct. ProxySettingsPerUser:0 was never the default, and was always something that was only on when set via Policy/Registry manipulation.

  2. Peter Graves says:

    I’m seeing the same thing, but worse. A long delay between Server gotrequest and beginreponse.
    It only happens using IE 11. IIS, the application is C# .net. Adding the site to compatibility view in the client settings fixes it, but makes the site malformed. How can I debug this more deeply to see what the server is doing and why this is happening? Any ideas you have on this would be appreciated. Thanks

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s