SharkByte561/Windows-Fehlerbehebung

Windows-Fehlerbehebung mit TSS

TSS ist das signierte PowerShell-Toolkit von Microsoft Support. Es verfügt über 157 Szenarien, etwa 400 Ablaufverfolgungskomponenten, 215 CollectLog-Sets, 9 SDP-Berichte, 24 Auto-Stopp-Trigger und 34 Xray-Prüfungen für bekannte Probleme. Es sammelt Daten sehr gut, erklärt jedoch fast nichts davon. Dieser Skill liefert die fehlenden Teile:

• Auswahl der zu sammelnden Daten;
• kostengünstige Prüfung vor dem Sammeln;
• Lesen der gesammelten Ergebnisse.

Der Skill-Ordner enthält einen vorgefertigten Katalog von TSS (references/tss-index.json), sodass Suchvorgänge auch auf Rechnern ohne TSS funktionieren.

Ausführen der Skripte: Pfade sind relativ zu diesem Skill-Ordner. Verwenden Sie die integrierte Windows PowerShell 5.1, die jeder Windows-Computer hat: powershell -NoProfile -ExecutionPolicy RemoteSigned -File <script>. pwsh 7 funktioniert genauso, falls installiert.

• -ExecutionPolicy RemoteSigned gilt nur für diesen einen Prozess. Er ist erforderlich, da Windows-Clients standardmäßig Restricted verwenden, was jede .ps1-Datei blockiert. Verwenden Sie niemals Bypass (siehe references/safety.md).
• Wenn ein Skript trotzdem blockiert wird, weil der Skill als ZIP heruntergeladen wurde ("nicht digital signiert"), führen Sie Unblock-File für die scripts\*.ps1 dieses Skills aus, niemals für TSS.
• Wenn die Gruppenrichtlinie die Ausführungsrichtlinie festlegt, hat der Schalter keine Wirkung. Das ist die Entscheidung der Administratoren – teilen Sie dies dem Benutzer mit.

Wo TSS lebt: Die Skripte finden eine lokale TSS-Kopie mit scripts/Resolve-TssRoot.ps1. Es prüft zuerst $env:TSS_ROOT, dann den von Update-Tss.ps1 oder Resolve-TssRoot.ps1 -Save <folder> gespeicherten Ordner, dann C:\TSS.

• Triage, Paketanalyse und Szenariosuche benötigen keine lokale Kopie.
• Um eine zu erhalten, führen Sie scripts/Update-Tss.ps1 aus (Stufe 2). Es installiert eine verifizierte Kopie nach C:\TSS (oder -TssRoot <folder>) und speichert deren Speicherort.

Arbeitsablauf

Nicht jede Anfrage erfordert jeden Schritt. Ein Benutzer, der ein ZIP-Archiv übergibt, springt direkt zu Schritt 5. Ein Benutzer, der nur fragt "welches Szenario für X", benötigt nur Schritt 3.

1. Das Symptom eingrenzen

Ermitteln Sie zuerst Folgendes:

• Was schlägt fehl und der genaue Fehlertext oder -code?
• Seit wann und was hat sich um diesen Zeitpunkt geändert (Update, Treiber, Richtlinie, Netzwerk)?
• Betrifft es einen Benutzer/Rechner oder viele?
• Kann es auf Abruf reproduziert werden oder tritt es sporadisch auf?
• Welche Seite muss bei Client/Server-Problemen betrachtet werden?

Fragen Sie nur nach Dingen, die Sie nicht ableiten können. Diese Antworten bestimmen das Szenario und den Ausführungsort.

2. Schneller schreibgeschützter Triage (auf dem betroffenen Rechner)

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

• Dauert etwa 20 Sekunden und benötigt keine Administratorrechte. Es schreibt triage.md und triage.json nach %TEMP%\win-triage\<timestamp>\.
• Es ändert nichts. Die Netzwerktests senden einen Gateway-Ping, eine DNS-Abfrage und einen HTTP-GET an msftconnecttest.com; überspringen Sie diese mit -NoNetworkTests.
• Mit erhöhten Rechten liest es auch das Sicherheitsprotokoll (Sperrungen, fehlgeschlagene Anmeldungen) und testet den Domänen-Sicherheitskanal.

