SharkByte561/windows-troubleshoot

Dépannage Windows avec TSS

TSS est la boîte à outils PowerShell signée du Support Microsoft. Elle contient 157 scénarios, environ 400 composants de trace, 215 jeux CollectLog, 9 rapports SDP, 24 déclencheurs d'arrêt automatique et 34 vérifications xray de problèmes connus. Elle collecte très bien les données mais n'en explique quasiment rien. Cette compétence fournit les éléments manquants :

• choisir quoi collecter ;
• vérifier à moindre coût avant de collecter quoi que ce soit ;
• lire ce qui a été collecté.

Le dossier de compétence contient un catalogue pré-construit de TSS (references/tss-index.json), ce qui permet les recherches même sur les machines sans TSS.

Exécution des scripts : les chemins sont relatifs au dossier de cette compétence. Utilisez le Windows PowerShell 5.1 intégré, présent sur toutes les machines Windows : powershell -NoProfile -ExecutionPolicy RemoteSigned -File <script>. pwsh 7 fonctionne de la même manière s'il est installé.

• -ExecutionPolicy RemoteSigned ne s'applique qu'à ce seul processus. Il est nécessaire car les clients Windows ont par défaut Restricted, qui bloque tous les fichiers .ps1. N'utilisez jamais Bypass (voir references/safety.md).
• Si un script est toujours bloqué parce que la compétence a été téléchargée sous forme de zip (« non signé numériquement »), exécutez Unblock-File sur les scripts\*.ps1 de cette compétence, jamais sur TSS.
• Si la stratégie de groupe définit la stratégie d'exécution, le paramètre est sans effet. C'est la décision des administrateurs, veuillez en informer l'utilisateur.

Où trouver TSS : les scripts trouvent une copie locale de TSS avec scripts/Resolve-TssRoot.ps1. Il vérifie d'abord $env:TSS_ROOT, puis le dossier enregistré par Update-Tss.ps1 ou Resolve-TssRoot.ps1 -Save <folder>, puis C:\TSS.

• Le triage, l'analyse des packages et la recherche de scénarios ne nécessitent pas de copie locale.
• Pour en obtenir une, exécutez scripts/Update-Tss.ps1 (niveau 2). Il installe une copie vérifiée dans C:\TSS (ou -TssRoot <folder>) et enregistre son emplacement.

Workflow

Toutes les demandes ne nécessitent pas toutes les étapes. Un utilisateur qui remet un zip passe directement à l'étape 5. Un utilisateur qui demande simplement « quel scénario pour X » n'a besoin que de l'étape 3.

1. Cerner le symptôme

Obtenez ceci avant toute chose :

• ce qui échoue, et le texte ou le code d'erreur exact
• depuis quand, et ce qui a changé à ce moment-là (mise à jour, pilote, politique, réseau)
• si cela affecte un utilisateur/machine ou plusieurs
• si cela peut être reproduit à la demande, ou si cela se produit par intermittence
• quel côté examiner pour les problèmes client/serveur

Ne demandez que ce que vous ne pouvez pas déduire. Ces réponses déterminent le scénario et l'endroit où il s'exécute.

2. Triage rapide en lecture seule (sur la machine affectée)

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

