Fiddler vs. Windows 10 Creators Update & "mobileservice:13340"

[Christopher Downing]

I have been unable to set fiddler as the system proxy ever since updating to the Windows 10 "creators update"(Version 1703, build 15063.332). All fields on the LAN settings window are blank, and it won't let me update them. I try to check "Automatically Detect Settings" on the advanced settings window, clicking "ok" does NOTHING!!! Reinstalling fiddler ALSO does NOTHING!!!!

After one cumulative update of Windows, the problem got worse: 

" 22:17:47:1692 ! WARNING: Port 8888 is already in use (for at least some IP addresses) by 'mobileservice:13340' "

Any suggestions?

[Eric Lawrence]

The first thing you can/should do is move Fiddler to a different port (Tools > Fiddler Options > Connections), as this is easy and generally doesn't cause any problems. Use something like 8876 or something.

When you say "All fields on the LAN settings window are blank", I assume you mean "While Fiddler is set to capture"? If so, is there any data when Fiddler isn't set to capture? Is there anything interesting on Fiddler's Log tab?

(I believe that many thousands of Microsoft employees use Fiddler internally, so you can take heart that I'm sure we can get this working for you again). 

[Christopher Downing]

It's empty regardless of being set to capture or not. 

Which results in THIS: 

17:43:47:2747 !WARNING: Failed to get proxy information for Connection 'DefaultLAN'.

17:43:47:2747 !WARNING: The DefaultLAN Gateway information could not be obtained.

[Eric Lawrence]

> Failed to get proxy information for Connection 'DefaultLAN'.

This indicates that the WinINET API call is failing, which suggests that there's either a bug in Windows, or a problem with your particular system's configuration (e.g. an ACL is incorrect on a registry key) that is breaking the API.

If you run Fiddler as an Administrator, is there any change?

[Christopher Downing]

Same problem..... Running as an admin doesn't help

[Christopher Downing]

Update: the latest windows 10 update fixes the mobileservice:13340 problem, but the same WinINET API issue is happening. Is there a fix?

[Eric Lawrence]

The fix would have to come from either Microsoft, or manual repair after diagnosis on your machine (e.g. using ProcMon to watch registry key changes to see if any of them fail due to ACL problems).

If it's helpful, both Firefox and Chrome allow you to specify your proxy settings independently of the system settings. In Firefox, this is in the settings UI, while in Chrome you use a command-line argument:

   chrome --proxy-server=http://127.0.0.1:8888

[Christopher Downing]

Latest Windows update doesn't fix the problem, here is a post from someone in the Telerik forms

"I'm having the same problem. This seems to be a problem with other developer machines where I am that have installed the Windows 10 Creator's Update (1703). I think the problem with Fiddler is a symptom and not a cause of the issue of not being able to click the OK button on the Internet Options dialog for the proxy settings. It sounds like Fiddler is just unable to change those settings for some reason or maybe Microsoft just doesn't like our first name. I will reply back to this if I find a solution."

also I'm quite a noob using the chrome dev-tools console, especially since I'm on chrome ver. 59.0.3071.115.

Don't think the latest version of Firefox supports fiddlerhook

[EricLaw]

Config problems like this are rarely fixed by Windows update, sadly.

You don't need FiddlerHook. Simply set Firefox proxy settings to point directly at 127.0.0.1:8888.

[EricLaw]

To be clear, the Chrome instructions have nothing to do with the Chrome dev tools. You simply launch Chrome with that command line to set its proxy settings to point at Fiddler.

[Christopher Downing]

Ok, now how do i get the secure HHTPS traffic going on it? I already have the fiddler certificate installed.

[EricLaw]

In Firefox, you set the SSL Proxy setting to the same value (127.0.0.1:8888). Note that you must install Fiddler's certificate into Firefox specifically (it doesn't trust Windows' certificates).

In Chrome, the command line provided earlier proxies both HTTP and HTTPS.