Windows Phone 8.1 Emulator not proxying through Fiddler

Question

I've just started looking into Win Phone 8.1 and playing with proxying some data via Fiddler from the emulator but it doesn't seem to want to play ball. All the guidance around Phone 7 and 8 (not 8.1) seems to be that the emulator will route traffic as you'd expect other apps on the machine talking HTTP to do but I'm not seeing it happen. For example, Eric's post here: http://blogs.msdn.com/b/fiddler/archive/2010/10/15/fiddler-and-the-windows-phone-emulator.aspx

There are no filters applied.

Content is loading successfully in IE on the emulator.

Fiddler is successfully capturing all traffic from the host.

The emulator can successfully browse to the host in order to pull the Fiddler root cert.

Fiddler has the registrationhostname property correctly set.

So I'm pretty much out of ideas and I'm seeing the same behaviour on multiple machines. I'm more inclined to think I've missed something obvious than I am to think something has changed in 8.1, any thoughts on what to try next?

One thing that I'm confused about is that the guidance I see (such as Eric's) talks about configuring Fiddler to allow remote connections but then there's nothing on setting a proxy in the emulator as you'd normally do with a physical device. I assume this is accounted for by configuring the host name in Fiddler and that it's then resolved by the emulator to route through the proxy?

Edit: Just for reference, I need the emulator as it'll be used in an upcoming Pluralsight course where I want to show both the phone behaviour and the traffic via Fiddler. I suspect the issue may be related to the fact that it's talking over a virtual NIC on the host, sound reasonable?

Answer 1

I can successfully use Windows Phone 8.1 Virtual Machines (on Windows 8.1 Update 1) with Fiddler.

Try this:

1. Run Fiddler.
2. Click Tools > Fiddler Options > Connections. Change the Fiddler Listen Port from 8888 to something else, e.g. 8889. (The Windows Phone team decided to steal port 8888 for their debugger).
3. Tick the Allow remote computers to connect box.
4. Click Ok button
5. In the QuickExec box below Fiddler's session list, type prefs set fiddler.network.proxy.RegistrationHostName 169.254.80.80 where the IP address is found at the top of the tooltip you see when hovering over the Online indicator at the top-right of Fiddler's toolbar.
6. Restart Fiddler.
7. Start VS 2013 and load your project. Click Run for the Windows Phone 8.1 emulator.
8. Open IE. When the Settings dialog box appears, choose Custom Settings. In the Data Sense savings drop down, choose Off.
9. Click Done.

Step #2 technically shouldn't be required (because their debugger is listening on loopback instead of the public IP), but it can't hurt. I'm not positive that Step #8 is required, but given that Data Sense's browser-optimization service is based on a proxy in the cloud, it certainly seems like it could interfere.

Answer 2

@EricLaw's method for getting the WP 8.1 emulator to play with Fiddler definitely works. Additional things that I had to do included:

Delete the existing WP VM from the Hyper-V manager. You can open this by either searching for it or typing this in the run command: %windir%\system32\mmc.exe "%windir%\system32\virtmgmt.msc"

This appeared to help completely clear the network settings of the VM, and when you run Visual studio the VM will be recreated.

Also if you're trying to run this on a corporate network, I've read people coming into problems when their network is running IPSec. For this you will either need to get an exception for the emulator, or use a different network -- such as a guest network.

HTH

Answer 3

I personally always use a hardware phone and set Fiddler's remote port as the proxy in the phone's Wi-Fi Settings app.

That said, it should be possible to listen to the WP81 emulator. I just haven't tried this myself. I remember having similar problems when trying to listen in on Zune traffic when a Windows Phone 7 device was connected. It turned out Zune ignored Fiddler's proxy settings, so I had to resort to some other measures. Here's the reply I got from Eric Lawrence, Fiddler's author:

For whatever reason, the 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 his extension here: http://deletethis.net/dave/wpadserverfiddlerextension/

After you install it, on the 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 Dave's 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.

Source

Maybe this will work for you.