windbg-decompile-ext

Estensione WinDbg x64 che disassembla funzioni live e utilizza un LLM per produrre pseudocodice verificato.

Current Scope

• assunzioni esclusivamente x64
• analisi della memoria live tramite DbgEng
• disassembly strutturato basato su Zydis per un recupero stabile di mnemonici/operandi
• recupero dell'intervallo di funzione tramite regione di simbolo, unwind ed euristiche
• recupero in stile SSA-lite per argomenti di registro in ingresso, variabili locali in stack slot, candidati di merge e condizioni di branch normalizzate
• fatti sui valori IR di basso livello con hint def-use, espressioni copia/costante canonizzate e marcatori di definizioni morte
• fatti sullo stato dei valori a livello di blocco per le definizioni reaching live-in/live-out convergenti su registri e variabili locali di stack
• fatti sulle regioni del flusso di controllo basati su dominatori per loop naturali, candidati if/else, candidati switch, metadati di induzione dei loop e metadati di range/default degli switch
• fatti sull'ABI x64 per slot shadow/home, delta dello stack pointer, riconoscimento prologo/epilogo, chiamate no-return, tail call, thunk, candidati import-wrapper e argomenti di chiamata recuperati su registro/stack
• recupero argomenti Microsoft x64 consapevole di SIMD/FP per xmm0-xmm3, con protezioni per lo zero-idiom vettoriale per evitare falsi argomenti in ingresso
• hint di recupero dei tipi per valori di tipo puntatore, variabili locali di stack, offset di campo, array con indice scalato, confronti di tipo enum, test di bitflag e candidati vtable
• fatti su idiomi e pattern di libreria per helper di memoria/stringhe, security cookie, stack probe, allocator, inizializzatori di aggregati e caricamenti RIP-relative di globali/import
• fatti sui target di chiamata per chiamate dirette, chiamate indirette via registro/memoria, candidati virtual-call/vtable-offset, tipo di ritorno, modello dei parametri, effetti collaterali, effetti sulla memoria, hint di ownership e confidenza
• fatti di offuscamento in stile OLLVM per dispatcher di control-flow flattening, edge semantici recuperati, edge morti da predicati opachi e idiomi di sostituzione scalare di istruzioni
• fatti di prontezza alla deoffuscazione più il controllo /deobf:on|off su se i fatti di offuscamento recuperati possono guidare la riscrittura in pseudo-C
• fatti del grafo delle evidenze che collegano fatti ad alto segnale dell'analizzatore, PDB e comportamento osservato al grounding su istruzioni/blocchi
• prompting refine-first con uno scheletro di pseudocodice generato dall'analizzatore, riepiloghi consapevoli del grafo per regioni CFG, condizioni e blocchi importanti, selezione classificata dei fatti ad alto segnale e campionamento distribuito per insiemi di fatti di grandi dimensioni
• collegamenti DML di WinDbg per la navigazione verso entry/basic-block/evidence/call-target quando la callback di output supporta DML
• modalità di risultato separate per output breve, spiegazione delle evidenze, solo fatti, prompt di debug, JSON e stile data-model
• switch di correzione utente per hint no-return, tipo, campo e rinomina
• fatti di policy di analisi consapevoli della sessione per sessioni live, dump, kernel e simil-TTD
• fatti sul comportamento osservato dal contesto corrente del debugger, inclusi campioni di argomenti di registro, hotspot di memoria e suggerimenti di query TTD quando disponibili
• classificazione RIP-relative di stringhe/globali/IAT e hint di firma del target di chiamata per il prompting LLM
• hint per il prompting LLM consapevoli del PDB caricato: prototipo, parametri/locali con scope, campo, enum e righe sorgente
• chiamate LLM dirette in-process dall'estensione
• adattatore HTTP compatibile con OpenAI o fallback mock deterministico
• passaggio di verifica sull'output LLM

WinDbg Usage

Caricare l'estensione dall'output di build, quindi eseguire !decomp su un simbolo o un indirizzo:```text .load C:\path\to\decomp.dll !decomp /doctor !decomp module!FunctionName !decomp 0x7ffb`12345678

• /doctor non richiede un target e non chiama il provider. Riporta il percorso di configurazione/stato di caricamento, il riepilogo di provider/modello/endpoint, la presenza di autenticazione senza segreti, le impostazioni di timeout/token/chunking, il supporto DML, la classe/qualificatore di sessione, il tipo di processore e le avvertenze relative al PDB.
• /doctor:net è accettato come richiesta esplicita di verifica di rete, ma attualmente segnala che il ping del provider viene saltato. L'estensione non esegue un probe di rete dalla modalità doctor.
• I valori segreti come chiavi API, token bearer, token di refresh e stringhe di query URL non vengono stampati.

