Utilisez `/doctor` lorsque la configuration semble incorrecte ou avant d'activer un fournisseur LLM :```text
!decomp /doctor
!decomp /doctor:net

Le chemin de commande normal effectue une analyse locale, construit des faits d'analyse, appelle optionnellement le point de terminaison LLM configuré, vérifie la réponse par rapport aux preuves récupérées, et imprime du pseudo-C avec confiance, avertissements et notes d'incertitude :```text
!decomp ntdll!RtlAllocateHeap
!decomp kernel32!Sleep
!decomp game.exe!CheckIntegrity

- `brief` affiche la cible, la confiance, le résumé, et la première incertitude ou avertissement du vérificateur.
- `explain` ajoute les sections evidence, control-flow, type-hint, observed-behavior, et call-target.
- `json` affiche les JSON de requête et de réponse lisibles par machine.
- `facts` affiche uniquement les faits de l'analyseur et désactive le chemin LLM.
- `prompt` affiche le prompt système exact, le prompt utilisateur et les faits du prompt. Cela désactive l'appel LLM.
- `data` affiche un instantané JSON stable destiné à l'automatisation de style WinDbg JavaScript/NatVis.
- `analyzer` affiche le chemin pseudo-code déterministe de l'analyseur uniquement, sans appeler le LLM.
- `plan` effectue une analyse locale et affiche un plan de pré-vol sans appeler le LLM ni mettre à jour le cache des résultats. Il inclut les nombres de cibles/modules/plages, la disponibilité des PDB, la politique de session, le découpage estimé, les comptes pertinents pour la taille du prompt, et des recommandations pratiques.

Utilisez `/verbose` lorsqu'une commande semble bloquée ou lorsque vous souhaitez voir le flux de progression complet.```text
!decomp /verbose module!SlowFunction
!decomp /verbose /view:json module!SlowFunction

- `/view:window` exécute le chemin normal `!decomp` pour la cible et ouvre le résultat complet rendu dans une visionneuse séparée.
- La visionneuse utilise le même moteur de rendu de réponse que le chemin console, puis ouvre une fenêtre native sans mode Win32 appartenant à la fenêtre du débogueur lorsqu'elle peut être trouvée.
- La sortie du débogueur signale le handle de la fenêtre native de la visionneuse. Si la fenêtre de la visionneuse ne peut pas être créée, la commande affiche un avertissement et revient au résultat console normal.
- Les liens DML uniquement sont rendus comme des étiquettes de texte avec leurs chaînes de commande dans la visionneuse. Lorsque RichEdit est disponible, la fenêtre utilise une disposition RTF de style GitHub avec des en-têtes de section, un style de métadonnées et une mise en évidence pseudo-code ; sinon, elle revient au texte brut.
- Lorsque la session en cours a des résultats mis en cache précédents, la visionneuse affiche une liste d'historique à gauche pour que vous puissiez basculer entre la sortie actuelle et les résultats de décompilation antérieurs sans relancer l'analyse.
- `/view:json`, `/view:facts`, `/view:prompt` et `/view:data` restent des sorties console lisibles par machine et ne sont pas redirigés vers la visionneuse.```text
!decomp /limit:deep module!LargeFunction
!decomp /limit:huge module!VeryLargeFunction
!decomp /limit:12000 module!VeryLargeFunction
!decomp /timeout:120000 module!SlowFunction

- `/deobf:on` est la valeur par défaut. L'analyseur continue d'émettre des faits bruts, mais la récupération du dispatcher de style OLLVM à haute confiance, la preuve d'arête morte opaque, les idiomes de substitution et les superpositions de CFG sémantique peuvent guider les faits d'invite, la politique de fusion, la politique de conflit du vérificateur et la récupération pseudo-C structurée.
- `/deobf:off` conserve les faits `obfuscation`, `semantic_control_flow` et `deobfuscation_readiness` visibles, mais désactive les actions de réécriture sûres, maintient la structuration du flux de contrôle sur le CFG brut et indique aux chemins d'invite/fusion/vérificateur de préserver la forme obfusquée brute.
- Utilisez `/deobf:off` lorsque vous souhaitez inspecter directement le dispatcher, la branche factice ou la surface de substitution au lieu de demander à l'extension de récupérer une structure désorbusquée.
- `/deobfuscation:on|off` est accepté comme alias plus long.

Aides de cache et de rejeu :```text
!decomp /view:json module!FunctionName
!decomp /last:json
!decomp /view:explain module!FunctionName
!decomp /last:explain
!decomp /view:facts module!FunctionName
!decomp /last:facts
!decomp /view:data module!FunctionName
!decomp /last:data
!decomp /view:prompt module!FunctionName
!decomp /last:prompt
!decomp /history
!decomp /refresh module!FunctionName
!decomp /last:2:explain
!decomp /last:2:json

