/alibabacloud-ecs-windows-os-troubleshooting

name: alibabacloud-ecs-windows-os-troubleshooting
description: >
    Troubleshoot and repair Alibaba Cloud ECS Windows instances from inside
    the GuestOS or remotely via Cloud Assistant. Use whenever the user reports
    any Windows symptom or asks for a health check on an ECS Windows instance,
    even vague ones like "check this machine":
    boot failures (BSOD, black screen, boot loop, stuck at logo), crashes and
    hangs, RDP/VNC login failures, network problems (internet access, ping,
    DNS, DHCP, firewall, SMB), a port unreachable from outside
    while the service is running (8080, 3389), inbound firewall port
    blocking, disk and storage, Windows activation, Windows Update, time
    synchronization, user accounts and permissions, BitLocker, drivers,
    application crashes, certificates and TLS, scheduled tasks, slow
    performance, configuration not taking effect, Cloud Assistant and
    management channel issues. Supports online diagnosis (running system) and
    offline diagnosis (faulty system disk mounted as a data disk) via a
    direct in-GuestOS channel or remote aliyun ecs run-command.
license: Apache-2.0
compatibility: >
    Target must be an Alibaba Cloud ECS Windows instance with PowerShell 5.1+.
    Remote execution: Alibaba Cloud CLI (aliyun) v3.4.11+ with the
    aliyun-cli-ecs plugin installed and configured, network access to the ECS
    OpenAPI endpoints, and the Cloud Assistant agent (AliyunService) running
    on the target instance. Direct execution: runs inside the GuestOS,
    no external tools required. Offline diagnosis additionally requires the
    faulty system disk mounted as a data disk on the diagnosing instance.
metadata:
  author: alibabacloud
  version: "1.0"
  domain: aiops

ECS Windows Troubleshooting

This skill performs anomaly troubleshooting and diagnosis for **Alibaba Cloud ECS Windows instances** (online 7 problem domain groups and offline problem domain routing are defined in [WORKFLOW-GUIDE.md](references/online/WORKFLOW-GUIDE.md) and [WORKFLOW-GUIDE.md](references/offline/WORKFLOW-GUIDE.md) respectively). It supports two diagnostic modes:

• **Online Diagnosis**: The current Windows system is running. Troubleshoot layer by layer inside the GuestOS using PowerShell commands.
• **Offline Diagnosis**: The faulty system disk has been mounted as a data disk on the current instance. Perform root cause analysis and fix on the mounted offline system disk.

This file only defines **functional description and top-level flow**. The specific troubleshooting logic, criteria, and fix scripts are all defined in the corresponding files under `references/`. When executing, you MUST load the corresponding file and strictly follow its content--relying on memory will miss root causes or produce incorrect fixes.

Out of Scope

• Non-Alibaba Cloud ECS, non-Windows GuestOS, other clouds or physical machines
• Pure management/billing/API-side issues with no GuestOS involvement
• When no channel (online or offline) is available to perform troubleshooting inside the target instance

Principles and Requirements

1. **Collection result reuse**: Prioritize reusing command collection results already executed within the session. Except when truly necessary (e.g., time window change, need for latest state, previous execution failed), it is prohibited to repeatedly execute the same collection command with the same parameters. 2. **Classify before investigate**: First converge the user's description into a **problem domain** (pattern determination is described in "Phase 2" below; classification and sequence determination is executed in the "Path Planning" step after entering the corresponding mode's WORKFLOW-GUIDE), then execute according to the unified troubleshooting sequence for that domain. You must not skip classification and proceed with free-form troubleshooting. 3. **Self-service troubleshooting priority**: Any information that can be obtained through PowerShell commands in the target environment MUST be collected directly; users must not be asked to execute manually. Only when the command execution channel cannot cover should you ask the user, and the query MUST include a complete copyable collection command. This principle covers **passive collection only**; operations that modify system state (enabling debug/tracing channels, changing configuration, assigning drive letters or access paths, changing disk/partition attributes) are governed by the confirmation gate in principle 6 and the specific gates in domain files, even when the execution channel could run them directly. 4. **Collection rules loaded by mode**: Collection channel rules and tool invocation rules are mode-specific details. After entering the corresponding mode, load the relevant rule files according to the "Collection Channel Rules" and "Collection Fallback Chain" sections of its WORKFLOW-GUIDE. 5. **Mode routing must not be skipped**: Before entering any troubleshooting action, you MUST first complete "Diagnostic Mode Determination" (online/offline). The two modes operate on different objects (online operates on the current running system, offline operates on the mounted offline system disk), and the loaded rule files and fix methods are also different. Mixing rules will produce invalid or even dangerous operations. 6. **Fix requires confirmation**: Any fix operation MUST present the complete plan and risk notes, and wait for the user's explicit confirmation before execution. Automatic execution of fix commands is prohibited. After presenting the plan, END the current turn -- execution may start only after the user's explicit confirmation reply in a later turn; presenting the plan and executing the fix in the same turn is prohibited. The user's original request to "fix/repair/troubleshoot and fix" -- no matter how explicit or emphatic -- is NOT confirmation: it asks for a diagnosis and precedes any plan, so it cannot approve a plan the user has not yet seen. Confirmat