Using AI to Automate Windows Root Cause Analysis

Root cause analysis in Windows environments has historically been a manual process. An alert fires, an administrator opens Task Manager, Event Viewer, or Resource Monitor. A single performance incident can involve tens of thousands of kernel events spanning disk I/O, memory allocation, network activity, and process scheduling.

Event Tracing for Windows (ETW) emits the underlying telemetry. This post describes a two-stage pipeline that combines on-host event correlation with LLM-based interpretation of the correlated output.

Pipeline

Raw ETW data is too large to send to an LLM directly. A single incident may include 50,000 events. The pipeline reduces volume on the host before model invocation.

Stage 1: on-host correlation. An agent subscribes to ETW providers, detects patterns (CPU spikes, disk latency increases, memory pressure transitions), and extracts the events surrounding the pattern. The output is typically 30 to 50 events per incident.

Stage 2: model invocation. The correlated summary (5 to 20 KB of structured data) is sent to an LLM. The model returns a description of the observed sequence, a hypothesis for the cause, and a list of possible remediation actions.

Example output

Trigger: alert "CPU exceeded 95% on APPSERVER-07 for 3 minutes."

Correlated events extracted by the on-host stage:

• Process w3wp.exe (PID 4820) CPU rose from 12% to 97% at 14:23:41
• 47 new threads created in the w3wp process between 14:23:38 and 14:23:45
• Disk read I/O on E:\inetpub\wwwroot\app\bin\LargeAssembly.dll reached 340 MB/s
• .NET CLR JIT compilation events for 2,847 methods in rapid succession
• IIS request queue depth rose from 2 to 89 in 8 seconds
• Application pool recycle event at 14:23:38 (reason: scheduled recycle)

Model output for the above input:

Root Cause: Scheduled IIS Application Pool recycle caused cold-start performance degradation.

The application pool for DefaultAppPool performed a scheduled recycle at 14:23:38. The new worker process JIT-compiled 2,847 .NET methods on first request, producing sustained CPU usage while servicing incoming requests. The 340 MB/s disk read burst was the CLR loading assemblies from disk. Request queue depth rose because the worker process could not service requests during JIT compilation.

Recommended Fix: Enable .NET ReadyToRun (R2R) compilation or NGen pre-compilation to remove cold-start JIT overhead. Alternatively, configure application pool recycling during off-peak hours and enable overlapping recycling so the existing worker continues servicing requests until the new one is warm.

Comparison to threshold rules

Threshold-based monitoring fires on a single metric crossing a value, such as CPU above 90% for 5 minutes, disk latency above 100ms, or memory above 85%. Threshold rules report symptoms.

Combination rules can cover specific failure modes ("if CPU > 90% AND w3wp.exe is the top process AND an app pool recycle happened in the last 60 seconds, then cold-start"). The set of such rules required to cover the failure modes encountered in a Windows environment is large, and the rules require ongoing maintenance as software changes.

An LLM produces output based on the correlated events presented in the prompt. The output describes the sequence of events and a hypothesized cause without requiring a pre-written rule for that specific combination.

Data sent to the model

The correlated summary contains event types, timing, resource measurements, and process names. It does not contain file contents, user data, network payloads, or credentials.

Provider data-handling terms vary. Anthropic states that API inputs to Claude are not used for model training and are not retained beyond the request lifecycle.

Limitations

Hardware failures. ETW emits symptoms of hardware issues (retried I/O, corrected ECC errors). The model may attribute these symptoms to software causes without explicit hardware context in the prompt.

Multi-system causes. If the cause spans multiple machines (a database server causing application server timeouts), per-host ETW analysis sees only the local side. Multi-host correlation is a separate problem.

Novel failure modes. Model output is based on patterns in training data. Unusual interactions or new driver bugs may produce a plausible but incorrect explanation. The correlated events remain available for manual investigation.

Configuration drift. The model analyzes what happened. If a registry setting or group policy is misconfigured, the model sees the behavioral impact but may not identify the configuration as the cause without additional context in the prompt.

Linux parity

The same pipeline applies on Linux with eBPF as the capture mechanism. eBPF programs at process exec, file open, network connect, and accept emit the input to the on-host correlation stage. The structured output is in the same format and is consumed by the model in the same way.