使用 TSS 進行 Windows 疑難排解
TSS 是 Microsoft 支援團隊自己的簽名 PowerShell 工具包。它包含 157 個場景、約 400 個追蹤元件、215 個 CollectLog 集合、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 秒,不需要管理員權限。它會將
triage.md和triage.json寫入%TEMP%\win-triage\<timestamp>\。 - 它不會變更任何內容。網路測試會發送一個閘道 ping、一個 DNS 查詢和一個 HTTP GET 到 msftconnecttest.com;使用
-NoNetworkTests可以跳過這些測試。 - 以提升的權限執行時,它還會讀取安全性記錄(鎖定、失敗的登入)並測試網域安全通道。
設定 -Hours 以涵蓋「從何時開始」加上一些緩衝時間。對於「上週」開始的問題,請使用 -Hours 240。
讀取 triage.md。其中的 Flags 表格是一組線索,而非最終判定。將這些標記與使用者的症狀相關聯,然後忽略其餘部分。許多問題在這裡就結束了:磁碟已滿、待重新啟動、核心服務停止、APIPA 位址、安全通道中斷、重複的錯誤檢查。在這些情況下,解釋修正方法並提供在進行任何繁重追蹤之前停止的選項。
3. 選擇 TSS 場景
powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 "user keeps getting locked out"
powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 -Name ADS_AccountLockout # 完整項目
- 它會傳回排名的場景、CollectLog、SDP 報告和元件,每個都包含確切的命令、「使用時機」說明、附加工具和副作用說明。
- 閱讀您選擇的項目的完整說明(
-Name)。它指出了在哪裡執行場景以及它會變更什麼。 - 優先選擇能回答問題的最輕量選項:
-CollectLog(靜態日誌)優於-Scenario(即時追蹤),而「Ex」變體則會增加網路抓取和 PSR,使其更為繁重。 - 並非每個問題都是 TSS 問題。「僅有弱相符」的警告表示沒有適合的場景。
- 當機和藍屏問題是透過轉儲檔案解決的:在初始健康檢查列出的迷你轉儲上執行 WinDbg
!analyze -v。 - 磁碟已滿、硬體 (WHEA) 和待重新啟動問題是從初始健康檢查本身解決的。
- 來自 Learn 頁面的
-SDP Perf報告在此 TSS 版本中已棄用。
- 當機和藍屏問題是透過轉儲檔案解決的:在初始健康檢查列出的迷你轉儲上執行 WinDbg
- 對於無法按需求重現的問題,請從
references/waitevent-recipes.md新增一個自動停止觸發器,例如-WaitEvent Evt:4740:Security。 references/scenario-index.md是可瀏覽的清單,按區域分組。
4. 移交(或執行)收集
TSS 追蹤是 references/safety.md 中的第 3 層:它們會變更稽核原則、偵錯登錄機碼和快取,並可能產生數 GB 的敏感資料。
- 提供命令、執行位置、副作用、預期大小以及來自
references/running-tss.md的先決條件:提升的命令提示字元、簽章檢查、進程範圍的執行原則以及最新的 TSS(它會在 90 天後拒絕執行)。Find-TssScenario.ps1會在每次查詢時列印到期日。如果副本已過期或即將過期,請提供scripts/Update-Tss.ps1,這是第 2 層:它會下載、驗證雜湊和簽章,並安裝在舊副本旁邊。-CheckOnly僅比較版本。- 如果目前無法更新(離線機器,或必須與較早版本相符的收集),在 TSS 命令中加入
-noExpire是 Microsoft 內建的覆寫方法。說明其代價:定義凍結在該組建版本,且支援團隊可能會要求在目前版本上重新執行。
- 只有在得到明確同意後,且僅在使用者管理的機器上,才能自行執行。
- 通常由使用者執行,因為重現問題需要他們在機器前。
除非使用者明確要求,否則切勿使用 -Crash、notmyfault 或機器範圍的執行原則變更。
5. 分析收集的套件
powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Read-TssPackage.ps1 <C:\MS_DATA\TSS_...zip | folder> [-OutDir <dir>] [-ExtractDir <short dir>]
a 除非傳遞 -ExtractDir,否則 Zip 檔會解壓縮到 %TEMP%\tssx\<id>。當使用者希望將所有內容保存在一個案例資料夾中時傳遞此參數,並保持該路徑簡短。
- Windows PowerShell 5.1 無法處理超過 260 個字元的路徑,而 TSS 的檔案名稱很長。如果
-ExtractDir超過 80 個字元或-OutDir超過 200 個字元,指令碼會拒絕執行。請使用類似C:\cases\<case>的路徑,然後將摘要複製到任何需要的地方。
指令碼會在不變更套件的情況下讀取它。它會產生 package-summary.md 和 package-summary.json,包含:
- 中繼資料(電腦、場景、時間、OS 組建)
- 發現的 xray 問題
- 每個事件記錄檔的關鍵事件和主要錯誤
- 文字記錄檔中最常見的錯誤碼
- 安裝/服務記錄檔中的最後失敗行
- TSS 自己的收集警告,以及幾乎為空的追蹤檔案。一個 6 位元組的
.etl表示捕捉從未執行過,因此在推理之前先說明這一點。 - 庫存清單,包括敏感檔案清單。這也涵蓋文字中包含電子郵件地址或使用者設定檔名稱的事件記錄檔,Outlook 和 Office 事件經常如此。
然後,進一步深入分析摘要:
- 開啟它指向的特定檔案。
references/package-anatomy.md說明了每個場景系列應首先讀取什麼,以及哪個工具可以解碼.etl、.blg、.pml和.dmp。 - 將 xray 發現和事件模式視為假設,並針對機器的實際配置測試每個假設。如果可以存取受影響的機器(通常就是您正在操作的機器),請以唯讀方式檢查設定。例如:NRPT 規則衝突 →
Get-DnsClientNrptPolicy以及機器是否實際加入網域。VPN/overlay 用戶端(例如 Tailscale 或 Zscaler)會合法地建立本機 NRPT 規則,而不符合機器的檢查則是值得說明的誤判。 - 詢問問題何時重現,並加權分析該時間視窗內的事件。
- 將訊號與背景噪音分開;解剖頁面列出了常見的噪音。然後在報告(步驟 6)中指明噪音,以便讀者不會追查它。
- 如果 TSS 記錄了收集警告,請說明缺少哪些資料。
6. 報告
使用此格式。保持簡短並針對症狀:
## 診斷:<一行摘要>
**信心水準:** 高 / 中 / 低,並說明原因。
## 證據
- <檔案或檢查> → <顯示的內容,附帶時間戳記/計數/代碼>
## 無關項目(背景噪音)
- <提供者/ID 或代碼、計數> → <為何與此症狀無關,例如 DCOM 10010、BitLocker 24641、Store 0x80073D02>
## 修正
1. <步驟>(依照 safety.md 的第 1/2/3 層,需要管理員權限?)
## 如果無法解決
- 下一步收集:<確切的 .\TSS.ps1 命令>,在 <機器> 上執行,重現問題,發送 <zip 檔>
## 分享資料前
- <來自套件摘要的敏感檔案,以及應移除的內容>
描述您找到的個人資料(電子郵件地址、SID、序號、IP、使用者名稱),提供計數和所在檔案,但不要將其複製到您的答案中。答案最終往往會進入同一個您試圖保持乾淨的工單中。
清楚地說明您未檢查的內容,或資料無法顯示的內容(例如,只有 Microsoft 才能解碼的元件 ETL)。
注意事項
- 一次使用一個場景。 元件和 CollectLog 可以組合,但場景不行。
- 檢查場景在哪裡執行。 鎖定和 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:產生的目錄。