Setzen Sie -Hours so, dass es den Zeitraum "seit wann" plus einen Puffer abdeckt. Für etwas, das "letzte Woche" begann, verwenden Sie -Hours 240.

Lesen Sie triage.md. Seine Flags-Tabelle ist eine Reihe von Hinweisen, kein Urteil. Beziehen Sie die Flags auf das Symptom des Benutzers und ignorieren Sie den Rest. Viele Probleme enden hier: eine volle Festplatte, ein ausstehender Neustart, ein gestoppter Kerndienst, eine APIPA-Adresse, ein defekter Sicherheitskanal, wiederholte Bugchecks. Erklären Sie in diesen Fällen die Lösung und bieten Sie an, vor einer aufwändigen Ablaufverfolgung aufzuhören.

3. Das TSS-Szenario auswählen

powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 "Benutzer werden ständig gesperrt"
powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 -Name ADS_AccountLockout      # vollständiger Eintrag

• Es gibt bewertete Szenarien, CollectLogs, SDP-Berichte und Komponenten zurück, jeweils mit dem genauen Befehl, einer "Verwenden bei"-Zeile, den Add-On-Tools und den Nebenwirkungssätzen.
• Lesen Sie die vollständige Beschreibung Ihrer Auswahl (-Name). Sie sagt, wo das Szenario ausgeführt wird und was es ändert.
• Bevorzugen Sie die leichteste Option, die die Frage beantwortet: -CollectLog (statische Protokolle) ist besser als -Scenario (Live-Ablaufverfolgung), und die "Ex"-Varianten fügen eine Netzwerkerfassung und PSR hinzu, was sie schwerer macht.
• Nicht jedes Problem ist ein TSS-Problem. Eine Warnung "nur schwache Übereinstimmungen" bedeutet, dass kein Szenario passt.
  • Abstürze und Bluescreens werden über den Minidump gelöst: WinDbg !analyze -v auf dem vom Triage aufgelisteten Minidump.
  • Probleme mit voller Festplatte, Hardware (WHEA) und ausstehendem Neustart werden aus dem Triage selbst gelöst.
  • Der -SDP Perf-Bericht von den Learn-Seiten ist in dieser TSS-Version veraltet.
• Für Probleme, die nicht auf Abruf reproduziert werden können, fügen Sie einen Auto-Stopp-Trigger aus references/waitevent-recipes.md hinzu, z. B. -WaitEvent Evt:4740:Security.
• references/scenario-index.md ist die durchsuchbare Liste, gruppiert nach Bereich.

4. Datensammlung übergeben (oder ausführen)

TSS-Ablaufverfolgungen sind Stufe 3 in references/safety.md: Sie ändern die Überwachungsrichtlinie, Debug-Registrierungsschlüssel und Caches und können Gigabytes sensibler Daten erzeugen.

1. Präsentieren Sie den Befehl, den Ausführungsort, die Nebenwirkungen, die erwartete Größe und die Voraussetzungen aus references/running-tss.md: erhöhte Konsole, Signaturprüfung, prozessbezogene Ausführungsrichtlinie und ein aktuelles TSS (es weigert sich, nach 90 Tagen ausgeführt zu werden).
   • Find-TssScenario.ps1 gibt das Ablaufdatum bei jeder Suche aus. Wenn die Kopie abgelaufen ist oder bald abläuft, bieten Sie scripts/Update-Tss.ps1 an, das Stufe 2 ist: Es lädt herunter, überprüft den Hash und die Signaturen und installiert es neben der alten Kopie. -CheckOnly vergleicht nur Versionen.
   • Wenn ein Update gerade nicht möglich ist (Offline-Rechner oder eine Sammlung, die mit einer früheren übereinstimmen muss), ist das Hinzufügen von -noExpire zum TSS-Befehl der integrierte Override von Microsoft. Sagen Sie, was es kostet: Definitionen auf diesem Build eingefroren, und der Support kann eine erneute Ausführung mit der aktuellen Version verlangen.
2. Führen Sie es nur nach einer ausdrücklichen Zustimmung selbst aus, und nur auf einem Rechner, den der Benutzer verwaltet.
3. Normalerweise führt der Benutzer es aus, da eine Reproduktion seine Anwesenheit am Rechner erfordert.