- `/fix:noreturn:name` traite les appels correspondants comme non-retour pour le désassemblage de repli, la récupération CFG, les faits ABI et les vérifications.
- `/fix:type:expr=TYPE` ajoute une indication de type utilisateur de haute confiance.
- `/fix:field:expr=TYPE` ajoute une indication de champ utilisateur de haute confiance.
- `/fix:rename:old=new` ajoute une indication de renommage et applique le renommage aux identifiants finaux du pseudo-code.
- `/fix:clear` efface toutes les corrections persistantes de session.

La variable d'environnement `DECOMP_NORETURN_OVERRIDES` reste prise en charge. Les valeurs de la ligne de commande `/fix:noreturn:` sont superposées à la valeur d'environnement d'origine pour la session WinDbg en cours.

Les commutateurs de correction sont persistants par session :

- `/fix:noreturn:`, `/fix:type:`, `/fix:field:` et `/fix:rename:` sont mémorisés par l'extension chargée et réutilisés lors des exécutions ultérieures de `!decomp`.
- `/fix:clear` efface toutes les corrections persistantes de session et restaure la substitution d'environnement non-retour à sa valeur d'origine au moment du chargement de l'extension.
- Les commutateurs hérités `/noreturn:`, `/type:`, `/field:`, `/rename:` et `/clear-overrides` restent pris en charge.

Les valeurs de correction malformées sont ignorées et signalées dans `uncertainties` plutôt que d'être mises en cache. Par exemple, `/fix:type:rcx` est ignoré car il ne contient pas une paire `expr=TYPE`.

Workflow d'investigation recommandé :

1. Commencez par `!decomp /view:facts target` pour confirmer que la plage de fonctions, les blocs, les appels, les importations, les données PDB et les faits de session semblent raisonnables.
2. Utilisez `!decomp /view:plan target` pour estimer le partitionnement, la taille de l'invite, le risque de délai d'attente et la qualité des symboles avant de soumettre une requête LLM.
3. Utilisez `!decomp /view:prompt target` lorsque la taille de l'invite, la langue ou la sélection d'éléments probants semble erronée.
4. Exécutez `!decomp target` pour obtenir le résultat pseudo-C complet vérifié.
5. Utilisez `!decomp /refresh target` lorsqu'un artefact persistant existant est rejoué mais que vous avez besoin d'une analyse actualisée.
6. Si le résultat semble erroné, exécutez `!decomp /view:explain target` et inspectez les avertissements du vérificateur, la couverture des preuves et les corrections suggérées.
7. Ajoutez des corrections ciblées telles que `/fix:noreturn:`, `/fix:type:`, `/fix:field:` ou `/fix:rename:` et réexécutez la même cible.
8. Utilisez `/history` et la relecture indexée `/last:N:*` pour comparer plusieurs résultats récents.
9. Capturez `/view:json` ou `/last:json` lors du signalement de bogues ou de la comparaison de comportements entre versions.

## Surface des faits de l'analyseur

Les faits récents de l'analyseur sont intentionnellement transmis via `/view:json`, `/view:facts`, `/view:prompt` et le mode LLM normal. Les champs de haute valeur à inspecter en premier :

