Over on StackOverflow, a new Windows 8 user asked how to get Fiddler working with new Windows 8 Metro-style applications. These applications work somewhat differently than classic desktop applications, and require a bit of special configuration work to get Fiddler to work properly.
Fear not, however, Windows 8 and Fiddler get along just fine after a few tweaks. Many of my colleagues have been using Fiddler to debug Metro-style applications over the last few months.
There are three important Windows 8 changes that impact Fiddler:
- The .NET CLR 2.0 isn’t installed by default
- Metro-style applications require a specific Capability to communicate with the localhost (where Fiddler runs)
- Metro-style applications do not respect the per-User Trusted Root Certificates store
Each of these three issues can be worked around to restore the full functionality of Fiddler when running on Windows 8.
DotNet Runtime Version
By default, Windows 8 ships with the Common Language Runtime v4 and the .NET Framework v4.5. Fiddler, however, is currently compiled to run on the v2.0 CLR which is installed on most PCs with the .NET2.0, .NET3.0, and .NET3.5 Frameworks. When you first launch Fiddler on Windows 8, you should see a prompt to install and enable the .NET Framework version 3.5 and the v2.0 CLR:
If for some reason you cannot install the older .NET CLR & Framework (or simply don’t want to), then you can try an beta version of Fiddler targeting the version 4.0 .NET Framework & CLR. This build currently trails the v2-targeted release build by a few bugfixes and features but will be updated periodically. One day, it will likely become the default package, in the same way that the v2-targeted version of Fiddler replaced the v1.1-targeted version back in 2007.
Connecting to Fiddler requires an Application Capability or Loopback Exemption
Windows 8’s Metro-style applications run in isolated processes (AppContainers) where permissions are granted based on a capabilities model. An application only is granted the capabilities which are specified in its package manifest.
[Update 12/10/2011: Please read this post for details on a new utility which simplifies the following steps. ]
Fiddler is a proxy running on your local computer, and for a Metro-style application to send its traffic to Fiddler, the application must either declare the privateNetworkClientServer permission or a Loopback Exemption must be created. Without either of these settings, the App will not be able to connect to the Fiddler proxy running on the local computer, and thus Fiddler will not be able to see its traffic.
CheckNetIsolation LoopbackExempt allows the developer to set up Fiddler or his debugging/testing environment without modifying the capabilities assigned to the AppContainer. Generally speaking, using the CheckNetIsolation tool should be preferred to adding the privateNetworkClientServer capability, as doing so is less impactful to the behavior of the App you’re testing. There was a recent talk that describes how to use CheckNetIsolation with Fiddler-- The talk is “Debugging connected Windows 8 apps” and it’s available for viewing here. Minutes 27 to 34 talk about Fiddler, and minutes 19 to 34 discuss use of the CheckNetIsolation tool. To exempt your application’s AppContainer, open an Administrative Command Prompt, and type CheckNetIsolation LoopbackExempt –a -n=AppContainer’sFullName
You can learn more about assigning capabilities to your application by looking for the text To add capabilities to an app inside this whitepaper.
The Windows 8 Firewall blocks Modern Applications from connecting to Loopback
[Update 12/10/2011: This step should not be needed in the latest Fiddler v4 builds]
You will also need to allow loopback connections through the firewall. The simplest way to do that is to click Tools > Fiddler Options and tick the “Allow remote computers to connect” option, restarting Fiddler when complete.
To decrypt HTTPS, Fiddler’s Root Certificate must be placed in the Machine's Trusted Root store
Fiddler’s HTTPS-decryption feature relies on a man-in-the-middle approach to decrypting HTTPS traffic. Upon enabling the feature, Fiddler provides the option to copy its self-signed root certificate into your per-User Trusted store:
However, Metro-style applications will not respect any root certificates that are only installed in the per-User Trusted Root Certification Authorities store. If a Metro-style application encounters a certificate chain that doesn’t lead to the Local Machine’s Trusted Root Certification Authorities store, then the trust chain will be deemed invalid and your HTTPS request will fail.
To address this, recent versions of Fiddler include code that will offer to place the Fiddler Root Certificate into the machine-wide Trusted Root Certification Authorities store when Fiddler detects that it is running on Windows 8. After the prompts above, you’ll see the following prompts:
If you choose Yes and Yes in these prompts, then Fiddler should be able to successfully decrypt the HTTPS traffic from your Metro-style application. Note: If you want Fiddler to have the machine trust the root certificate on earlier Windows versions, set the preference named fiddler.certmaker.offermachinetrust to True.
Please let me know if you have any questions, and thank you for building on Windows 8!
-Eric Lawrence