I target possono essere simboli pubblici/privati, nomi di funzioni esportate o indirizzi. Se il target risolve a un indirizzo all'interno di una funzione, l'estensione tenta di recuperare l'intervallo della funzione contenente da simboli, dati di unwind ed euristiche del flusso di controllo. Metti tra virgolette i target che contengono spazi:```text !decomp "my module!Function With Spaces"

L'output normale, brief e explain include un flusso di avanzamento compatto anche senza /verbose. Le esecuzioni LLM lunghe mostrano il completamento dell'analisi locale, l'avanzamento dei chunk, gli avvisi di retry, l'inizio del merge, la verifica e il suggerimento di annullamento con Ctrl+Break. Le modalità leggibili dalla macchina, come /view:json, /view:facts, /view:prompt e /view:data, sopprimono le righe di avanzamento e i link helper DML, così che gli script ricevano solo il payload richiesto.

Usa /view:* per scegliere cosa vuoi vedere. Questo mantiene piccola la superficie dei comandi: un'unica opzione controlla tutte le modalità di output.```text !decomp /view:brief module!HotPath !decomp /view:explain module!BranchyFunction !decomp /view:json module!FunctionName !decomp /view:facts module!FunctionName !decomp /view:prompt module!FunctionName !decomp /view:data module!FunctionName !decomp /view:analyzer module!FunctionName !decomp /view:plan module!FunctionName

• /verbose stampa le fasi locali come la risoluzione del target, il recupero dell'intervallo di funzioni, le letture di byte, il disassemblaggio, la costruzione dei fatti dell'analizzatore, l'arricchimento PDB/sessione, la tokenizzazione dello pseudo-codice e i risultati del verificatore.
• In modalità LLM, /verbose stampa anche le dimensioni del prompt, i budget di token per le richieste, le fasi di connessione/invio/ricezione HTTP, le dimensioni dei chunk di risposta, il motivo di fine, l'anteprima JSON del modello estratto, i tentativi di retry e le decisioni di retry basate sul feedback del verificatore.
• La chiave API non viene stampata. I log di richiesta/risposta mostrano dimensioni e brevi anteprime anziché header completi o corpi del prompt integrali.
• /verbose sostituisce il flusso di avanzamento compatto con la traccia completa. Usalo quando le righe di avanzamento compatte non bastano a diagnosticare dove va il tempo.
• Durante un comando !decomp di lunga durata, premi Ctrl+Break in WinDbg per richiedere l'annullamento. L'estensione controlla gli interrupt tra le fasi di analisi locale e mentre attende il worker LLM, poi chiede all'I/O HTTP sincrono attivo di fermarsi.

Alias legacy come /brief, /explain, /json, /facts-only, /debug-prompt, /data-model, /dx e /no-llm funzionano ancora per vecchi script, ma i nuovi esempi usano /view:*.

Visualizzatore di finestre:```text !decomp /view:window module!FunctionName !decomp /view:window /view:explain module!FunctionName

• /limit:deep alza il limite di istruzioni a 8192.
• /limit:huge alza il limite di istruzioni a 16384.
• /limit:N imposta un limite di istruzioni esplicito.
• /timeout:MS sovrascrive il timeout della richiesta per questa invocazione.
• Il chunking LLM è controllato da decomp.llm.json; il limite di istruzioni da riga di comando controlla quanto codice locale l'estensione tenta di recuperare prima di inviare prompt.
• Le opzioni legacy /deep, /huge e /maxinsn:N rimangono supportate.

Decompilazione consapevole dell'offuscamento:```text !decomp /deobf:on module!FlattenedFunction !decomp /deobf:off module!FlattenedFunction !decomp /view:facts /deobf:off module!FlattenedFunction