- `stack_pointer` enregistre les deltas de pile par instruction, les alias relatifs au cadre et la confiance.
- `call_arguments` enregistre les arguments de registre et de pile récupérés aux sites d'appel, y compris les stockages de pile inter-blocs à proximité lorsque les preuves sont suffisamment solides.
- `pdb.prototype_parameters` enregistre les noms, types, ordinaux, emplacements ABI et confiance source des paramètres de prototype structurés.
- `control_flow` inclut les variables d'induction de boucle, les valeurs initiales, les pas, les bornes, la direction, l'adresse de la table de commutation, les cibles de cas, la cible par défaut, les bornes de plage, la signe et l'expression d'index lorsqu'ils sont récupérés.
- `callee_summaries` et les faits de cible d'appel incluent les candidats d'appel direct, indirect et virtuel/vtable ainsi que les sémantiques de mémoire, d'allocation, de libération et d'état connues de Win32/NT/Rtl.
- `obfuscation` expose les candidats de dispatcheur d'aplatissement de style OLLVM, les variables d'état, les arêtes sémantiques récupérées, les prédicats opaques et les idiomes de substitution scalaire.
- `semantic_control_flow` expose les arêtes vivantes/mortes récupérées qui sont dérivées des faits d'obfuscation et restent disponibles pour inspection même lorsque `/deobf:off` est utilisé.
- `deobfuscation_readiness` expose `enabled`, les actions de réécriture sûres, les hypothèses bloquées, les chemins de faits prioritaires, les compteurs et la confiance. Lorsqu'il est désactivé, il enregistre la décision de politique et bloque la réécriture du flux de contrôle désobfusqué.
- La sélection des faits pour l'invite classe les signaux de haute importance en premier, puis préserve la distribution avec un échantillonnage réparti afin que les grandes fonctions ne perdent pas toutes les preuves de faible fréquence.

## Configuration recommandée de dbgeng

Le moyen le plus rapide est d'intégrer l'en-tête et la bibliothèque d'importation dans le projet.

Disposition attendue de l'intégration :```text
third_party\dbgeng\inc\dbgeng.h
third_party\dbgeng\lib\dbgeng.lib

### Préparer la copie fournisseur à partir de chemins de fichiers explicites```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-DbgengVendor.ps1 `
    -HeaderPath 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\sdk\inc\dbgeng.h' `
    -LibraryPath 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbgeng.lib'

Actualiser ou créer la copie du fournisseur :```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-ZydisVendor.ps1

## Build

Le chemin recommandé est un Visual Studio Developer PowerShell ou une Developer Command Prompt.

Le `decomp.dll` compilé intègre désormais une version de fichier Windows provenant de `version.txt`.

### Build normal```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 -Reconfigure

`decomp_snapshot_tests` couvre les contrats analyseur/protocole/vérificateur pour les arguments de pile récupérés, les entrées ABI SIMD/FP, la suppression de l'idiome zéro vectoriel, la préférence d'induction de boucle, les métadonnées de commutateur, les métadonnées d'appel virtuel, les faits d'obscurcissement de style OLLVM, la politique `/deobf:off`, les résumés d'API connus, la sélection de faits par invite, et les vérifications de fondement du vérificateur.

### Build héritée de dbgeng```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build-Legacy.ps1 -Reconfigure

Ce script incrémente le dernier composant dans `version.txt` de `1`, force une reconfiguration, puis construit la DLL Release. Par exemple, `1.0.0.7` devient `1.0.0.8`.

### Options courantes

- `-Configuration Release|Debug`
- `-Clean`
- `-Reconfigure`
- `-ConfigureOnly`
- `-Verbose`
- `-ZydisSource Auto|Vendor|Fetch`
- `-ZydisVendorDir 'C:\path\to\zydis'`
- `-DebuggersRoot 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64'`
- `-DbgengIncludeDir 'E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\inc'`
- `-DbgengLibrary 'E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\lib\dbgeng.lib'`

