Troubleshooting Workflows

The ET Ducky Diagnostic Method

  1. Identify: What system? What problem? When?
  2. Prepare: Enable relevant ETW providers via Remote Configuration
  3. Capture: Start a Live Session (ETW starts automatically)
  4. Reproduce: Trigger the issue while ETW is collecting
  5. Query: Ask AI specific, targeted questions
  6. Analyze: Review root cause and recommendations
  7. Remediate: Apply fixes via Shell tab or manually
  8. Verify: Confirm resolution
  9. Monitor: Set up alert rules to detect recurrence

Common Scenarios

Application Not Starting

Live Session → Attempt to start app → Ask “Why did [app] fail to start?” → AI analyzes Process, File I/O, Registry events.

Performance Degradation

Check health metrics → Live Session → “What is causing high CPU?” → Use Shell tab to terminate problematic processes.

Service Start Failures

Live Session → Start service → “Why did [service] fail to start?” → AI analyzes dependencies and errors.

Multi-System Issues

Multi-Agent Session → Select all affected agents → “Trace this request through all tiers” → Run Correlation.

Support Bundle

Agent 2.8.5.2 and later can collect a support bundle on the host: a zip of the agent's configuration with credentials removed, its recent logs, buffer and state summaries, and environment details. Nothing in it is sent anywhere; you decide whether to share it.

Collecting it

  • Windows: from an elevated (Administrator) command prompt, run "C:\Program Files\ETDucky\Agent\ETDucky.Agent.exe" --diag.
  • Linux: run sudo -u etducky etducky-agent --diag. It runs as the agent's own user and refuses to run as root.

The command prints where the zip was written: the agent's diag folder (C:\ProgramData\ETDucky\Agent\diag on Windows, /var/lib/etducky/diag on Linux), which only administrators (Windows) or the agent's user (Linux) can read. The three newest bundles are kept. Options: --out <folder> also copies the zip there, --no-logs leaves the logs out, --log-mb <1-25> sets how much of each log is included (default 5 MB), and --include-commands keeps the text of shell commands, which is left out by default.

What it contains and what it leaves out

  • The configuration with the agent's identity and credential keys removed and every other text value under a secret-sounding name replaced; on and off settings and numbers under such names are kept (agent 2.8.5.3 or later). The original file is never copied.
  • The agent's audit log first, then the three newest agent logs, each cut to its newest part. The bundle is at most 25 MB.
  • Counts from the local event buffer (no event contents), the list of state files, and the rule engine's hourly statistics, including how many firings each rule held back.
  • Every text line passes a redactor that removes tokens, authorization headers, organization keys, private key blocks, signed URLs and passwords, account SIDs, user names in profile paths, and public IP addresses (last part kept). MANIFEST.json lists every file with its SHA-256, what the redactor removed, and what it does not look for.

Review the zip before sharing it. The redactor removes the patterns it knows; it cannot recognize every secret. Collecting a bundle from the dashboard is not available yet.

Automated Troubleshooting

For ticket-driven or described-issue workflows, use the Automated Troubleshooting tab instead of opening a live session manually. ETW collection starts and stops automatically with the session.

  1. Start from the Agents page: Click an agent to open its details modal, then click Run Troubleshooting. The live session opens to the Automated Troubleshooting tab.
    Or start from the Tickets page: Click Start live session next to any ticket. The session opens directly to Automated Troubleshooting with that ticket already selected.
  2. Optionally select a ticket from the dropdown. When a ticket is selected, a preview panel shows the title, status, assignee, and full description. You can also create a new native ET Ducky ticket using Open support ticket, or leave “No ticket” and describe the issue in the text area.
  3. Click Analyze & Suggest Actions. The AI proposes one diagnostic action at a time; approve (optionally editing the command), skip, or stop at each step. A command runs without an approval card only when ET Ducky's read-only check proves it reads state, such as a process or service listing, a registry value, or a log file in an allowed log folder; every other command waits for your approval. Registry keys that hold stored secrets are the exception and wait for approval (see Registry reads below). Commands that read credential or key files, weaken Microsoft Defender, or match another blocked pattern are refused before either step. The log shows such a step as not run, with the reason and what to do instead.
  4. When the job completes, review the summary. If the run was linked to a ticket (integration or native ET Ducky), the result panel shows a ticket selector (pre-set to the linked ticket) and a status dropdown. Select a new status if appropriate, then click Apply to ticket to push the summary as a note and update the status in one action.