• Prend environ 20 secondes et ne nécessite pas d'administration. Il écrit triage.md et triage.json dans %TEMP%\win-triage\<horodatage>\.
• Il ne change rien. Les tests réseau envoient un ping à la passerelle, une recherche DNS et un GET HTTP vers msftconnecttest.com ; ignorez-les avec -NoNetworkTests.
• En mode élevé, il lit également le journal de sécurité (verrouillages, échecs d'ouverture de session) et teste le canal sécurisé du domaine.

Définissez -Hours pour couvrir le « depuis quand » avec une marge. Pour quelque chose qui a commencé « la semaine dernière », utilisez -Hours 240.

Lisez triage.md. Son tableau Flags est un ensemble de pistes, pas un verdict. Reliez les indicateurs au symptôme de l'utilisateur et ignorez le reste. De nombreux problèmes se terminent ici : un disque plein, un redémarrage en attente, un service central arrêté, une adresse APIPA, un canal sécurisé rompu, des bugchecks répétés. Dans ces cas, expliquez la correction et proposez de vous arrêter avant toute trace lourde.

3. Choisir le scénario TSS

powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 "les utilisateurs sont constamment verrouillés"
powershell -NoProfile -ExecutionPolicy RemoteSigned -File scripts/Find-TssScenario.ps1 -Name ADS_AccountLockout      # entrée complète

• Il renvoie les scénarios, CollectLogs, rapports SDP et composants classés, chacun avec la commande exacte, une ligne « utiliser quand », les outils complémentaires et les phrases décrivant les effets secondaires.
• Lisez la description complète de votre choix (-Name). Elle indique où exécuter le scénario et ce qu'il modifie.
• Préférez l'option la plus légère qui répond à la question : -CollectLog (journaux statiques) est préférable à -Scenario (trace en direct), et les variantes « Ex » ajoutent une capture réseau et PSR, ce qui les alourdit.
• Tous les problèmes ne sont pas des problèmes TSS. Un avertissement « correspondances faibles uniquement » signifie qu'aucun scénario ne correspond.
  • Les plantages et les écrans bleus sont résolus à partir du dump : WinDbg !analyze -v sur le minidump que le triage répertorie.
  • Les problèmes de disque plein, de matériel (WHEA) et de redémarrage en attente sont résolus par le triage lui-même.
  • Le rapport -SDP Perf des pages Learn est obsolète dans cette version de TSS.
• Pour les problèmes qui ne peuvent pas être reproduits à la demande, ajoutez un déclencheur d'arrêt automatique à partir de references/waitevent-recipes.md, par exemple -WaitEvent Evt:4740:Security.
• references/scenario-index.md est la liste consultable, regroupée par domaine.

4. Transmettre (ou exécuter) la collecte

Les traces TSS sont de niveau 3 dans references/safety.md : elles modifient la stratégie d'audit, les clés de registre de débogage et les caches, et peuvent produire des gigaoctets de données sensibles.

1. Présentez la commande, l'endroit où l'exécuter, les effets secondaires, la taille attendue et les prérequis de references/running-tss.md : console élevée, vérification de signature, stratégie d'exécution au niveau du processus et TSS à jour (il refuse de s'exécuter après 90 jours).
   • Find-TssScenario.ps1 affiche l'expiration à chaque recherche. Si la copie est expirée ou sur le point de l'être, proposez scripts/Update-Tss.ps1, qui est de niveau 2 : il télécharge, vérifie le hachage et les signatures, et installe à côté de l'ancienne copie. -CheckOnly se contente de comparer les versions.
   • Si la mise à jour n'est pas possible immédiatement (machine hors ligne, ou collecte qui doit correspondre à une précédente), l'ajout de -noExpire à la commande TSS est le contournement intégré de Microsoft. Dites ce qu'il en coûte : définitions figées à cette version, et le support peut demander une réexécution sur la version actuelle.
2. Exécutez-la vous-même uniquement après un accord explicite, et seulement sur une machine que l'utilisateur administre.
3. Habituellement, c'est l'utilisateur qui l'exécute, car une reproduction nécessite sa présence devant la machine.

N'utilisez jamais -Crash, notmyfault ou des modifications de stratégie d'exécution à l'échelle de la machine, sauf si l'utilisateur le demande explicitement.

5. Analyser le package collecté

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

Un zip est décompressé dans %TEMP%\tssx\<id> sauf si vous passez -ExtractDir. Passez-le lorsque l'utilisateur souhaite que tout soit conservé dans un seul dossier de cas, et gardez ce chemin court.

• Windows PowerShell 5.1 ne peut pas gérer les chemins de plus de 260 caractères, et les noms de fichiers TSS sont longs. Le script refuse un -ExtractDir de plus de 80 caractères ou un -OutDir de plus de 200. Utilisez quelque chose comme C:\cases\<case>, puis copiez les résumés là où ils doivent aller.

Le script lit le package sans le modifier. Il produit package-summary.md et package-summary.json avec :

