Debugging Windows Phone traffic

Fiddler works great with Windows Phone, and can capture HTTP and HTTPS traffic from both applications and the browser running on the phone. Below, find instructions on how to use Fiddler in three different scenarios:

Configure the Windows Phone Emulator to use Fiddler

The Windows Phone Emulator runs on your desktop and is launched by Visual Studio. You can use Fiddler to capture Windows Phone Emulator traffic by following simple instructions that slightly change how Fiddler is registered.

Monitor WiFi web traffic from a Windows Phone device

If you have a Windows Phone 7 device, you can configure it to send web traffic to Fiddler running on a desktop Windows PC using WiFi. The instructions also include information on how you can configure your phone to trust the Fiddler HTTPS root certificate.

Monitor web traffic from a tethered Windows Phone device

If you tether your phone to your Windows PC using a USB cable, you can configure the Zune application to send the Windows Phone's traffic to Fiddler using the following steps:

WMZuneComm.exe service is hardcoded to use an automatically detected proxy setting, not whatever setting that you may have had configured in IE. The "AutoDetect" settings are configured using a process called WPAD, which depends on DHCP. Fortunately, a friend of mine wrote a DHCP server whose sole job it is to announce that Fiddler is the proxy that everyone should be using.

You can find Dave Risney's WPAD-to-Fiddler extension here: http://deletethis.net/dave/wpadserverfiddlerextension/ 

After you install it, restart Fiddler. On Fiddler's Tools > WPAD Server Settings screen, in the Response Filtering section, choose "No Response Filtering", or create an ALLOW Filter for the local computer's IPv6 loopback address. (I'll ask Dave to make the next version do this automatically).

After that, you'll find that when your Zune attaches to the computer, the Server log screen in the WPAD extension shows your computer querying for the autoproxy, to which it returns a proxy configuration script that tells the client to use Fiddler as the proxy.

Note, you may have to restart your computer's DHCP Client service for the change to be noticed. To do so, launch services.msc, select the DHCP Client entry, and click the Restart service link at the left. The reason is that service caches DHCP responses, including those to WPAD requests, so it may have an outdated entry for the WPAD query that prevents Fiddler's WPAD extension from being queried.

Subsequently, you can see traffic from both the device and from the Zune Update software (WMZuneComm.exe). For instance, when you choose "Settings > Phone > Update" in the Zune client, you'll see the following traffic:

> HEAD http://www.update.microsoft.com/WM/MicrosoftUpdate/Redir/duredir.cab
> 200 OK (application/octet-stream)

> HEAD http://www.update.microsoft.com/WM/MicrosoftUpdate/Selfupdate/duident...
> 200 OK (application/octet-stream)

> POST https://www.update.microsoft.com/v6/ClientWebService/client.asmx
> 200 OK (text/xml)

> HEAD http://download.windowsupdate.com/WM/MicrosoftUpdate/redir/duredir.cab
> 200 OK (application/octet-stream)

To stop Zune from trying to send traffic from itself and the phone to Fiddler, close Fiddler and restart the DHCP Client service.

If you want your phone to trust Fiddler's HTTPS root certificate, see the instructions above.