SharkByte561/windows-troubleshoot

使用 TSS 进行 Windows 故障排除

TSS 是微软支持团队自家的已签名 PowerShell 工具包。它包含 157 个场景、约 400 个跟踪组件、215 个日志收集集、9 个 SDP 报告、24 个自动停止触发器和 34 个 xray 已知问题检查。它收集数据的能力非常出色，但几乎不解释任何数据。本技能提供了缺失的部分：

• 选择要收集的内容；
• 在收集之前廉价检查；
• 解读返回的数据。

本技能文件夹中包含了预先构建的 TSS 目录 (references/tss-index.json)，因此在没有 TSS 的机器上也可以进行查询。

运行脚本： 路径是相对于本技能文件夹的。请使用每台 Windows 机器上都内置的 Windows PowerShell 5.1：powershell -NoProfile -ExecutionPolicy RemoteSigned -File <script>。如果已安装，pwsh 7 也可同样工作。

• -ExecutionPolicy RemoteSigned 仅适用于该进程。由于 Windows 客户端默认设置为 Restricted，这会阻止所有 .ps1 文件，因此需要此参数。切勿使用 Bypass（参见 references/safety.md）。
• 如果因为技能是通过 zip 下载的（“未经过数字签名”）而导致脚本仍被阻止，请对本技能自己的 scripts\*.ps1 运行 Unblock-File，切勿在 TSS 上运行。
• 如果组策略设置了执行策略，则该开关无效。这是管理员的决定，请告知用户。

TSS 存放位置： 脚本使用 scripts/Resolve-TssRoot.ps1 定位本地 TSS 副本。它首先检查 $env:TSS_ROOT，然后检查通过 Update-Tss.ps1 或 Resolve-TssRoot.ps1 -Save <folder> 保存的文件夹，最后检查 C:\TSS。

• 健康检查、数据包分析和场景查找不需要本地副本。
• 要获取本地副本，请运行 scripts/Update-Tss.ps1（第 2 级）。它会将一份经过验证的副本安装到 C:\TSS（或 -TssRoot <folder>）并保存其位置。

工作流程

并非每个请求都需要所有步骤。提供 zip 文件的用户直接跳转到步骤 5。只询问“X 用哪个场景”的用户只需要步骤 3。

1. 确定症状

在开始之前获取以下信息：

• 故障现象是什么，以及确切的错误文本或代码
• 从什么时候开始，以及当时发生了什么变化（更新、驱动程序、策略、网络）
• 是影响单个用户/机器还是多个
• 是否可以按需复现，还是间歇性发生
• 对于客户端/服务器问题，应在哪一端查找

仅询问你无法推断的信息。这些答案决定了场景及其运行位置。

2. 快速只读健康检查（在受影响的机器上）

powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Invoke-QuickTriage.ps1 [-Hours 72] [-NoNetworkTests]

• 大约需要 20 秒，无需管理员权限。它会在 %TEMP%\win-triage\<timestamp>\ 生成 triage.md 和 triage.json。
• 它不会更改任何内容。网络测试会向 msftconnecttest.com 发送一个网关 ping、一个 DNS 查询和一个 HTTP GET 请求；使用 -NoNetworkTests 可跳过这些测试。
• 如果以提升权限运行，它还会读取安全日志（锁定、登录失败）并测试域安全通道。

将 -Hours 设置为涵盖“从何时开始”并留有余地。对于“上周”开始的问题，请使用 -Hours 240。

阅读 triage.md。其标记表提供了一系列线索，而非最终结论。将这些标记与用户的症状关联起来，并忽略其余部分。许多问题在此处就能解决：磁盘已满、待重启、核心服务停止、APIPA 地址、安全通道中断、重复出现 bugcheck。在这种情况下，请解释修复方法，并主动提出在进行繁重跟踪之前停止操作。

3. 选择 TSS 场景

powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 "用户一直被锁定"
powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 -Name ADS_AccountLockout      # 完整条目