Verwenden Sie niemals -Crash, notmyfault oder maschinenweite Änderungen der Ausführungsrichtlinie, es sei denn, der Benutzer bittet ausdrücklich darum.

5. Das gesammelte Paket analysieren

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

Ein ZIP-Archiv wird nach %TEMP%\tssx\<id> entpackt, es sei denn, Sie übergeben -ExtractDir. Verwenden Sie dies, wenn der Benutzer alles in einem Fallordner behalten möchte, und halten Sie den Pfad kurz.

• Windows PowerShell 5.1 kann Pfade über 260 Zeichen nicht verarbeiten, und TSS-Dateinamen sind lang. Das Skript lehnt ein -ExtractDir mit mehr als 80 Zeichen oder ein -OutDir mit mehr als 200 Zeichen ab. Verwenden Sie etwas wie C:\cases\<case> und kopieren Sie dann die Zusammenfassungen dorthin, wo sie benötigt werden.

Das Skript liest das Paket, ohne es zu ändern. Es erzeugt package-summary.md und package-summary.json mit:

• Metadaten (Computer, Szenario, Zeit, OS-Build)
• gefundene Xray-Probleme
• pro Ereignisprotokoll: Schlüsselereignisse und Top-Fehler
• die häufigsten Fehlercodes in den Textprotokollen
• die letzten Fehlerzeilen in Setup/Dienstprotokollen
• TSS-eigene Sammlungswarnungen und fast leere Ablaufverfolgungsdateien. Eine 6-Byte-.etl-Datei bedeutet, dass die Erfassung nie ausgeführt wurde – sagen Sie dies, bevor Sie daraus Schlussfolgerungen ziehen.
• ein Inventar, einschließlich der Liste sensibler Dateien. Dies umfasst auch Ereignisprotokolle, deren Text E-Mail-Adressen oder Benutzerprofilnamen enthält, was in Outlook- und Office-Ereignissen häufig vorkommt.

Gehen Sie dann über die Zusammenfassung hinaus:

• Öffnen Sie die spezifischen Dateien, auf die sie verweist. references/package-anatomy.md sagt, was für jede Szenariofamilie zuerst gelesen werden sollte und welches Tool .etl, .blg, .pml und .dmp dekodiert.
• Behandeln Sie Xray-Ergebnisse und Ereignismuster als Hypothesen und testen Sie jede gegen die tatsächliche Konfiguration des Rechners. Wenn der betroffene Rechner erreichbar ist (oft ist es der, auf dem Sie sich befinden), überprüfen Sie die Einstellung schreibgeschützt. Zum Beispiel: NRPT-Konfliktregel → Get-DnsClientNrptPolicy und ob der Rechner überhaupt in der Domäne ist. VPN/Overlay-Clients wie Tailscale oder Zscaler erstellen legitimerweise lokale NRPT-Regeln, und eine Prüfung, die nicht zum Rechner passt, ist ein falsch positives Ergebnis, das Sie erwähnen sollten.
• Fragen Sie, wann das Problem reproduziert wurde, und gewichten Sie die Ereignisse in diesem Zeitfenster.
• Trennen Sie Signal vom Hintergrundrauschen; die Anatomieseite listet das übliche Rauschen auf. Nennen Sie dann das Rauschen im Bericht (Schritt 6), damit der Leser ihm nicht nachjagt.
• Wenn TSS Sammlungswarnungen protokolliert hat, sagen Sie, welche Daten fehlen.

6. Bericht

Verwenden Sie dieses Format. Halten Sie es kurz und spezifisch für das Symptom:

## Diagnose: <eine Zeile>
**Vertrauenswürdigkeit:** hoch / mittel / niedrig, und warum.
## Beweise
- <Datei oder Prüfung> → <was es zeigt, mit Zeitstempel/Anzahl/Code>
## Nicht verwandt (Hintergrundrauschen)
- <Anbieter/ID oder Code, Anzahl> → <warum es nicht mit diesem Symptom zusammenhängt, z. B. DCOM 10010, BitLocker 24641, Store 0x80073D02>
## Lösung
1. <Schritt> (Stufe 1/2/3 gemäß safety.md, Administratorrechte erforderlich?)
## Falls das nicht hilft
- nächste Sammlung: <exakter .\TSS.ps1-Befehl>, ausgeführt auf <Rechner>, reproduzieren, <ZIP> senden
## Vor der Weitergabe der Daten
- <sensible Dateien aus der Paketzusammenfassung und was gelöscht werden sollte>

