Scelta del metodo di debug remoto migliore

Esistono due metodi principali per eseguire il debug remoto, nonché diversi metodi aggiuntivi e un numero enorme di metodi di combinazione.

Ecco alcuni suggerimenti per aiutarti a scegliere la tecnica migliore.

• il debug remoto tramite il debugger è in genere il metodo migliore. Se si dispone semplicemente di un server e di un client e possono connettersi liberamente tra loro, gli stessi file binari del debugger vengono installati sia sul client che sul server e il tecnico di debug che funzionerà il client sarà in grado di comunicare con qualcuno nella stanza con il server, questo è il metodo consigliato.

  Il client e il server possono eseguire qualsiasi versione di Windows. Non è necessario che eseguano la stessa versione dell'altra.

  Se il client non è in grado di inviare una richiesta di connessione al server, ma il server è in grado di inviare una richiesta al client, è possibile utilizzare il debugging remoto tramite il debugger con una connessione inversa utilizzando il parametro clicon.

• Debug remoto tramite remote.exe viene usato per controllare in remoto una finestra del Prompt dei Comandi. Può essere usato per controllare in remoto KD, CDB o NTSD. Non può essere usato con WinDbg.

  Se il client non dispone di copie dei file binari del debugger, è necessario utilizzare il metodo remote.exe.

• È possibile utilizzare un server di elaborazione o un server di connessione KD se il tecnico di debug non sarà in grado di comunicare con qualcuno nella stanza con il server. Tutto il lavoro di debug effettivo viene eseguito dal client (denominato smart client); In questo modo viene rimossa la necessità di avere una seconda persona presente nel server stesso.

  I server di elaborazione vengono usati per il debug in modalità utente; I server di connessione KD vengono usati per il debug in modalità kernel. Oltre a questa distinzione, si comportano in modi simili.

  Questo metodo è utile anche se il computer in cui il server sarà in esecuzione non può gestire carichi di processo pesanti o se il tecnico che esegue il client ha accesso ai file di simboli o ai file di origine riservati e non accessibili dal server. Tuttavia, questo metodo non è altrettanto veloce o efficiente del debug remoto tramite il debugger. Questo metodo non può essere usato per il debug di file dump.

  Per informazioni dettagliate, vedere Process Server (modalità utente) e Server di Connessione KD (modalità kernel).

• Un repeater è un server proxy leggero che inoltra i dati tra due computer. È possibile aggiungere un ripetitore tra il client e il server se si esegue il debug remoto tramite il debugger o se si usa un server di elaborazione.

  L'uso di un ripetitore può essere necessario se il client e il server non sono in grado di comunicare direttamente tra loro, ma possono accedere a un computer esterno. È anche possibile usare connessioni inverse con ripetitori. È anche possibile usare due ripetitori in una riga, ma questo è raramente necessario.

  Vedere Ripetitori per informazioni dettagliate.

• È anche possibile controllare CDB (o NTSD) dal debugger del kernel. Si tratta di un'altra forma di debug remoto. Per informazioni dettagliate, vedere Controllo del debugger User-Mode dal debugger del kernel.

Sono possibili variazioni su tutti questi metodi.

È possibile concatenare più computer per sfruttare più di un metodo di trasporto. È possibile creare sequenze di trasporto complesse che tengano conto di dove si trova il tecnico, dove si trovano i simboli e se ci sono firewall che impediscono le connessioni in determinate direzioni. Per alcuni esempi, vedere scenari di debug remoto avanzati.

È anche possibile eseguire il debug remoto in un singolo computer. Ad esempio, potrebbe essere utile avviare un server di elaborazione con privilegi limitati e quindi connettersi a esso con un client intelligente con privilegi elevati.