• 它会返回排序后的场景、日志收集、SDP 报告和组件，每个都包含确切的命令、“使用时机”说明、附加工具和副作用说明。
• 阅读你选择的场景的完整描述（-Name）。它会说明在何处运行该场景以及它会改变什么。
• 优先选择能够回答问题的最轻量级选项：-CollectLog（静态日志）优于 -Scenario（实时跟踪），而其“Ex”变体则会增加网络捕获和 PSR，这使得它们更重。
• 并非每个问题都是 TSS 问题。“仅弱匹配”警告表示没有合适的场景。
  • 崩溃和蓝屏问题可通过转储文件解决：在健康检查列出的 minidump 上运行 WinDbg !analyze -v。
  • 磁盘已满、硬件 (WHEA) 和待重启问题可通过健康检查本身解决。
  • 来自 Learn 页面的 -SDP Perf 报告在此 TSS 版本中已弃用。
• 对于无法按需复现的问题，请从 references/waitevent-recipes.md 添加自动停止触发器，例如 -WaitEvent Evt:4740:Security。
• references/scenario-index.md 是可浏览的列表，按区域分组。

4. 移交（或运行）收集

TSS 跟踪属于 references/safety.md 中的第 3 级：它们会更改审核策略、调试注册表键和缓存，并可能产生数 GB 的敏感数据。

1. 提供命令、运行位置、副作用、预期大小以及 references/running-tss.md 中的先决条件：提升的控制台、签名检查、进程范围的执行策略以及最新的 TSS（90 天后将拒绝运行）。
   • Find-TssScenario.ps1 在每次查询时都会打印到期信息。如果副本已过期或即将过期，请提供 scripts/Update-Tss.ps1，这是第 2 级：它会下载、验证哈希和签名，并安装到旧副本旁边。-CheckOnly 仅比较版本。
   • 如果当前无法更新（离线机器，或者需要与早期版本匹配的收集），则在 TSS 命令中添加 -noExpire 是微软内置的覆盖方法。说明其代价：定义冻结在该版本，并且支持人员可能会要求使用当前版本重新运行。
2. 只有在获得明确同意后，并且仅在用户管理的机器上，才能自行运行。
3. 通常由用户运行，因为复现通常需要他们位于机器前。

除非用户明确要求，否则切勿使用 -Crash、notmyfault 或机器范围执行策略更改。

5. 分析收集的数据包

powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Read-TssPackage.ps1 <C:\MS_DATA\TSS_...zip | folder> [-OutDir <dir>] [-ExtractDir <short dir>]

ZIP 文件将被解压到 %TEMP%\tssx\<id>，除非你传递了 -ExtractDir。当用户希望将所有内容保留在一个案例文件夹中时，请传递此参数，并保持路径简短。

• Windows PowerShell 5.1 无法处理超过 260 个字符的路径，而 TSS 文件名很长。此脚本会拒绝长度超过 80 个字符的 -ExtractDir 或长度超过 200 个字符的 -OutDir。请使用类似 C:\cases\<case> 的路径，然后将摘要复制到任何需要的位置。

此脚本在不更改数据包的情况下读取它。它会生成 package-summary.md 和 package-summary.json，其中包含：

• 元数据（计算机、场景、时间、操作系统版本）
• 发现的 xray 问题
• 每个事件日志的关键事件和顶部错误
• 文本日志中最常见的错误代码
• 设置/服务日志中的最后失败行
• TSS 自己的收集警告，以及近乎空的跟踪文件。一个 6 字节的 .etl 文件意味着捕获从未运行过，因此在据此推理之前请说明这一点。
• 清单，包括敏感文件列表。这也涵盖了文本中包含电子邮件地址或用户配置文件名称的事件日志，Outlook 和 Office 事件通常包含此类信息。

然后进一步深入研究摘要：

