alibabacloud-ecs-troubleshoot-skills

name	alibabacloud-ecs-troubleshoot-skills
description	name: alibabacloud-ecs-windows-online-troubleshooting Use when this capability is needed.

---

name: alibabacloud-ecs-windows-online-troubleshooting description: Use this skill whenever the user reports a problem with a Windows system, Windows Server, or Windows ECS instance, or asks to check, diagnose, inspect, or troubleshoot anything Windows-related. Covers network issues (ping, DNS, DHCP, firewall, SMB), RDP/remote desktop (connection failures, authentication, black screen, lag), storage/disk, system activation, Windows Update, performance slowdowns, user accounts/permissions, drivers, app crashes, security/certificate/TLS, scheduled tasks, or vague requests like 'check the system' or 'something is wrong.' Load this skill even if the user does not explicitly mention Windows but the context implies a Windows environment.

Windows ECS 在线诊断 Skill

何时使用本技能

当用户报告 Windows 实例的故障现象，或要求对 Windows 实例进行问题排查、状态检查时，加载本技能。覆盖范围包括：

• 网络问题：ping、DNS、DHCP、防火墙、SMB
• RDP/远程桌面：连接失败、认证、黑屏、卡顿
• 存储/磁盘、系统激活、Windows Update、性能问题
• 用户账户/权限、驱动、应用崩溃、安全/证书/TLS、计划任务
• 模糊描述如“检查一下系统”或“系统有问题”

诊断能力清单和问题路由表存放在 references/REFERENCE.md 中，在路径规划阶段加载。

---

诊断执行流程

用户呈现通用规则

执行过程中向用户呈现进度、排查路径、当前步骤等信息时，禁止暴露 Skill 内部标记，必须用自然语言描述该步骤所对应的诊断功能。需隐藏的内部标记包括但不限于：

• 内部文件名 / 路径：如 references/REFERENCE.md、references/rdp-service.md、references/networking-tcpip.md 等
• 内部术语：如「路由表」「reference」「推测性排查」「动态规划」「step 集合」「事件日志预诊断」 等 Skill 设计概念
• 内部编号 / 标签：如 Step 1、Step 2 等机械编号，以及 Direct/Contributing/Unrelated、Critical/Warning/Info、MUST 等词汇的原始字样
• 工具调用详情：如「调用 ReadReference / 加载 xxx 文件」之类的实现描述

示例：

• 不要说：「现在执行 rdp-service.md 的步骤」「本问题为 Direct + Critical」
• 改为说：「现在检查 TermService 服务状态与 RDP 监听端口配置」「此问题是直接根因且严重影响连接」

内部标记仅用于工具调用、日志与模型内部推理，不进入对话面向用户的文本。

问题理解

1. 提取用户问题中的核心现象（错误代码、提示信息、用户操作）
2. 确认关键上下文：系统能否启动？当前执行环境（控制台/RDP/云助手）？
3. 信息不足时 MUST 先向用户追问（具体现象、错误提示、操作时机等），收集到足够信息后再进入路径规划阶段
4. 记录原始问题描述，后续所有分析 MUST 围绕此问题

路径规划

1. 加载诊断能力与路由表：读取 references/REFERENCE.md，获取诊断能力清单和问题路由表
2. 事件日志预诊断（可选）：
   • 采集用户报告时间段内的关键事件日志（System、Application、Security）
   • 筛选 Error/Critical 级别事件，提取 Event ID 和来源
   • 根据事件日志特征初步界定问题方向（如网络类、驱动类、服务类、安全类）
   • 注意：仅采集和预分析，不执行具体诊断步骤
3. 路由表匹配（可使用专有知识库和世界知识辅助判断）：
   • 精确匹配 → 使用既定序列
   • 模糊匹配 → 使用最接近序列，但标注为「推测性排查」
4. 动态规划（未命中路由表时）：
   • 结合用户问题描述 + 事件日志预诊断结果，从诊断能力清单中选择相关 reference
   • 组合排查序列，并向用户说明：「此为动态规划的排查路径，非预设场景」