### Exemple avec fournisseur prioritaire```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 `
    -Configuration Release `
    -ZydisSource Vendor `
    -Reconfigure `
    -Verbose

Le script de construction tente automatiquement de localiser :

- `cmake.exe` depuis le PATH, CMake autonome ou CMake fourni avec Visual Studio
- `third_party\dbgeng` sous la racine du projet
- `DEBUGGERS_ROOT` à partir des variables d'environnement ou des emplacements courants du kit Windows

La sélection de la source Zydis fonctionne comme ceci :

- `Auto` : préfère `third_party\zydis`, sinon récupère `Zydis` lors de la configuration
- `Vendor` : nécessite une arborescence `third_party\zydis` utilisable ou le chemin passé par `-ZydisVendorDir`
- `Fetch` : ignore l'arborescence du fournisseur et laisse CMake télécharger `Zydis`

`DEBUGGERS_ROOT` peut pointer vers une racine de débogueur qui utilise l'une de ces dispositions :

- `sdk\inc\dbgeng.h` et `sdk\lib\dbgeng.lib`
- `sdk\inc\dbgeng.h` et `sdk\lib\amd64\dbgeng.lib`
- `sdk\inc\dbgeng.h` et `sdk\lib\x64\dbgeng.lib`
- `sdk\inc\dbgeng.h` et `dbgeng.lib`
- `inc\dbgeng.h` et `lib\dbgeng.lib`
- `inc\dbgeng.h` et `lib\amd64\dbgeng.lib`
- `inc\dbgeng.h` et `lib\x64\dbgeng.lib`
- `dbgeng.h` et `dbgeng.lib`

Si votre installation ne correspond pas à ces dispositions, passez directement les chemins CMake :```powershell
cmake -S . -B build-manual -G "Visual Studio 17 2022" -A x64 `
    -DDBGENG_INCLUDE_DIR='E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\inc' `
    -DDBGENG_LIBRARY='E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\lib\dbgeng.lib'
cmake --build build-manual --config Release

Exemple d'abonnement ChatGPT :```json
{
  "provider": "chatgpt",
  "model": "gpt-5.5",
  "chatgpt_auth_file": "%USERPROFILE%\\.codex\\auth.json",
  "timeout_ms": 120000,
  "max_completion_tokens": 12000,
  "force_chunked": false,
  "chunk_trigger_instructions": 900,
  "chunk_trigger_blocks": 36,
  "chunk_block_limit": 24,
  "chunk_count_limit": 16,
  "chunk_completion_tokens": 6000,
  "merge_completion_tokens": 12000,
  "reasoning_effort": "medium"
}

Forcer l'anglais :```json
{
  "display_language": {
    "mode": "fixed",
    "tag": "en-US",
    "name": "English"
  }
}