Beschreiben Sie personenbezogene Daten, die Sie finden (E-Mail-Adressen, SIDs, Seriennummern, IPs, Benutzernamen), mit Anzahl und Datei, kopieren Sie sie jedoch nicht in Ihre Antwort. Die Antwort landet oft im selben Ticket, das Sie sauber halten möchten.

Sagen Sie klar, was Sie nicht überprüft haben oder was die Daten nicht zeigen können (z. B. eine Komponenten-ETL, die nur Microsoft dekodieren kann).

Stolperfallen

• Verwenden Sie jeweils nur ein Szenario. Komponenten und CollectLogs können kombiniert werden, Szenarien jedoch nicht.
• Prüfen Sie, wo das Szenario ausgeführt wird. Sperr- und KDC-Szenarien gehören auf den Domänencontroller. SMB, RDS und DNS haben separate Client- und Server-Szenarien. Die Ausführung auf der falschen Seite ergibt eine saubere Ablaufverfolgung und eine falsche Schlussfolgerung.
• Xray benötigt meistens den Live-Rechner. Keine der 34 Prüfungen in dieser TSS-Version funktioniert offline, daher findet xray.ps1 -Offline gegen ein Paket nichts. Lesen Sie stattdessen die während der Sammlung erstellten xray_*-Dateien (references/xray-checks.md listet die Prüfungen mit ihren KB-Artikeln).
• Aktualisieren Sie den Index, wenn TSS sich ändert. Update-Tss.ps1 baut ihn für Sie neu auf. Wenn der Benutzer auf andere Weise ein neueres TSS erhält, führen Sie scripts/Build-TssIndex.ps1 -TssRoot <folder> aus, damit Namen und Optionen übereinstimmen. Die Suche warnt, wenn sich Index und Kopie auf der Festplatte unterscheiden.
• Hintergrundrauschen ist normal. Ein gesundes Windows protokolliert ständig DCOM 10010/10016-, Perflib-, BitLocker 24641- und Store 0x80073D02-Fehler. Bauen Sie keine Diagnose darauf auf, es sei denn, sie stimmen zeitlich mit dem Symptom überein.

Dateien

• scripts/Invoke-QuickTriage.ps1: Schreibgeschützter Live-Health-Schnappschuss.
• scripts/Find-TssScenario.ps1: Symptom → TSS-Befehl; -Name gibt den vollständigen Eintrag; -AsJson zum Parsen.
• scripts/Read-TssPackage.ps1: Offline-Analyse eines MS_DATA-ZIP-Archivs oder -Ordners.
• scripts/Update-Tss.ps1: -CheckOnly vergleicht die lokale Kopie mit der veröffentlichten Version. Ohne diesen Schalter lädt das Skript ein neueres TSS herunter, überprüft es und installiert es in TSS_<version> und baut dann den Index neu auf.
• scripts/Resolve-TssRoot.ps1: Gibt den lokalen TSS-Ordner aus, falls vorhanden; -Save <folder> zeichnet eine anderswo aufbewahrte Kopie auf.
• scripts/Build-TssIndex.ps1: Erzeugt den references/-Katalog aus einem TSS-Ordner neu (liest nur dessen JSON- und Xray-Quellen).
• references/running-tss.md: Voraussetzungen, Befehlsmuster, Ausgabelayout, der 90-Tage-Ablauf.
• references/safety.md: Stufen, harte Stopps, bekannte Nebenwirkungen, Datenaustausch.
• references/package-anatomy.md: Was pro Szenariofamilie gelesen werden sollte, Dekodierungswerkzeuge, Rauschen, Fehlercodes.
• references/scenario-index.md, waitevent-recipes.md, xray-checks.md, tss-index.json: Generierter Katalog.