5. 输出：有序的 reference 列表（通常 2-5 个，避免过多）+ 规划理由
   • 向用户展示排查路径时，禁止使用 "Step 1、Step 2" 等无意义编号，必须描述每一步要检查的具体内容（如「检查 TermService 服务状态及监听端口配置」）

逐步执行

按排查序列逐个加载 reference 执行诊断。

单个 reference 执行规则：

1. 读取 reference 文件（references/{file}.md）
2. 根据用户问题从步骤集合中选取相关子集
3. 严格逐步骤执行：每个步骤必须完成「数据采集 → 分析判定 → 正常/异常结论」全流程后，才能进入下一步。禁止一次性批量采集多个步骤的数据再集中分析
   • 每个异常判定 MUST 有对应采集数据作为证据
   • 每个步骤 MUST 给出明确的正常/异常二分结论
   • 发现的异常 MUST 关联到具体根因
   • 采集脚本可根据实际情况调整，但应参考 reference 文件中提供的脚本作为起点
4. 遇到交叉引用 → 优先处理跳转目标，完成后回到主序列
5. 重复引用优化：同一个 reference 被多次引用时只需执行一次，后续直接复用已有结果

序列控制逻辑：

• 提前终止：发现的根因已能完全解释用户所有症状 → 终止后续 reference
• 继续执行：仅解释部分症状 → 继续执行后续 reference
• 方向修正：执行中发现问题方向与初始规划不符 → 回退到路径规划阶段，基于新线索重新规划

因果链分析

1. 汇总所有 reference 的发现
2. 构建因果关系链（区分直接原因和间接原因）
3. 按与用户问题的相关性排列优先级：relation（Direct > Contributing > Unrelated）× severity（Critical > Warning > Info）双维度排序；Unrelated 问题单独列为"其他发现"，不混入主要修复方案
4. 无发现时：尝试扩展排查范围；仍无发现 → 如实告知用户，给出建议的排查方向

修复方案

1. 每个根因提供可执行的修复脚本，MUST 附带验证方法和预期结果
2. 按优先级顺序呈现
3. 展示完整修复内容给用户，等待明确确认 — 禁止自动执行任何修复命令
4. 同题聚合：同一根因的多个修改合并为一个脚本
5. 异题分离：不同根因的修复严格分开，逐个确认
6. 涉及系统修改的操作 MUST 标注风险

---

因果链输出规范

因果链示例

[用户问题] 远程桌面连不上
    │
    ├── [Direct] TermService 服务已停止
    │       └── [Contributing] 依赖服务 RpcSs 异常
    │
    └── [Direct] 防火墙阻止 3389 端口
            └── [Contributing] 公共网络配置文件生效

修复脚本模板

#requires -RunAsAdministrator
# 修复：{根因名称}
# 风险：{风险说明}
# 验证：执行后运行 {验证命令} 确认修复结果

# --- 修复操作 ---
{修复命令}

# --- 验证 ---
{验证命令}

诊断结论输出模板

诊断结论

用户问题：{原始问题描述}

共发现 {N} 个问题，按修复优先级排列：

---

🔴 问题 1（Direct | Critical）：{root_cause}

证据：{采集到的异常数据}

分析：{为什么这个问题直接导致了用户看到的现象}

因果链：{用户问题} ← {直接原因} ← {间接原因（如有）}

修复方案：

{修复脚本}

验证：

{验证命令}

预期结果：{正常状态}

---

🟡 问题 2（Contributing | Warning）：{root_cause} ...

---

Gotchas（易错点）

诊断阶段

• Get-WmiObject 在部分系统上被弃用，优先使用 Get-CimInstance

• 网络连通性检查需区分 ICMP 被阻止和真正的网络不可达

• 命令输出格式简化原则：使用命令采集信息时，输出格式 MUST 尽量简单，减少大模型理解成本。优先使用 Select-Object 仅输出关键字段，避免冗长的完整对象输出。示例：

  • 推荐：Get-Service TermService | Select-Object Name, Status, StartType
  • 不推荐：Get-Service TermService（输出包含大量无关字段）
  • 推荐：Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 Id, Name, CPU
  • 不推荐：Get-Process | Sort-Object CPU -Descending | Select-Object -First 5（输出 20+ 字段）

