Troubleshoot Common Issues with Always On Tracing

Always On Tracing (AOT) captures logs continuously across all Citrix components — VDAs, Delivery Controllers, StoreFront™, License Server, and Citrix Workspace App. When a problem is reported, the data is already there. This article shows how to use the Logs node in Citrix Director or Monitor to identify the cause of an issue and how to export logs from Director or Monitor for submission to Citrix Technical Support.

Note:

Before you start — collect this for every scenario

• Affected user or machine — a specific username, VDA hostname, or delivery group name
• Time of failure — even an approximate window helps narrow the default time filter. Adjust the time range to cover the period before the reported failure.
• Scope — one user, one machine, or environment-wide? Scope alone often points to the correct failure pattern before you open a log
• Recent changes — any CVAD updates, Group Policy changes, power management changes, or network changes in the relevant window

When to Use AOT for Customer-Reported Issues

AOT is designed to help with a broad range of customer-reported issues. The following are some of the most commonly reported issue types where AOT logs can be sufficient to either isolate or find the root cause. This list does not cover every possible issue — there are many other issue types where AOT logs can also help. Most of these issues can definitely be isolated with AOT logs — you can identify the component at fault or sometimes find the root cause as well. You don’t always need to escalate or collect additional traces for the issue types below, unless otherwise requested by a support engineer.

• StoreFront login failure
• CWA store adding failure
• Resource enumeration failure or slowness
• ICA® session launch failure
• Post-launch session slowness
• MCS provisioning failure
• Citrix policy applying failure
• User profile load/unload failure or slowness
• Power action failure or delay
• Clipboard mapping failure
• FAS authentication failure
• Citrix Director data retrieval failure
• Session not being recorded

The Logs node in Director and Monitor

The Logs node is available in both Citrix Director (on-premises CVAD) and Citrix Monitor (DaaS). To access it, select Logs from the left navigation panel. The interface is the same in both environments.

Filter bar

The filter bar has four filters and a separate Apply button. Set the filters first, then click Apply to refresh the log view. The current log count appears below the filter bar — for example, 850 Logs | Batch 1. Use the batch navigation arrows to page through large result sets.

Log table — columns

The log table shows five columns by default for each entry. New columns can be added by clicking the Column button. Click the > expand arrow on any row to see the full log message and additional fields.

Exporting logs for Citrix Technical Support

The export icon appears at the top right of the Logs section. Use it to download the current filtered log view as a file. Before exporting:

Note:

Version availability: The export icon is available on DaaS from the Cloud 129 (April–May 2026) release and later, and on Citrix Virtual Apps and Desktops from CVAD 2603 and later. The option is not available on earlier versions. Note:

AuthKey required: The Logs node only shows data if the AuthKey is configured in Director or Monitor settings. The AuthKey is generated during Log Server setup. Without it, the Logs node shows no entries.

Scenario 1: Session launch failure

A user clicks a published desktop or application and gets a launch error. The session never opens. The error may appear on the Citrix Workspace App screen or the progress bar stalls and times out with no session connecting.

In the Logs node, set Category to Application Launch, Log Level to Error, and adjust Time to cover the failure window. Click Apply. Sort by Time (UTC) ascending and read the Message and Host Type columns together — they show which component in the launch path failed and what it reported.

Note:

The log messages below are illustrative examples. Actual messages in your environment follow the same format and column structure but may differ in exact wording.

Example: No VDA available in the delivery group

The DDC received the launch request but could not assign a desktop. All VDAs in the delivery group were unregistered or at session capacity.

The Error from DDC tells you the broker could not find an available VDA. Check VDA registration in Web Studio → Search Machines. See Scenario 2 for VDA registration troubleshooting.

Example: VDA assigned but session initialization failed

The DDC assigned a VDA but the VDA could not start the session. Common causes: FSLogix or roaming profile container failure, Group Policy processing error, or VDA resource exhaustion.

