Combinazione di questo metodo con debug remoto

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.

Importante

Ci sono ulteriori importanti considerazioni sulla sicurezza quando si utilizza il debug remoto. Per ulteriori informazioni, inclusi dettagli su come abilitare la modalità protetta, vedere Security During Remote Debugging e Security Considerations for Windows Debugging Tools.

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 lapsus nella sincronizzazione e questi lapsus possono impedire l'autenticazione del server dei simboli. La configurazione più complessa descritta qui può evitare questo problema.

Nota Nel descrivere questo scenario, 'applicazione di destinazione si riferisce all'applicazione in modalità utente che viene sottoposta a debug, computer di destinazione si riferisce al computer che contiene l'applicazione di destinazione e il processo CDB o NTSD, e computer host si riferisce 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 -ddefer e -server della riga di comando, specificando le opzioni di trasporto desiderate. L'opzione -server deve essere il primo parametro della 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. Avvia WinDbg o KD sul computer host, come se volessi avviare il debug del computer di destinazione, ma senza effettivamente intervenire sul computer di destinazione. Per usare WinDbg, usare la sintassi seguente.

   windbg [-y KernelSymbolPath] [-k ConnectionOptions] 
   

   Per altre informazioni su questo passaggio, vedere Live Kernel-Mode Debugging Using WinDbg (Classic)

   .

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 prompt Input> appare nel debugger del kernel, utilizzare il comando .sleep (Sospendi debugger) per mettere in pausa i debugger e consentire al computer di destinazione di funzionare 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 Modalità di cambio 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; viene chiamato debug in modalità utente controllata da remoto. Quando il debugger in modalità kernel viene inserito nel computer di destinazione e viene visualizzato il prompt Input>, il debugger in modalità utente viene controllato dal debugger del kernel; viene chiamato debug in modalità utente controllato dal kernel.

• Queste due modalità non sono mai disponibili contemporaneamente. Quando si accede al debugger del kernel sul computer di destinazione, anche se il debugger in modalità utente può 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 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 (Sospendi 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 prompt Input>. Se questo prompt non è visibile, passare al debugging in modalità kernel e quindi usare il comando g (Go) al prompt dei kd>.

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