Condividi tramite

Combinazione di questo metodo con debug remoto

  • Articolo

A volte è utile controllare il debugger in modalità utente dal debugger del kernel e usare il debugger in modalità utente come server di debug contemporaneamente.

Ad esempio, questa configurazione è utile quando i simboli in modalità utente si trovano in un server di simboli. Nella configurazione standard per controllare il debugger in modalità utente da un debugger del kernel, l'interazione dei due debugger può portare a piccoli lasso di tempo nella sincronizzazione e questi intervalli possono impedire l'autenticazione del server dei simboli. La configurazione più complessa descritta qui può evitare questo problema.

Nota Nella descrizione di questo scenario, l'applicazione di destinazione fa riferimento all'applicazione in modalità utente di cui viene eseguito il debug, il computer di destinazione fa riferimento al computer che contiene l'applicazione di destinazione e il processo CDB o NTSD e il computer host fa riferimento al computer che contiene il debugger del kernel.

Per usare questa tecnica, è necessario eseguire le operazioni seguenti:

  1. Avviare NTSD o CDB nel computer di destinazione, con le opzioni della riga di comando -ddefer e -server, specificando le opzioni di trasporto desiderate. L'opzione -server deve essere il primo parametro nella riga di comando.

    Ad esempio, è possibile collegarsi a un processo in esecuzione usando la sintassi seguente.

    ntsd -server ServerTransport -ddefer [-y UserSymbolPath] -p PID

    In alternativa, è possibile avviare un nuovo processo come destinazione usando la sintassi seguente.

    ntsd -server ServerTransport -ddefer [-y UserSymbolPath] ApplicationName

    Se si esegue l'installazione come debugger postmortem, usare la sintassi seguente. Si noti che è necessario modificare manualmente il Registro di sistema per installare un debugger postmortem che include il parametro -server; per informazioni dettagliate, vedere Abilitazione del debug postmortem.

    ntsd -server ServerTransport -ddefer [-y UserSymbolPath]

    Per informazioni sulle opzioni di trasporto disponibili, vedere Attivazione di un server di debug.

  2. Avviare WinDbg o KD nel computer host, come se si intendesse eseguire il debug del computer di destinazione, ma non eseguire effettivamente l'interruzione nel computer di destinazione. Per usare WinDbg, usare la sintassi seguente.

    windbg [-y KernelSymbolPath] [-k ConnectionOptions]

    Per altre informazioni su questo passaggio, vedere Debug in modalità kernel live con WinDbg (versione classica)

    .

  3. Avviare WinDbg o CDB come client di debug, con le stesse opzioni di trasporto usate per avviare il server. Questo client di debug può essere eseguito nel computer host o in un terzo computer.

    cdb -remote ClientTransport

    Per altre informazioni su questo passaggio, vedere Attivazione di un client di debug.

  4. Quando i debugger sono in esecuzione e il Input> prompt viene visualizzato nel debugger del kernel, usare il comando .sleep (Pause Debugger) per sospendere i debugger e consentire l'esecuzione del computer di destinazione per alcuni secondi. Ciò consente al computer di destinazione di elaborare il protocollo di trasporto remoto, stabilendo la connessione tra il server remoto in modalità utente e il client remoto.

Se si usa CDB come debugger in modalità utente, la finestra del prompt dei comandi associata a CDB rimane bloccata e non disponibile durante il debug. Se si usa NTSD, non viene creata alcuna finestra aggiuntiva, anche se NTSD ha un ID processo associato nel computer di destinazione.

Le quattro modalità e i metodi di passaggio tra di essi descritti nell'argomento Cambia modalità si applicano in questo scenario di combinazione, con le differenze seguenti:

  • Esistono due diverse modalità di debug in modalità utente. Quando il computer di destinazione è in esecuzione, il server di debug viene controllato dal client di debug come in qualsiasi altra sessione di debug remoto; questa operazione è denominata debug in modalità utente controllata da remoto. Quando il debugger in modalità kernel viene interrotto nel computer di destinazione e viene visualizzato il Input> prompt, il debugger in modalità utente è controllato dal debugger del kernel. Si tratta di debug in modalità utente controllata dal kernel.

  • Queste due modalità non sono mai disponibili contemporaneamente. Quando il debugger del kernel viene interrotto nel computer di destinazione, anche se il debugger in modalità utente potrebbe essere attivo, il computer di destinazione non è in grado di elaborare il protocollo di trasporto remoto e pertanto il debugger in modalità utente non sarà in grado di ricevere l'input remoto attraverso questa connessione.

  • Se i simboli in modalità utente si trovano in un server di simboli, tutti i comandi del debugger che richiedono l'accesso ai simboli devono essere eseguiti in modalità di debug in modalità utente controllata da remoto.

  • Per passare dal debug in modalità utente controllata dal kernel al debug in modalità utente controllata da remoto, usare il comando .sleep (Pause Debugger). Quando il debugger in modalità utente viene riattivato dal comando di sospensione, sarà in modalità di debug in modalità utente controllata da remoto.

  • Per passare dal debug in modalità utente controllata da remoto al debug in modalità kernel, immettere qualsiasi comando dal Input> prompt. Se questo prompt non è visibile, passare al debug in modalità kernel e quindi usare il comando g (Go) al kd> prompt.

Internamente, un debugger in modalità utente avviato con -ddefer assegna la prima priorità all'input dal client di debug e la seconda priorità all'input del debugger del kernel. Tuttavia, non può mai verificarsi un conflitto tra gli input simultanei, perché quando il debugger del kernel si è interrotto nel computer di destinazione, la connessione remota non è disponibile.