• /last:json stampa il JSON della richiesta/risposta precedente senza rilanciare l'analisi.
• /last:explain ri-renderizza il precedente risultato completo con la sezione explain senza rilanciare l'analisi né chiamare l'LLM.
• /last:facts stampa i fatti dell'analizzatore dal risultato precedente senza rilanciare l'analisi.
• /last:data stampa lo snapshot precedente del data-model senza rilanciare l'analisi.
• /last:prompt stampa il dump precedente del prompt senza rilanciare l'analisi.
• /history elenca il ring buffer dei risultati in memoria. L'indice 1 è il risultato più recente.
• /refresh <target> bypassa la replica dell'artefatto persistente per quel target, esegue una nuova analisi locale e una nuova analisi LLM e sostituisce l'artefatto salvato dopo un risultato LLM riuscito.
• /last:N:explain, /last:N:json, /last:N:facts, /last:N:data e /last:N:prompt riproducono un risultato cache più vecchio in base all'indice di cronologia senza rilanciare l'analisi locale né chiamare l'LLM.
• Le modalità /last:* sono comandi di replay da terminale. Se un target è presente nello stesso comando, l'artefatto in cache viene riprodotto e per quel target non viene avviata alcuna analisi locale o richiesta LLM.
• Gli artefatti in cache in memoria vivono solo nell'istanza dell'estensione caricata. La cronologia dei risultati mantiene gli ultimi 8 risultati e scompare quando WinDbg scarica l'estensione o il processo termina.
• I risultati riusciti basati su LLM vengono anche salvati automaticamente in una cartella artifact accanto alla decomp.dll caricata. L'operatore non ha bisogno di un comando di salvataggio separato.
• Gli artefatti persistenti includono request, response, data_model, debug_prompt e un oggetto kernel_build con valori di versione Win32/KD, stringa di build, NtBuildLab opzionale e un fingerprint di build.
• In una sessione successiva, eseguendo lo stesso comando !decomp <target> viene automaticamente controllato il percorso artifact\<kernel_build>\... dopo la risoluzione del target e il recupero dell'RVA della funzione. Se il kernel_build salvato corrisponde alla build corrente del sistema operativo, l'estensione riproduce l'artefatto senza leggere i byte della funzione, eseguire i passaggi dell'analizzatore locale o chiamare l'LLM.
• Gli artefatti persistenti mancanti, illeggibili o non corrispondenti vengono trattati come cache miss. Il comando ricade su un'analisi fresca e sovrascrive l'artefatto solo dopo un risultato LLM riuscito.
• I collegamenti ad azioni DML nell'output normale usano queste viste /last:* in cache, quindi fare clic su explain, json, facts, prompt o data-model non avvia una nuova esecuzione di decompilazione.
• I comandi legacy /last-json, /last-explain, /last-facts, /last-data-model, /last-dx e /last-prompt rimangono supportati.

DML navigation:

• Quando WinDbg segnala che la callback di output corrente è compatibile con DML, il pseudo-codice viene evidenziato sintatticamente con gli slot di colore DML configurati.
• L'output normale include una riga actions con collegamenti cliccabili explain, json, facts, prompt, data-model e history per lo stesso target.
• L'output normale include anche una riga nav con collegamenti al disassembly di ingresso, al breakpoint di ingresso e alla riproduzione dell'ultimo artefatto.
• Gli indirizzi di ingresso, i blocchi di base, i blocchi di evidenza, le regioni di flusso di controllo, i siti di suggerimento di tipo, i siti osservati di memory hotspot, i suggerimenti di query TTD e i target di chiamata diretta diventano collegamenti cliccabili quando l'estensione dispone di sufficienti informazioni sugli indirizzi.
• Le incertezze e gli avvisi del verifier sono collegati alla migliore posizione di evidenza recuperata quando la causa può essere mappata a un branch, un loop, uno switch, una chiamata senza ritorno, un'istruzione di return o l'ingresso della funzione.
• Se il percorso di output corrente non è compatibile DML, l'estensione ricade automaticamente su testo semplice. Il risultato dell'analisi è lo stesso; cambia solo la presentazione.

Session-aware and observed-behavior details:

• /view:json, /view:facts, /view:prompt e la modalità LLM normale includono session_policy.
• session_policy registra la classe di debug, il qualificatore, il tipo di esecuzione, la strategia di analisi, i flag dump/live/kernel e se il supporto TTD risulta caricato.
• observed_behavior registra rip e rsp correnti, l'indirizzo di ritorno quando leggibile, campioni degli argomenti nei registri x64 Microsoft (rcx, rdx, r8, r9), hotspot ripetuti di accesso alla memoria e comandi TTD suggeriti.
• I campioni degli argomenti del frame corrente sono ad alta confidenza solo quando il program counter corrente è dentro la funzione analizzata. Altrimenti vengono mantenuti come suggerimenti contestuali.
• Se ttdext.dll o TTDReplay.dll è caricato nel processo del debugger, l'estensione aggiunge query suggerite dx @$cursession.TTD.Calls(...) invece di fingere silenziosamente che i dati di traccia siano già stati raccolti.

