Scelta del miglior metodo di debug remoto
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 ha semplicemente un server e un client e possono connettersi liberamente tra loro, gli stessi file binari del debugger vengono installati sia sul client che sul server e sul server e il tecnico di debug che sarà in grado di operare il client sarà in grado di parlare con qualcuno nella stanza con il server, questo è il metodo consigliato.
Il client e il server possono eseguire qualsiasi versione di Windows. Non devono eseguire 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 usare il debug remoto tramite il debugger con una connessione inversa usando il parametro clicon .
Il 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 usare il metodo remote.exe.
Un server di elaborazione o un server di connessione KD può essere usato se il tecnico di debug non sarà in grado di parlare con qualcuno nella stanza con il server. Tutto il lavoro di debug effettivo viene eseguito dal client (denominato client intelligente); ciò rimuove 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 possono essere accessibili dal server. Tuttavia, questo metodo non è più veloce o efficiente come il debug remoto tramite il debugger. Questo metodo non può essere usato per il debug di file dump.
Per informazioni dettagliate, vedere Server di elaborazione (modalità utente) e server di connessione KD (modalità kernel).
Un ripetitore è 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 inversa con ripetitori. È anche possibile usare due ripetitori in una riga, ma questo è raramente necessario.
Per informazioni dettagliate, vedere Ripetitori .
È 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 di User-Mode dal debugger del kernel .
Le variazioni su tutti questi metodi sono possibili.
È possibile concatenare diversi computer insieme per sfruttare più di un metodo di trasporto. È possibile creare sequenze di trasporto complesse che tengano conto della posizione del tecnico, dove si trovano i simboli e se esistono firewall che impediscono 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.