• 打开它指向的特定文件。references/package-anatomy.md 说明了对于每个场景系列应首先读取什么，以及用于解码 .etl、.blg、.pml 和 .dmp 的工具。
• 将 xray 发现和事件模式视为假设，并针对机器的实际配置测试每个假设。如果可以访问受影响的机器（通常就是你所在的那台），请以只读方式检查设置。例如：NRPT 规则冲突 → Get-DnsClientNrptPolicy 以及该机器是否已加入域。VPN/覆盖客户端（如 Tailscale 或 Zscaler）会合法地创建本地 NRPT 规则，而不符合该机器的检查是误报，值得说明。
• 询问问题复现的时间，并评估该时间窗口内的事件权重。
• 将信号与背景噪音分开；解剖页面列出了常见的噪音。然后在报告中（步骤 6）指明这些噪音，以便读者不去追查它们。
• 如果 TSS 记录了收集警告，请说明哪些数据丢失。

6. 报告

使用此格式。保持简洁并针对症状：

## 诊断：<一行>
**信心：** 高 / 中 / 低，以及原因。
## 证据
- <文件或检查> → <显示的内容，带时间戳/计数/代码>
## 不相关（背景噪音）
- <提供程序/ID 或代码，计数> → <为什么与当前症状无关，例如 DCOM 10010、BitLocker 24641、Store 0x80073D02>
## 修复
1. <步骤>（根据 safety.md 的 第 1/2/3 级，需要管理员权限？）
## 如果无效
- 下一步收集：<确切的 .\TSS.ps1 命令>，在 <机器> 上运行，复现，发送 <zip>
## 共享数据前
- <包摘要中的敏感文件，以及需要删除的内容>

描述你发现的个人数据（电子邮件地址、SID、序列号、IP、用户名），提供计数和所在文件，但不要将其复制到你的答案中。答案最终通常会出现在你正试图保持干净的同一个工单中。

清晰地说明你没有检查什么，或者数据无法显示什么（例如，只有微软才能解码的组件 ETL）。

注意事项

• 一次只使用一个场景。 组件和日志收集可以组合，但场景不能。
• 检查场景在何处运行。 锁定和 KDC 场景应在域控制器上运行。SMB、RDS 和 DNS 有单独的客户端和服务器场景。在错误的一端运行会导致干净的跟踪和错误的结论。
• xray 主要需要实时机器。 此 TSS 版本中的 34 个检查都无法离线运行，因此针对数据包运行 xray.ps1 -Offline 将找不到任何内容。请改为读取收集期间生成的 xray_* 文件（references/xray-checks.md 列出了带有其 KB 文章的检查）。
• TSS 更改时刷新索引。 Update-Tss.ps1 会为你重建索引。如果用户通过其他方式获得了更新的 TSS，请运行 scripts/Build-TssIndex.ps1 -TssRoot <folder>，以便名称和选项匹配。当索引和磁盘上的副本不同时，查找会发出警告。
• 背景噪音是正常的。 健康的 Windows 会持续记录 DCOM 10010/10016、Perflib、BitLocker 24641 和 Store 0x80073D02 错误。除非它们在时间上与症状相符，否则不要以此建立诊断。

文件

• scripts/Invoke-QuickTriage.ps1：只读实时健康快照。
• scripts/Find-TssScenario.ps1：症状 → TSS 命令；-Name 提供完整条目；-AsJson 用于解析。
• scripts/Read-TssPackage.ps1：对 MS_DATA zip 或文件夹的离线分析。
• scripts/Update-Tss.ps1：-CheckOnly 将本地副本与已发布版本进行比较。不带此参数，脚本会下载、验证并安装更新的 TSS 到 TSS_<version>，然后重建索引。
• scripts/Resolve-TssRoot.ps1：打印本地 TSS 文件夹（如果有）；-Save <folder> 记录保存在其他位置的副本。
• scripts/Build-TssIndex.ps1：从 TSS 文件夹重新生成 references/ 目录（仅读取其 JSON 和 xray 源代码）。
• references/running-tss.md：先决条件、命令模式、输出布局、90 天到期。
• references/safety.md：级别、硬性停止、已知副作用、数据共享。
• references/package-anatomy.md：按场景系列读取的内容、解码工具、噪音、错误代码。
• references/scenario-index.md、waitevent-recipes.md、xray-checks.md、tss-index.json：生成的目录。