Gli switch di correzione utente consentono di correggere i fatti dell'analizzatore dalla riga di comando quando il debugger non dispone di sufficienti informazioni semantiche:```text !decomp /fix:noreturn:FatalError module!FunctionName !decomp /fix:type:rcx=MY_TYPE* module!FunctionName !decomp /fix:field:[rcx+18h]=uint32_t module!FunctionName !decomp /fix:rename:v3=request module!FunctionName !decomp /fix:clear

Puoi copiarli manualmente, oppure usare lo script di supporto.

Prepara una copia vendor da una root del debugger```powershell

powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-DbgengVendor.ps1 ` -SourceRoot 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64'

Una volta che third_party\dbgeng esiste, Build.ps1 lo preferirà automaticamente e di solito non serve DEBUGGERS_ROOT.

Configurazione consigliata per Zydis

Il repository può utilizzare:

• il codice sorgente venduto in third_party\zydis
• FetchContent di CMake

Il comportamento predefinito è auto, che preferisce third_party\zydis quando presente e, in alternativa, scarica Zydis durante la configurazione di CMake.

Layout previsto per il vendoring:```text third_party\zydis\CMakeLists.txt third_party\zydis\include\Zydis\Zydis.h third_party\zydis\dependencies\zycore\CMakeLists.txt

Puoi anche fare il vendor da un albero sorgente locale già scaricato:```powershell powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-ZydisVendor.ps1 ` -SourcePath 'C:\path\to\zydis'

Test di regressione```powershell

cmake --build build --config Debug ctest --test-dir build -C Debug --output-on-failure cmake --build build --config Release ctest --test-dir build -C Release --output-on-failure

Build di release con versione del file DLL con incremento automatico```powershell

powershell -ExecutionPolicy Bypass -File .\scripts\Invoke-ReleaseBuild.ps1

Esempio esplicito di include e libreria```powershell

powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 -Configuration Release -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' -Reconfigure

Compatibilità con dbgeng legacy

Se il tuo dbgeng.h è troppo vecchio e la build fallisce su GetSymbolEntryOffsetRegions o GetSymbolEntryString, usa Build-Legacy.ps1 oppure passa manualmente l'opzione CMake.

Con DECOMP_USE_SYMBOL_ENTRY_APIS=OFF, l'estensione ripiega su:

• GetFunctionEntryByOffset per il recupero degli intervalli basato su unwind per x64
• GetNameByOffset più disassemblaggio euristico se mancano i metadati unwind

Uso dei PDB

L'estensione consuma automaticamente i simboli e le informazioni sui tipi che WinDbg ha già caricato per i moduli di destinazione.

Ci sono due livelli pratici di arricchimento dei PDB:

• fatti tipizzati a livello di modulo: nome della funzione, prototipo, tipo di ritorno, nomi dei simboli globali, offset dei campi, nomi delle costanti enum e suggerimenti per le righe di origine
• fatti a livello di ambito: nomi/tipi di parametri e variabili locali dall'ambito attivo del debugger quando la funzione di destinazione corrisponde all'ambito corrente o quando l'estensione può passare all'ambito dell'ingresso della funzione

Come questo influisce sulla generazione di pseudocodice:

• gli argomenti di registro recuperati possono essere rinominati da nomi euristici come arg1 a nomi PDB come ctx
• le variabili locali di stack possono essere aggiornate da nomi generici di slot a nomi e tipi locali con ambito quando disponibili
• gli accessi alla memoria basati su puntatori possono ricevere suggerimenti di campo come ctx->State
• i confronti simili a enum possono ricevere nomi simbolici come state == StateRunning
• i riepiloghi diretti dei chiamati possono riutilizzare prototipi e tipi di ritorno derivati dai PDB

Limitazioni importanti:

• i PDB pubblici possono fornire nomi di funzioni e alcuni dati sui tipi, ma spesso non includono le variabili locali con ambito
• le build ottimizzate possono rendere i valori e le posizioni delle variabili locali con ambito incompleti o ambigui
• l'estensione tratta i dati PDB come suggerimenti semantici, non come permesso di sovrascrivere il flusso di controllo contraddetto dal disassemblaggio

Il comportamento attuale è automatico. Non esiste un'opzione di configurazione separata per l'uso dei PDB; la qualità dipende da ciò che WinDbg ha già caricato e dal fatto che l'ambito corrente possa essere associato alla funzione di destinazione.

