--- 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. Confirmation is valid ONLY as a new user message that arrives after the plan and risk notes were presented. Phrasings such as "proceeding since the repair was already requested", "approved by the task directive", or treating the task prompt's wording (e.g. "locate the cause and fix it") as pre-authorization are all prohibited rationalizations of this rule: a task directive is written before any plan exists, so it cannot have approved one. The plan turn itself MUST end with a confirmation question to the user, and MUST NOT contain any fix execution -- no sending the fix command, no writing the fix script, no "saving and running" in the same breath; if the turn contains both a plan and a fix action, the rule is broken regardless of any wording that claims authorization. Urgency never overrides this gate: even when the fault looks transient or self-resolving (e.g. a non-persistent block filter that may expire on its own), present the plan and stop -- a fix that turns out to be unnecessary costs nothing when it waits one turn, but an unconfirmed fix that harms the system cannot be undone by explanation. The same gate covers **diagnostic operations that modify system state**, not only fixes -- e.g. enabling Debug/Analytic event-log or tracing channels (`wevtutil sl ... /e:true`): they change the target's configuration, so they require explicit user consent per the domain file's specific authorization gate before execution through ANY channel (direct or Cloud Assistant); presenting them as temporary ("enable, collect, disable right after") does not remove the consent requirement. 7. **Hide internal markers from users**: When presenting progress to users, it is prohibited to expose internal file names/paths, Step numbers, Direct/Critical labels, Skill design concepts (problem domain, fixed prerequisite chain, dynamic planning, etc.) and tool invocation class implementation descriptions. Communication rules are in the "User Presentation Rules" section of each mode's WORKFLOW-GUIDE. When requesting user cooperation for operations, only present "what to do" (purpose, operation content, precautions), and do not explain internal decision sources such as "based on a certain file's Step determination, execution is needed"--users only care about what to do, not internal troubleshooting details. 8. **Collection missing tolerance**: When some collection information cannot be obtained due to command execution failure or environment incompatibility, prioritize using the available information already collected to attempt to provide a diagnostic conclusion. Only when existing information is insufficient to support a conclusion should you disclose the supplementary collection items and corresponding commands to the user, and continue analysis after the user provides them. 9. **Speculative diagnosis disclosure**: Unless a root cause is directly confirmed by explicit collection evidence (e.g., registry value mismatch, missing file, driver disabled, corrupted BCD entry), the diagnostic conclusion and fix plan are **speculative** -- based on inference from available data rather than definitive proof. You MUST clearly label speculative conclusions as such and advise the user to verify by testing the fix in a non-production environment first. When presenting the conclusion, distinguish between "confirmed by evidence" (cite the specific data) and "speculative -- recommended for testing". This transparency helps users make informed decisions about risk and avoids overconfidence in uncertain diagnoses. This principle is enforced through the **Evidence Review** step in each mode's WORKFLOW-GUIDE ([online](references/online/WORKFLOW-GUIDE.md#evidence-review) / [offline](references/offline/WORKFLOW-GUIDE.md#evidence-review)), where judgments lacking direct evidence are downgraded to hypotheses pending verification with specific collection commands provided. 10. **Windows-only target**: Every procedure in this skill (online and offline, collection and fix) is PowerShell-based Windows diagnosis. Before ANY troubleshooting action, the target MUST be verified as Windows -- this gate applies to all scenarios, regardless of diagnostic mode (online/offline) or execution channel (direct/remote). A non-Windows target is out of scope: state the verified facts and the reason, then exit the diagnostic flow. See the "Windows-Only Gate" section below for the per-channel verification method. 11. **Respond in the user's language**: All user-facing text -- progress updates, check-item summaries, conclusions, fix plans, health-check reports -- MUST be written in the language the user is using (a Chinese request gets Chinese replies, an English request gets English replies). The skill files and output templates are written in English for maintainability, but they are structural guides, not output text: translate headings, status words (e.g., Normal/Abnormal, Warning/Critical), and all narrative into the user's language instead of copying English verbatim. Users act on these summaries to make confirmation decisions; an answer in a language they did not use degrades comprehension. Technical identifiers stay verbatim in any language: command text, field names, Event IDs, error strings quoted from system output, registry paths. ## Execution Channel The execution channel determines **how** PowerShell commands are delivered to the target instance. This is orthogonal to the diagnostic mode (online/offline) -- both modes support both channels. The channel is determined based on where the agent is running relative to the target instance. - **Direct execution channel** (Local): Commands executed locally via `powershell.exe` on the same instance being diagnosed or where the offline disk is mounted. This is the default when the skill is running inside the target GuestOS. - **Remote execution channel** (Remote): Commands delivered to a remote ECS instance through Cloud Assistant. Applies to both online diagnosis (commands sent to the target instance itself) and offline diagnosis (commands sent to the instance where the faulty disk is mounted). For detailed command semantics, execution templates, and timeout guidelines, see [REMOTE-EXECUTION.md](references/REMOTE-EXECUTION.md). In online diagnosis this channel additionally supports platform-side evidence -- a platform context snapshot captured at prerequisites, platform triage that can identify platform-level root causes before the GuestOS deep-dive, and cross-validation data (monitoring metrics, system events, console screenshot); see [platform-evidence.md](references/online/platform-evidence.md) and the online WORKFLOW-GUIDE. **Remote transport priority**: when the remote channel is needed, first check whether the current environment exposes a usable remote command execution tool -- typically an MCP server tool that sends scripts to ECS instances via Cloud Assistant (e.g., a `RunCommand` / `ExecuteScript` style tool). If one is available, prefer it: it removes CLI installation, credential configuration, shell-quoting, and result-polling burden, and the platform handles attribution on its side. If no such tool is available, fall back to the Alibaba Cloud CLI (`aliyun ecs run-command`) exactly as documented in [REMOTE-EXECUTION.md](references/REMOTE-EXECUTION.md). The transport choice changes only HOW the command travels -- all other rules of this channel still apply whichever transport carries the command: instance identification (ask the user, never enumerate), the Windows-Only Gate, target scoping, the two-turn fix confirmation gate, output size management, and the PowerShell script rules. The UA observability rules below apply to the `aliyun` CLI transport; an MCP tool performs its own attribution. **Channel determination is environmental, not lexical**: decide the channel from where the agent actually runs, never from the user's wording -- a prompt saying "troubleshoot this server locally" does not place you inside the GuestOS. If the current environment cannot execute PowerShell at all (e.g., the agent is running on Linux/macOS or any non-Windows machine), you are by definition NOT inside the target Windows instance: the direct channel is unavailable, and this is a **channel blocker, not a scope exit**. Switch to the remote execution channel -- verify its prerequisites (instance ID, region ID, instance Running + Windows, plus a usable transport per the Remote transport priority above) and deliver the same PowerShell diagnostic commands through it. Only if the remote prerequisites also fail, present the complete copyable PowerShell scripts and ask the user to run them on the target instance. Terminating the troubleshooting with "PowerShell is not available here" is prohibited. ### Remote CLI Quick Reference (MUST copy these forms) The `aliyun-cli-ecs` plugin's subcommands and flags are kebab-case and do NOT follow OpenAPI parameter names. Never construct `aliyun ecs` commands from memory of the OpenAPI docs -- copy the tested forms below verbatim; for any subcommand not listed here, load [REMOTE-EXECUTION.md](references/REMOTE-EXECUTION.md) Section CLI Flag Reference BEFORE the first call. | Purpose | Tested invocation | | --- | --- | | Prerequisite check (Status + OSType gate) | `aliyun ecs describe-instances --biz-region-id --instance-ids '[""]'` | | Send PowerShell script | `aliyun ecs run-command --biz-region-id --type RunPowerShellScript --command-content '