Préréglage de coloration syntaxique sombre :```json
{
  "syntax_highlighting": {
    "keyword_color": "warnfg",
    "type_color": "emphfg",
    "function_name_color": "srcid",
    "identifier_color": "wfg",
    "number_color": "changed",
    "string_color": "verbfg",
    "char_color": "srcchar",
    "comment_color": "subfg",
    "preprocessor_color": "normfg",
    "operator_color": "srcannot",
    "punctuation_color": "srcpair"
  }
}

Exemple de détails de réponse `/view:json` :

- La réponse JSON inclut `pseudo_c` et `pseudo_c_tokens`.
- `pseudo_c_tokens` est un flux de jetons déterministe adapté à la coloration syntaxique externe.
- La requête sérialisée inclut `preferred_natural_language_tag` et `preferred_natural_language_name`, qui reflètent la langue d'affichage résolue après application de `display_language.mode`.
- Les faits d'analyseur incluent désormais les champs de qualité P0 :
  `ir_values`, `block_value_states`, `control_flow` et `abi`.
- `ir_values` expose les identifiants de valeur de type SSA, les sites de définition, les cibles, les expressions canoniques, les liens d'utilisation, les indicateurs de constante/copie et les indices de définition morte.
- `block_value_states` expose les définitions atteignantes live-in/live-out par bloc de base, les valeurs canoniques, la classe de stockage, l'état de convergence et la confiance.
- `stack_pointer` expose les deltas de pile par instruction, les alias relatifs au cadre, les base/décalages bruts et la confiance.
- `control_flow` expose les candidats de région structurée tels que `natural_loop`, `if_else_candidate` et `switch_candidate` avec preuves de blocs, métadonnées d'induction de boucle, métadonnées de table de saut/défaut/plage, signe, expressions d'index et confiance.
- `abi` expose les hypothèses d'espace d'ombre Microsoft x64, les preuves d'emplacement d'accueil, la reconnaissance de cadre/prologue/épilogue, les preuves d'appel sans retour, les candidats d'appel en queue, les candidats de thunk, les candidats de wrapper d'importation et les arguments d'appel récupérés à partir des registres et des magasins de pile.
- Les faits d'analyseur incluent désormais également les champs sémantiques P1 :
  `type_hints`, `idioms` et `callee_summaries`.
- `type_hints` expose les preuves de pointeur, local, décalage de champ, de type tableau, de type énumération, de type drapeau de bits et de candidat vtable avec source et confiance. Lorsque les données PDB sont disponibles, les paramètres/locaux de portée, les indices de champ et les constantes d'énumération sont également promus dans ce flux d'indices de type unifié.
- `idioms` expose les remplacements de plus haut niveau pour les appels d'assistance reconnus et les motifs de compilateur tels que copie/remplissage mémoire, copie de chaîne, vérification de cookie de sécurité, sondes de pile, assistants d'allocation/libération, initialiseurs d'agrégats et chargements globaux/importations relatifs à RIP.
- `callee_summaries` expose les indices de type de retour, modèle de paramètres, effet secondaire, effet mémoire, propriété, source et confiance pour les appelés directs et indirects ; les cibles d'appel enrichies en symbole/type remplacent les résumés heuristiques initiaux lorsque WinDbg peut les résoudre, et les candidats d'appel virtuel incluent les expressions cible ainsi que les décalages vtable lorsqu'ils sont récupérés.
- Les résumés d'API Win32/NT/Rtl connus décrivent le comportement de copie/remplissage/remise à zéro mémoire, d'allocation, de libération, de statut et d'erreur lorsque les noms de symboles sont disponibles.
- Les faits de prompt incluent `analyzer_skeleton` et `graph_summary` afin que le modèle affine une ébauche fondée sur des preuves au lieu de partir d'une page blanche.
- `graph_summary` fournit le bloc d'entrée, les régions de flux de contrôle, les conditions normalisées et les blocs représentatifs à fort signal avec une politique de troncature explicite. La sélection des faits de prompt classe désormais les entrées à fort signal et utilise un échantillonnage par dispersion pour maintenir la représentativité des grands ensembles de faits.
- `evidence_graph` expose les nœuds de faits à fort signal et les arêtes de provenance afin que les valeurs IR, les états de valeur de bloc, les accès mémoire, les cibles d'appel, les indices de type, les indices PDB et le comportement observé puissent être retracés jusqu'aux preuves d'instruction et de bloc.
- `obfuscation`, `semantic_control_flow` et `deobfuscation_readiness` exposent les faits de récupération de style OLLVM et indiquent si les conseils de réécriture de désobfuscation sont activés pour la commande en cours.
- La réponse du vérificateur inclut les `warnings` héritées ainsi que les entrées structurées `issues`. Chaque problème comporte `severity`, `code`, `message` et éventuellement `evidence` afin que les outils puissent filtrer les erreurs telles que `branch.true_target_not_successor` séparément des avertissements à moindre risque.
- Les vérifications du vérificateur comparent désormais les cibles vraies/fausses normalisées des branches aux successeurs du CFG, comparent la densité de branches du pseudo-code aux branches conditionnelles récupérées, croisent les résumés d'appelés directs avec les effets d'appel du pseudo-code, valident l'ancrage des nœuds/arêtes du graphe de preuves, et vérifient les références d'état de valeur de bloc par rapport aux blocs récupérés et aux valeurs IR.
- La sortie normale et explain peut inclure une section concise `suggested fixes`. Ce sont des commandes `/fix:*` conservatrices dérivées des problèmes du vérificateur, des opportunités de renommage basées sur PDB, ou des points chauds mémoire observés à plusieurs reprises. La sortie compatible DML rend les suggestions immédiatement applicables sous forme de liens de réexécution cliquables pour la même cible ; les suggestions de type placeholder restent en texte brut jusqu'à ce que `TYPE` soit remplacé.
- En mode LLM, l'extension alimente automatiquement les problèmes du vérificateur dans une invite de nouvelle tentative. La nouvelle tentative est conservée lorsqu'elle préserve ou améliore la qualité du vérificateur ; sinon, la réponse originale est conservée avec une note d'incertitude ajoutée.
- `session_policy` et `observed_behavior` exposent le contexte spécifique à WinDbg tel que la politique live/dump/kernel/TTD, les échantillons d'arguments de registre du cadre actuel, les points chauds mémoire et les suggestions de requêtes de trace.
- La requête sérialisée inclut désormais également un objet `pdb` lorsque les données de symbole/type sont disponibles.
- `pdb.availability` rapporte le niveau d'enrichissement tel que `none`, `symbols`, `typed` ou `scoped`.
- `pdb.params`, `pdb.locals`, `pdb.field_hints`, `pdb.enum_hints` et `pdb.source_locations` sont destinés à être des indices sémantiques lisibles par machine pour les outils externes ou l'analyse hors ligne.

Écrasements d'environnement optionnels :

- `DECOMP_LLM_PROVIDER`
- `DECOMP_LLM_ENDPOINT`
- `DECOMP_LLM_MODEL`
- `DECOMP_LLM_API_KEY`
- `OPENAI_API_KEY`
- `DECOMP_LLM_CHATGPT_ACCESS_TOKEN`
- `DECOMP_LLM_CODEX_ACCESS_TOKEN`
- `KERNFORGE_CODEX_ACCESS_TOKEN`
- `DECOMP_LLM_CHATGPT_AUTH_FILE`
- `DECOMP_LLM_CODEX_AUTH_FILE`
- `KERNFORGE_CODEX_AUTH_FILE`
- `DECOMP_LLM_REASONING_EFFORT`
- `DECOMP_LLM_TIMEOUT_MS`
- `DECOMP_LLM_MAX_COMPLETION_TOKENS`
- `DECOMP_LLM_FORCE_CHUNKED`
- `DECOMP_LLM_CHUNK_TRIGGER_INSTRUCTIONS`
- `DECOMP_LLM_CHUNK_TRIGGER_BLOCKS`
- `DECOMP_LLM_CHUNK_BLOCK_LIMIT`
- `DECOMP_LLM_CHUNK_COUNT_LIMIT`
- `DECOMP_LLM_CHUNK_COMPLETION_TOKENS`
- `DECOMP_LLM_MERGE_COMPLETION_TOKENS`
- `DECOMP_NORETURN_OVERRIDES`
  Fragments de noms de fonction séparés par des virgules ou des points-virgules traités comme cibles sans retour lors du désassemblage de repli, de la récupération des successeurs du CFG, des faits ABI et des vérifications du vérificateur. Exemple : `DECOMP_NORETURN_OVERRIDES=MyAbort;PanicAndExit`.

Note de priorité qualité :

- L'extension prend désormais en charge l'analyse multi-passes par morceaux pour les grandes fonctions.
- L'analyseur envoie les faits de valeur IR, les états de valeur de bloc, les régions de flux de contrôle, les faits du graphe de preuves et les preuves ABI x64/sans retour au LLM avant le raffinement, de sorte que `/view:analyzer`, `/view:json` et le mode LLM normal partagent tous la même base de preuves P0.
- Le vérificateur croise les boucles, les commutateurs, les sans retour, les cibles de branche, le comportement de retour, les effets d'appel d'appelé, l'ancrage du graphe de preuves, la cohérence des états de valeur de bloc, la couverture des preuves et les déclarations d'identifiant suspectes par rapport aux preuves de l'analyseur. Il abaisse la confiance lorsque des assertions confiantes dépassent les faits récupérés et étiquette chaque problème avec une paire sévérité/code stable.
- Lorsque le retour du vérificateur détecte des erreurs de schéma, des conflits de faits ou une confiance ajustée très faible, le chemin LLM effectue une nouvelle tentative automatique avec les problèmes du vérificateur ajoutés à l'invite.
- Un bon point de départ pour les modèles cloud est `max_completion_tokens=12000`, `chunk_completion_tokens=6000` et `merge_completion_tokens=12000`, avec `force_chunked=false` et des déclencheurs de morceau autour de `900 instructions` ou `36 blocs`.
- Gardez `force_chunked=true` uniquement pour les tests de résistance du pipeline de morceaux. La décompilation axée sur la qualité des fonctions aplaties ou à répartiteur nécessite généralement une seule invite jusqu'à ce que la fonction soit suffisamment grande pour dépasser les déclencheurs de morceau configurés.
- Gardez `timeout_ms` élevé pour les modèles cloud. `120000` est un point de départ plus sûr que `15000`.
- Si la qualité est encore faible sur les fonctions énormes, augmentez `chunk_count_limit` avant de réduire `/limit:N`.
- Si aucun point de terminaison n'est configuré, l'extension tombe sur le fournisseur de simulation déterministe.
- Même lorsque l'extension utilise `/view:analyzer` ou le fournisseur de simulation, `display_language` et `syntax_highlighting` affectent toujours ce que l'utilisateur voit.

## Test de fumée WinDbg

1. Compilez avec `Build.ps1` ou `Build-Legacy.ps1`.
2. Placez `decomp.llm.json` à côté du `decomp.dll` compilé.
3. Démarrez WinDbg. Les variables d'environnement ne sont que des écrasements optionnels.
4. Chargez l'extension.
5. Validez le mode analyseur uniquement avant d'activer le chemin LLM.```text
.load C:\path\to\decomp.dll
!decomp /view:analyzer ntdll!RtlAllocateHeap
!decomp /view:facts kernel32!Sleep