• PowerShell 格式化输出延迟：Select-Object 返回的对象进入延迟格式化队列，后续 Write-Host 输出可能先于表格到达控制台，导致输出顺序错乱。采集脚本编写时必须在 Select-Object 后追加 | Format-Table 或 | Format-List 强制同步渲染，从源头保证输出顺序正确

• 避免解析 cmd 命令行的文本输出：cmd 命令输出的字段名随系统语言变化，解析会在中/英文系统上产生不同结果。应优先使用 PowerShell cmdlet 替代；无法替代时直传原始输出交给 LLM 分析。常用替换：

  cmd 命令	PowerShell 替代
  net user	Get-LocalUser / Get-CimInstance Win32_UserAccount
  net localgroup	Get-LocalGroupMember / Get-CimInstance Win32_GroupUser
  netstat	Get-NetTCPConnection / Get-NetUDPEndpoint
  ipconfig	Get-NetIPConfiguration / Get-NetIPAddress
  tasklist	Get-Process / Get-CimInstance Win32_Process
  sc query	Get-Service / Get-CimInstance Win32_Service
  net accounts	无直接替代，直传原始输出
  netsh	无直接替代，直传原始输出

修复阶段

• 修复防火墙规则时，MUST 保留现有规则，仅追加或修改目标规则
• 重启服务可能影响正在使用的 RDP 会话，需提醒用户
• 修改注册表前 MUST 建议用户先备份相关键值
• RDP 证书修复涉及 MachineKeys 权限，操作需谨慎

输出阶段

• 因果链中的“间接原因”不一定需要修复（可能是上游问题的连锁反应）
• 标注为 Unrelated 的问题不要混入主要修复方案，单独列出作为“其他发现”
• 动态规划的排查路径 MUST 标注为推测性，告知用户这不是预设的排查序列

命令不存在处理

• 当 cmd 工具或 PowerShell cmdlet 执行时报错「命令/模块不存在」（如 CommandNotFoundException、'xxx' is not recognized as an internal or external command）→ 直接跳过该检查项，不要重试
• 原因：系统环境不支持该工具（如精简版系统、组件未安装、版本过低、功能未启用），重试不会产生结果
• 处理方式：记录「该检查项因工具不可用已跳过」，继续执行后续步骤

PowerShell 与 cmd 重定向语法混用

• 禁止在 PowerShell 脚本中使用 cmd 重定向语法（如 >nul、2>nul、1>nul），这会触发 RedirectionFailed 错误
• PowerShell 中丢弃输出的正确写法：使用 $null 替代 nul，如 2>$null、>$null
• 示例对照：
  • 错误：schtasks /query /fo LIST /v 2>nul | Select-String "TermService"
  • 正确：schtasks /query /fo LIST /v 2>$null | Select-String "TermService"
  • 推荐：优先使用 PowerShell cmdlet（如 Get-ScheduledTask）替代 cmd 命令

含花括号的命令参数 MUST 用引号包裹

• PowerShell 把裸 {...} 视为脚本块（ScriptBlock），传给原生命令（如 bcdedit、reg、schtasks 等）时会被错误展开为 -encodedCommand 参数，导致命令报错
• 典型现象：bcdedit /enum {default} 报错 Invalid command line switch: /encodedCommand / 参数错误
• 规则：所有含花括号的字面量参数（BCD 标识符 {default} / {bootmgr} / {current} / {globalsettings} / GUID 形式 {xxxxxxxx-xxxx-...} 等）MUST 用 双引号 或 单引号 包裹后再传给原生命令
• 示例对照：
  • 错误：bcdedit /enum {default} 2>&1
  • 正确：bcdedit /enum "{default}" 2>&1
  • 错误：bcdedit /set {default} bootstatuspolicy IgnoreAllFailures
  • 正确：bcdedit /set "{default}" bootstatuspolicy IgnoreAllFailures
• 同样适用于 reg、wmic、schtasks、takeown 等所有原生 cmd/exe 工具调用

---

Source: aliyun/alibabacloud-ecs-troubleshoot-skills — distributed by TomeVault.