If you’d instead prefer to send all of your web traffic via TOR, you can simply set the X-OverrideGateway flag unconditionally for each Session.
VPNs, Modems, and Tethering
When you establish a VPN, 3G tethering, or dial-up modem connection in Windows, WinINET will use that connec-tion’s proxy settings for all requests. To ensure that such traffic is captured by Fiddler, ensure that the Monitor all connections box is checked inside Tools > Fiddler Options > Connections.
Some uncommon network software products operate outside of the WinINET layer. When connected using such software, your web traffic may not be visible to Fiddler because it is being captured and routed using mechanisms beyond WinINET’s control.
DirectAccess
Recent versions of Windows support a technology known as DirectAccess (http://technet.microsoft.com/en-us/network/dd420463) that permits remote access to a corporate network without establishing a VPN. DirectAccess is integrated into WinINET so that requests which flow over DirectAccess are never sent to the system default proxy.
Unfortunately, this behavior means that Fiddler cannot observe traffic when DirectAccess is in use.
It appears that individual DirectAccess configuration entries can be updated in the registry to specify a per-target proxy server, but debugging via this mechanism would prove very cumbersome. Instead, when using Fiddler in such an environment, engineers typically use Remote Desktop to access a desktop PC running inside the corporate network, then run Fiddler and the client application on that PC.
92 | Configuring Fiddler and Clients
M E M O R Y U S A G E A N D F I D D L E R ’ S B I T N E S S
Fiddler stores the entire request and response in memory; this means that Fiddler can use large amounts of memory (RAM) while it is running. The Operating System’s memory manager is designed to manage the use of memory by applications and ensures that even if Fiddler is using a large amount of memory, rarely-accessed objects are swapped out of system RAM into the disk-based pagefile.
However, even with lots of RAM and disk space, Fiddler may occasionally show a warning message:
Exception of type 'System.OutOfMemoryException' was thrown.
at System.IO.MemoryStream.set_Capacity(Int32 value) at System.IO.MemoryStream.EnsureCapacity(Int32 value)
at System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count) at Fiddler.Session.Execute(Object objThreadstate)
This message is somewhat misleading because the system isn’t really out of memory—instead, this means that the memory manager could not find a contiguous block of address space large enough to store the request or response.
This problem most often occurs when downloading large files (e.g. a video over a hundred megabytes in size). No matter how much RAM you have, a 32bit process is limited to an address space of 2 gigabytes in size. Each object in that address space can cause “fragmentation” that could prevent storage of large objects by splitting available memory into chunks that are too small to store an entire response within one contiguous block.
On a 32bit computer, if you have thousands of sessions in Fiddler’s Web Sessions list, fragmentation can prevent a response as small as a few megabytes from being stored. You can reduce the incidence of this problem by clearing Fiddler’s Web Sessions list periodically. Alternatively, use the Keep Only box on the toolbar to automatically trim the Web Sessions list to a fixed number of sessions to free up space.
Out-of-memory errors are rarely encountered when Fiddler runs on a 64bit version of Windows because the 64bit address space is so large that you cannot possibly fill it or fragment it enough to prevent storage of even giant sessions. However, even on 64bit computers, each individual request and response is limited to 2 gigabytes due to an underlying limit within the .NET Framework.
On a 32-bit machine, you can help avoid out-of-memory errors when downloading huge files by adding the follow-ing code to your FiddlerScript inside the OnPeekAtResponseHeaders function. This snippet will cause files larger than 5 megabytes to stream to the client and Fiddler will not keep a copy:
93 | Configuring Fiddler and Clients // This block enables streaming for files larger than 5mb
if (oSession.oResponse.headers.Exists("Content-Length")) {
var sLen = oSession.oResponse["Content-Length"];
if (!isNaN(sLen)) {
var iLen = parseInt(sLen);
if (iLen > 5000000) {
oSession.bBufferResponse = false;
oSession["ui-color"] = "yellow";
oSession["log-drop-response-body"] = "save memory";
} } }
If you're building on FiddlerCore or writing a Fiddler Extension, you can use similar logic:
FiddlerApplication.ResponseHeadersAvailable += delegate(Fiddler.Session oS) {
// This block enables streaming for files larger than 5mb if (oS.oResponse.headers.Exists("Content-Length"))
{
int iLen = 0;
if (int.TryParse(oS.oResponse["Content-Length"], out iLen)) {
By default, Fiddler will always run in 64bit mode when running on a 64bit version of Windows. In rare instances, you may prefer to run Fiddler in 32bit mode. For instance, you must run in 32bit mode when you’re using an extension that requires native binaries that are only available as 32bit modules (e.g. Silverlight 4) or your Fiddler-Script depends upon other modules unavailable in 64bit. For example, the Microsoft.Jet.OLEDB.4.0 database provider used to write to Microsoft Access .MDB database files is not available in 64bit mode. To force Fiddler to run in 32bit mode on 64bit Windows, use the ForceCPU.exe tool located in the Fiddler installation folder.
94 | Configuring Fiddler and Clients
B U F F E R I N G V S . S T R E A M I N G T R A F F I C
In order to enable modification of requests and responses, Fiddler is configured to completely buffer request and response messages before passing them along to their destinations.