Configurazione

Posiziona decomp.llm.json accanto a decomp.dll.

Questo file non serve solo per le impostazioni di rete dell'LLM.

• provider, endpoint, model, i budget di token e le impostazioni di chunking influenzano il percorso LLM.
• display_language influisce sul linguaggio naturale usato nei riepiloghi e nelle incertezze.
• syntax_highlighting influisce sul rendering dello pseudocodice in WinDbg quando è disponibile un output compatibile con DML.
• display_language e syntax_highlighting sono ancora usati per l'output di /view:analyzer e del mock-provider.

Esempio:```json { "provider": "openai-compatible", "endpoint": "https://api.openai.com/v1/chat/completions", "model": "gpt-5.4-2026-03-05", "api_key_env": "OPENAI_API_KEY", "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, "display_language": { "mode": "auto", "tag": "en-US", "name": "English" }, "syntax_highlighting": { "keyword_color": "warnfg", "type_color": "emphfg", "function_name_color": "srcid", "identifier_color": "wfg", "number_color": "changed", "string_color": "srcstr", "char_color": "srcchar", "comment_color": "subfg", "preprocessor_color": "verbfg", "operator_color": "srcannot", "punctuation_color": "srcpair" } }

Per provider: "chatgpt", endpoint è opzionale e il valore predefinito è https://chatgpt.com/backend-api/codex/responses. È accettato anche un URL di base come https://chatgpt.com/backend-api/codex e viene normalizzato in /responses. L'estensione legge tokens.access_token e tokens.refresh_token dal file di autenticazione configurato, aggiorna i token di accesso JWT scaduti tramite OAuth di OpenAI e riscrive il set di token aggiornato nello stesso file. Il file di autenticazione predefinito è %USERPROFILE%\.codex\auth.json, quindi un accesso ChatGPT della CLI Codex può essere riutilizzato direttamente. L'estensione non apre un browser né avvia un flusso di login OAuth dall'interno di WinDbg; se il file di autenticazione manca, non è valido o non è più aggiornabile, esegui codex login al di fuori di WinDbg e riprova con !decomp. Per test una tantum, usa access_token o access_token_env invece di un file di autenticazione. api_key, api_key_env, DECOMP_LLM_API_KEY e OPENAI_API_KEY sono riservati ai provider compatibili con le API-key OpenAI e vengono ignorati dal provider ChatGPT.

Chiavi supportate:

• provider
• endpoint
• model
• api_key
• api_key_env
• access_token
• access_token_env
• chatgpt_auth_file
• reasoning_effort
• timeout_ms
• max_completion_tokens
• force_chunked
• chunk_trigger_instructions
• chunk_trigger_blocks
• chunk_block_limit
• chunk_count_limit
• chunk_completion_tokens
• merge_completion_tokens
• display_language
• syntax_highlighting

Chiavi display_language supportate:

• mode
• tag
• name

display_language.mode accetta:

• auto
• fixed

Chiavi syntax_highlighting supportate:

• keyword_color
• type_color
• function_name_color
• identifier_color
• number_color
• string_color
• char_color
• comment_color
• preprocessor_color
• operator_color
• punctuation_color

Come funzionano i valori di colore di syntax_highlighting:

• Questi valori sono nomi di slot di colore DML di WinDbg, non nomi di colore RGB fissi o CSS.
• L'estensione li passa a WinDbg DML come <col fg="...">.
• WinDbg risolve ogni nome di slot in base al tema corrente e alle impostazioni colore della finestra dei comandi.
• Per questo motivo, verbfg, warnfg, emphfg, srcid e nomi simili non corrispondono a un unico colore universale su ogni macchina.
• Al momento non esiste una configurazione lato estensione per valori RGB arbitrari come #FF8800. Il colore effettivo arriva da WinDbg, non da decomp.llm.json.

Conseguenza pratica:

• Se un colore di un simbolo risulta troppo scuro in un tema scuro, lo stesso slot potrebbe apparire accettabile su un'altra macchina o con un altro tema di WinDbg.
• Se due slot appaiono quasi identici nel tema corrente, modifica i nomi degli slot in syntax_highlighting invece di supporre che l'estensione stia ignorando la tua impostazione.
• Se ti serve un colore finale davvero diverso, modifica il tema di WinDbg o le impostazioni colore della finestra dei comandi in modo che lo slot stesso venga risolto diversamente.

Quando l'evidenziazione è visibile:

• L'estensione genera pseudo-codice colorato in DML quando WinDbg segnala che i callback di output correnti supportano DML.
• Se il percorso di output corrente del debugger non supporta DML, l'estensione ripiega automaticamente su pseudo-codice in testo semplice.
• L'output /view:json non viene renderizzato in DML. Contiene invece pseudo_c_tokens così gli strumenti esterni possono applicare la propria evidenziazione della sintassi.

Slot di primo piano DML comuni:

• wfg Testo di primo piano predefinito della finestra.
• normfg Testo normale della finestra dei comandi.
• emphfg Testo enfatizzato. Microsoft lo documenta come azzurro chiaro per impostazione predefinita, ma l'aspetto esatto dipende comunque dal tema.
• warnfg Testo di avviso.
• errfg Testo di errore.
• verbfg Testo verbose.
• changed Dati modificati. Microsoft li documenta come rossi per impostazione predefinita.

Slot di primo piano DML comuni orientati al codice sorgente:

• srcnum Costanti numeriche.
• srcchar Costanti carattere.
• srcstr Costanti stringa.
• srcid Identificatori.
• srckw Parole chiave.
• srcpair Coppie di parentesi o simboli corrispondenti.
• srccmnt Commenti.
• srcdrct Direttive.
• srcspid Identificatori speciali.
• srcannot Annotazioni del sorgente o elementi simili ad annotazioni.

Esempi:

• verbfg significa "slot di primo piano Verbose", non "un blu specifico con nome".
• warnfg significa "slot di primo piano Warning", non "sempre giallo o arancione".
• function_name_color: "srcid" significa "renderizza i nomi delle funzioni usando lo slot degli identificatori di WinDbg".

Se stai regolando i colori su un tema scuro:

• Inizia con function_name_color: "emphfg" o function_name_color: "verbfg" se i nomi delle funzioni risultano troppo spenti con srcid.
• Usa identifier_color: "normfg" o identifier_color: "wfg" per i simboli generici che devono rimanere leggibili senza sovrastare le parole chiave.
• Tieni comment_color: "subfg" se vuoi che i commenti restino in secondo piano senza sparire del tutto.

Riferimento ufficiale:

• Comportamento degli slot di colore DML ed esempi: Customizing Debugger Output Using DML
• Classi di messaggi della finestra dei comandi come normal, warning, error e verbose: .printf (WinDbg)

Il file decomp.llm.json.example incluso nel repository contiene solo impostazioni di primo livello valide che l'estensione legge effettivamente.

Esempi solo di riferimento:

Segui la lingua dell'interfaccia del PC:```json { "display_language": { "mode": "auto" } }