The Error from Host Type WVDA identifies the VDA as the failure point and the Message shows the exact cause. Click the > expand arrow on that row to read the full message, which includes the full profile container path and error code.

Example: Virtual channel error during CWA post-launch

The session was created on the VDA side but the CWA client could not establish the ICA virtual channel connection. Filter Host Name to the CWA machine to see client-side errors.

Host Type CWAWindows with a CWA-POSTLAUNCH error means the VDA was ready but the ICA data path between client and VDA was blocked. Verify ports 1494 and 2598 are open from the client machine to the VDA.

Scenario 2: VDA registration failure

VDAs show as Unregistered in Director or Web Studio → Search Machines. Users see “No desktops are available to you at this time.” Published desktops appear greyed out in StoreFront or Citrix Workspace.

In the Logs node, set Category to VDA registration, Log Level to Error, and set Host Name to both the affected VDA and the DDC. Click Apply. Reading both sides of the registration handshake together — the VDA row and the DDC row at the same timestamp — shows exactly where the failure occurred.

Note:

The log messages below are illustrative examples. Actual messages in your environment follow the same format and column structure but may differ in exact wording.

Example: VDA cannot reach the Delivery Controller

The VDA is attempting to register but the DDC never receives the request. Only VDA-side errors appear — no matching DDC rows at the same timestamps.

The same error repeating at a fixed interval is a retry loop — the VDA is alive but blocked. Verify ports 80 and 443 are open from the VDA to the DDC, and check the ListOfDDCs registry key on the VDA for stale or incorrect DDC addresses.

Example: DDC rejects the registration request

The VDA reached the DDC but the DDC refused to register it. Both VDA and DDC rows appear — read the DDC Message for the rejection reason.

The Error row comes from Host Type DDC — the DDC is the failure point, not the VDA. Click the > expand arrow on the DDC row to read the full rejection reason. Common reasons: disabled machine account in Active Directory, VDA/DDC version mismatch, or license pool exhaustion.

Example: VDA registers then immediately deregisters

Registration succeeds but the DDC initiates deregistration within seconds. This repeats in a loop. A power management drain policy is shutting the VDA down before it can accept sessions.

The 14-second gap between registration and deregistration is the tell. Check Web Studio → Delivery Group → Power Management for a drain or shutdown schedule that is applying during business hours.

Warning:

The scenarios in this article are examples of how to search and investigate logs in Citrix Director or Monitor. The same methodology applies to any Citrix-related issue you encounter — session failures, authentication errors, connectivity problems, VDA instability, or any other component-level issue. Set the right Category, Log Level, and Host Name filters, read the log sequence in Time (UTC) order, and expand individual rows to read the full Message. The component that logged the first error and what the Message says will point you to the root cause — regardless of the scenario. Tip:

DaaS customers with Citrix Aidrien access: Copy the error message from the AOT log and paste it directly into Citrix Aidrien. Aidrien will explain the error and provide recommended troubleshooting steps. This may not resolve every issue on its own, but it will narrow down the root cause and in many cases guide you to a fix — before you need to contact Citrix Technical Support.

Escalating to Citrix Technical Support

If self-service investigation does not resolve the issue, include the following when opening a support ticket:

• Exported log file covering the failure window — use the export icon. You can export in two ways:
  • Targeted export — apply Time, Category, and Host Name filters, then export. This gives Support a focused log set scoped to the failure.
  • Broad export — apply only the Time filter and export without any other filters. This gives Support the full log picture for the failure window and is useful when the scope is unclear.

  When the file downloads, the filename is prefixed with AOT. Do not remove or rename this prefix. You can edit the portion of the filename that follows — but always retain AOT at the beginning.

• The failure pattern identified from the sections above
• CVAD version, component versions (VDA, DDC, StoreFront), and Log Server version
• The transaction ID or session ID of the failed event — searchable in the Logs node search bar

Because AOT captures logs continuously and every entry includes Host Name, Host Type, and timestamp, Citrix Technical Support can begin analysis immediately without asking you to reproduce the issue or collect new traces.