• les métadonnées (ordinateur, scénario, heure, version du système d'exploitation)
• les problèmes xray trouvés
• les événements clés par journal d'événements et les principales erreurs
• les codes d'erreur les plus fréquents dans les journaux texte
• les dernières lignes d'échec dans les journaux d'installation/servicing
• les avertissements de collecte propres à TSS, et les fichiers de trace presque vides. Un fichier .etl de 6 octets signifie que la capture n'a jamais eu lieu, alors dites-le avant de raisonner à partir de celui-ci.
• un inventaire, y compris la liste des fichiers sensibles. Cela couvre également les journaux d'événements dont le texte contient des adresses e-mail ou des noms de profil utilisateur, ce que les événements Outlook et Office font souvent.

Ensuite, allez plus loin que le résumé :

• Ouvrez les fichiers spécifiques qu'il indique. references/package-anatomy.md indique quoi lire en premier pour chaque famille de scénarios et quel outil décode .etl, .blg, .pml et .dmp.
• Traitez les résultats xray et les modèles d'événements comme des hypothèses, et testez chacun d'eux par rapport à la configuration réelle de la machine. Si la machine affectée est accessible (souvent c'est celle sur laquelle vous vous trouvez), vérifiez le paramètre en lecture seule. Par exemple : conflit de règle NRPT → Get-DnsClientNrptPolicy et si la machine est jointe au domaine. Les clients VPN/overlay comme Tailscale ou Zscaler créent légitimement des règles NRPT locales, et une vérification qui ne correspond pas à la machine est un faux positif qu'il vaut la peine de mentionner.
• Demandez quand le problème s'est reproduit et pondérez les événements dans cette fenêtre de temps.
• Séparez le signal du bruit de fond ; la page d'anatomie liste le bruit habituel. Nommez ensuite le bruit dans le rapport (étape 6), afin que le lecteur ne le poursuive pas.
• Si TSS a enregistré des avertissements de collecte, dites quelles données manquent.

6. Rapport

Utilisez ce format. Restez court et spécifique au symptôme :

## Diagnostic : <une ligne>
**Confiance :** élevée / moyenne / faible, et pourquoi.
## Preuves
- <fichier ou vérification> → <ce qu'il montre, avec horodatage/comptage/code>
## Non lié (bruit de fond)
- <fournisseur/ID ou code, comptage> → <pourquoi ce n'est pas lié à ce symptôme, ex. DCOM 10010, BitLocker 24641, Store 0x80073D02>
## Correction
1. <étape> (niveau 1/2/3 selon safety.md, nécessite admin ?)
## Si cela ne résout pas le problème
- prochaine collecte : <commande .\TSS.ps1 exacte>, exécutée sur <machine>, reproduire, envoyer <zip>
## Avant de partager les données
- <fichiers sensibles du résumé du package, et quoi supprimer>

Décrivez les données personnelles que vous trouvez (adresses e-mail, SID, numéros de série, IP, noms d'utilisateur), en donnant les comptages et le fichier dans lequel elles se trouvent, mais ne les copiez pas dans votre réponse. La réponse se retrouve souvent dans le même ticket que vous essayez de garder propre.

Dites clairement ce que vous n'avez pas vérifié, ou ce que les données ne peuvent pas montrer (par exemple, un ETL de composant que seul Microsoft peut décoder).

Pièges

• Utilisez un seul scénario à la fois. Les composants et CollectLogs peuvent être combinés, mais pas les scénarios.
• Vérifiez où le scénario s'exécute. Les scénarios de verrouillage et KDC appartiennent au contrôleur de domaine. SMB, RDS et DNS ont des scénarios client et serveur séparés. L'exécuter du mauvais côté donne une trace propre et une conclusion erronée.
• xray a surtout besoin de la machine en direct. Aucune des 34 vérifications de cette version de TSS ne s'exécute hors ligne, donc xray.ps1 -Offline sur un package ne trouve rien. Lisez plutôt les fichiers xray_* qui ont été produits pendant la collecte (references/xray-checks.md liste les vérifications avec leurs articles KB).
• Actualisez l'index lorsque TSS change. Update-Tss.ps1 le reconstruit pour vous. Si l'utilisateur obtient un TSS plus récent d'une autre manière, exécutez scripts/Build-TssIndex.ps1 -TssRoot <folder> pour que les noms et les options correspondent. La recherche vous avertit lorsque l'index et la copie sur le disque diffèrent.
• Le bruit de fond est normal. Les journaux Windows sains enregistrent constamment des erreurs DCOM 10010/10016, Perflib, BitLocker 24641 et Store 0x80073D02. Ne construisez pas un diagnostic sur eux à moins qu'ils ne coïncident avec le symptôme dans le temps.

Fichiers

• scripts/Invoke-QuickTriage.ps1 : instantané de santé en direct en lecture seule.
• scripts/Find-TssScenario.ps1 : symptôme → commande TSS ; -Name donne l'entrée complète ; -AsJson pour l'analyse.
• scripts/Read-TssPackage.ps1 : analyse hors ligne d'un zip ou dossier MS_DATA.
• scripts/Update-Tss.ps1 : -CheckOnly compare la copie locale avec la version publiée. Sans cela, le script télécharge, vérifie et installe un TSS plus récent dans TSS_<version>, puis reconstruit l'index.
• scripts/Resolve-TssRoot.ps1 : affiche le dossier TSS local, s'il existe ; -Save <folder> enregistre une copie conservée ailleurs.
• scripts/Build-TssIndex.ps1 : régénère le catalogue references/ à partir d'un dossier TSS (lit uniquement ses sources JSON et xray).
• references/running-tss.md : prérequis, modèles de commandes, disposition de la sortie, expiration de 90 jours.
• references/safety.md : niveaux, arrêts d'urgence, effets secondaires connus, partage de données.
• references/package-anatomy.md : quoi lire par famille de scénarios, outils de décodage, bruit, codes d'erreur.
• references/scenario-index.md, waitevent-recipes.md, xray-checks.md, tss-index.json : catalogue généré.