Forza coreano:```json { "display_language": { "mode": "fixed", "tag": "ko-KR", "name": "Korean" } }

Preset chiaro di syntax highlighting:```json { "syntax_highlighting": { "keyword_color": "emphfg", "type_color": "warnfg", "function_name_color": "srcid", "identifier_color": "normfg", "number_color": "changed", "string_color": "verbfg", "char_color": "srcchar", "comment_color": "subfg", "preprocessor_color": "srcannot", "operator_color": "wfg", "punctuation_color": "subfg" } }

Quindi valida la modalità LLM:```text !decomp ntdll!RtlAllocateHeap !decomp /view:json ntdll!RtlAllocateHeap !decomp 0x7ffb`12345678

Se il file di autenticazione contiene un refresh token, l'estensione aggiorna un access token scaduto prima di inviare la richiesta. DECOMP_LLM_CHATGPT_ACCESS_TOKEN può essere usato per un token bearer temporaneo, ma il percorso del file di autenticazione è preferibile per le sessioni WinDbg normali perché sopravvive alla scadenza del token. L'estensione non apre mai un browser durante !decomp; esegui codex login fuori da WinDbg quando è necessario un login ChatGPT interattivo.

Esempi di Endpoint LLM Locali

Ollama```powershell

$env:DECOMP_LLM_ENDPOINT = "http://127.0.0.1:11434/v1/chat/completions" $env:DECOMP_LLM_MODEL = "qwen2.5-coder:14b" $env:DECOMP_LLM_API_KEY = "ollama"

Server locale vLLM o compatibile con OpenAI```powershell

$env:DECOMP_LLM_ENDPOINT = "http://127.0.0.1:8000/v1/chat/completions" $env:DECOMP_LLM_MODEL = "Qwen/Qwen2.5-Coder-14B-Instruct" $env:DECOMP_LLM_API_KEY = "local"