Vérifications attendues :

- `target`, `entry`, et `module` devraient se résoudre de manière cohérente
- `regions` devrait être non nul pour les fonctions normales
- `/view:analyzer` devrait toujours afficher la confiance de l'analyseur et le squelette du pseudo-code
- le mode LLM devrait remplir `summary`, `pseudo_c`, `pseudo_c_tokens`, et `verified`
- la sortie `/view:json` devrait inclure `preferred_natural_language_tag` et `preferred_natural_language_name` dans la requête sérialisée
- lorsque des PDB privées ou riches sont chargées, `/view:json` devrait également inclure `pdb.prototype`, `pdb.params`, et éventuellement `pdb.locals`
- pour les structures et énumérations typées, `/view:json` peut inclure `pdb.field_hints` et `pdb.enum_hints`

## Exemple d’abonnement ChatGPT```powershell
$env:DECOMP_LLM_PROVIDER = "chatgpt"
$env:DECOMP_LLM_MODEL = "gpt-5.5"
$env:DECOMP_LLM_CHATGPT_AUTH_FILE = "$env:USERPROFILE\.codex\auth.json"
$env:DECOMP_LLM_TIMEOUT_MS = "120000"

### LM Studio```powershell
$env:DECOMP_LLM_ENDPOINT = "http://127.0.0.1:1234/v1/chat/completions"
$env:DECOMP_LLM_MODEL = "local-model"
$env:DECOMP_LLM_API_KEY = "lm-studio"