Skip to main content

Use Fiddler to Trace Requests From KTA Web Server or Core Worker

Article # 3031306 - Page views: 261


Normally Fiddler traces requests between the browser and the web server, but it can also be used to trace requests from the KTA web server or Core Worker to elsewhere.


Fiddler works by setting itself as a proxy for the current Windows user, so by default a Fiddler trace only captures traffic from applications that are running as the same user.  Most importantly this means that traffic from Windows services or IIS application pools that are running as different users will not be captured by a Fiddler trace by default.

To be able to capture traffic from these sources, do one of the following:

  • Login to Windows as the user under which is running the service or app pool that you want to trace and run the trace there.
  • Change the service or app pool to run as the logged in user and then trace.
  • By default Fiddler installs in a user specific directory, but if you install in a non-user specific directory, then another option is to Shift + Right click on the Fiddler.exe and choose “Run as different user.”

Note that all of the normal details of taking a Fiddler trace still apply, such as enabling the option to decrypt HTTPS and trust the Fiddler certificate in order to be able to trace HTTPS traffic.

Examples of data to capture

TotalAgility Core Worker

Capturing traffic from the TotalAgility Core Worker service can be used to troubleshoot traffic such as the following:

  • API calls to the app server core services (when on a different system)
  • Web Service activities calling external web services
  • Activities that integrate with other products, such as RPA/Kapow activities

TotalAgility IIS Application Pool

Capturing traffic from the KTA application pool on the web server would similarly be used to troubleshoot traffic such as the following:

  • API calls to the app server core services (when on a different system)
  • Web Service form actions calling external web services
  • Form actions or product functionality that integrate with other products, such as RPA/Kapow actions, or integration with Insight

Alternative to changing users

As an alternative to changing users, you can specify fiddler as a proxy in the relevant config file.  This is generally not practical, because it requires the following sequence of events:

  • Start running fiddler
  • Change relevant config files to point to the running instance of Fiddler as the proxy
  • Restart relevant processes so the config files take effect and start sending traffic through Fiddler
  • At this point Fiddler must stay running these processes to work
  • Reproduce the issue where traffic needs to be captured
  • Change the config files back, restart relevant processes, and stop Fiddler.

In a situation where this sequence is preferable to changing users, the following needs to be added to the relevant config file (web.config for web server, Agility.Server.Core.WorkerService.exe.config for Core Worker, etc) under <configuration>.  If a section already exists in the config file, merge the content of the two.

<!-- The following section is to force use of Fiddler for all applications, including those running in service accounts --> 
  <proxy autoDetect="false" bypassonlocal="false" proxyaddress="" usesystemdefault="false" />

See Also:


Level of Complexity 



Applies to  

Product Version Build Environment Hardware
KTA All      


Article # 3031306
  • Was this article helpful?