A configured Jira or ServiceNow integration is required only for selecting and pushing to integration tickets. Native ET Ducky tickets and “Describe issue” work without any ticketing integration. See Ticketing Integrations for connector setup and field mapping.

Download Transcript

The result screen includes a Download transcript button that saves a plain-text file (troubleshooting-<jobId>.txt) containing every command the run executed and its full output, plus the proposed-action rationale and the final summary. The summary is deliberately short; the transcript is the raw session evidence when you need to verify a finding, attach proof to a ticket, or see exactly what a command returned.

The button works for completed and failed runs alike — a failed run's transcript contains everything answered up to the failure point, which is usually the fastest way to see where it went wrong.

How a Run Works

What the assistant starts from

When a run starts, ET Ducky gives the assistant the host's current state: health now and over the last 24 hours, posture (domain membership, antivirus, firewall, free space on the system drive, operating system), hardware, up to five unacknowledged behavioral detections from the last 7 days, up to five metric inflections from the last 24 hours, the last three completed runs on the same host, and applications in your inventory that match the issue description. A section that cannot be read is marked unavailable rather than left out.

The assistant also receives earlier completed runs from your organization on the same issue as hints, preferring runs on the same host. Only runs whose fix verified, or that someone rated Helpful, are used. Runs from other organizations are never used.

Recent events on the host are given to the assistant as grouped, counted lines, most severe first, each with a reference such as [evt:1234] that the assistant can cite in its reasoning. Where the agent reported them, the file, registry key, command line and network addresses from those events are included. An event's command line is stored once, with passwords, tokens, secrets, API keys and authorization headers masked before it is stored.

Registry reads

Registry reads (Get-ItemProperty, Get-ItemPropertyValue and reg query) run without an approval card. Reads of keys that hold stored secrets wait for approval: Winlogon auto-logon, LSA secrets, saved PuTTY and WinSCP sessions, VNC and TeamViewer stored passwords, and SNMP community strings. A listing read (Get-ChildItem, -Recurse, /s or a wildcard) of one of those keys or a key above it also waits for approval, because it prints their values.

Step limit

A run makes at most 25 planner calls. A planner call is one decision by the AI about the next step; retries and refused proposals count. When a run reaches the limit, the log shows “Step limit reached (25 planner calls). Moving to summary.” and the run ends with its summary.

Fix verification

When the run proposes a fix and you approve it, the assistant then repeats the last read-only diagnostic command that ran without approval in the same run and decides whether the fix worked. Only that read-only check is repeated, never the fix. The check is classified and screened again before it runs. The log shows the outcome as verified, not verified, or inconclusive with the reason, for example when no read-only diagnostic ran earlier in the run or the agent did not answer within 3 minutes.

Interrupted and timed-out runs

A run that stops because the server restarted ends with “Troubleshooting was interrupted (server restart).” A run that makes no progress for 35 minutes ends with “Troubleshooting timed out.” Neither stays in a running state. Continue troubleshooting stays available on both results: it returns to the start form with the ticket and description kept, and Analyze & Suggest Actions starts a new run.

Approve, edit, skip and stop decisions are saved with the run on the server, so a decision is not lost if it arrives while the run is between steps.

Rating a run

The result screen asks Was this run useful? with Helpful and Not helpful. The rating is stored against the run, without the run's text. Ratings feed the AI Result Quality summary described in AI Diagnostics, and a Helpful rating lets later runs in your organization use this run as a hint.

Usage

Each AI call a run makes is recorded under its own usage type in the AI usage breakdown. See AI Usage & Quotas.