Skip to main content

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

Article # 3031306 - Page views: 130


Question / Problem: 

Normally Fiddler traces request between the browser and the web server.  How can it be used to trace requests from the KTA web server or Core Worker to elsewhere?

Answer / Solution: 

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, either change the service or application pool to run as the logged in user, or login to Windows as the user under which they are already running.  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 (which may be on the same 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 (which may be on the same system if it is a combined web/app server)
  • 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" />

Applies to:  

Product Version


  • Was this article helpful?