Condividi tramite


Come abilitare il debug di un driver UMDF

È possibile usare le configurazioni seguenti per eseguire il debug di un driver User-Mode Driver Framework (UMDF) durante lo sviluppo. Tutte le configurazioni coinvolgono due computer, un host e una destinazione.

  • Copiare manualmente il driver nella destinazione. Eseguire il debug in modalità utente nella destinazione. In questo scenario si esegue manualmente il collegamento a un'istanza del processo host del driver in esecuzione nella destinazione.
  • Copiare manualmente il driver nella destinazione e quindi eseguire il debug in modalità kernel dall'host.

È consigliabile eseguire tutti i test e lo sviluppo di driver UMDF con un debugger del kernel collegato.

Procedure consigliate

È consigliabile eseguire tutti i test dei driver UMDF con un debugger del kernel collegato.

Di seguito sono riportate le impostazioni consigliate. È possibile impostarli manualmente oppure usare lo strumento WDF Verifier Control Application (WDFVerifier.exe) in WDK per visualizzare o modificare queste impostazioni.

  • Abilitare Application Verifier in WUDFHost.exe:

    AppVerif –enable Heaps Exceptions Handles Locks Memory TLS Leak –for WudfHost.exe
    

    Se si verificano eccezioni, Application Verifier invia messaggi di diagnostica al debugger e si interrompe.

  • Se si usa una sessione di debug in modalità kernel, impostare HostFailKdDebugBreak in modo che il riflettore si interrompa nel debugger in modalità kernel prima di terminare il processo host del driver. Questa impostazione è abilitata per impostazione predefinita a partire da Windows 8.

  • Disabilitare il pooling impostando UmdfHostProcessSharing su ProcessSharingDisabled. Per informazioni, vedi Specifica delle direttive WDF nei file INF.

  • Per impostazione predefinita, quando un dispositivo UMDF ha esito negativo, il framework tenta di riavviarlo fino a cinque volte. È possibile disattivare il riavvio automatico impostando DebugModeFlags su 0x01. Per altre informazioni, vedi Valori del Registro di sistema per il debug dei driver WDF.

  • Riavviare il computer.

  • Per i problemi relativi al debug del driver UMDF, vedere Determinare perché il reflector ha terminato il processo host e il debug di arresti anomali del driver UMDF

Uso di WinDbg per collegarsi manualmente (debug in modalità utente)

Nel computer di destinazione è possibile collegare manualmente WinDbg all'istanza di WUDFHost che ospita il driver. Quando si esegue il collegamento, si esegue l'interruzione nel debugger ed è possibile impostare punti di interruzione nel driver.

Poiché l'inizializzazione del driver si verifica poco dopo il caricamento di WUDFHost, non è possibile collegarsi manualmente nel tempo per eseguire il debug del codice di inizializzazione. È invece possibile impostare un valore del Registro di sistema per fare in modo che il processo host attenda alcuni secondi durante l'inizializzazione dell'host o il tempo di caricamento del driver. Questo ritardo consente di collegare WinDbg all'istanza corretta del processo WUDFHost.

Seguire questa procedura:

  1. Nel Registro di sistema nel computer di destinazione impostare HostProcessDbgBreakOnStart o HostProcessDbgBreakOnDriverLoad su un numero di secondi e riavviare.
  2. Nel computer di destinazione aprire WinDbg come amministratore.
  3. Scegliere Connetti a processo dal menu File. Selezionare By Executable (Eseguibile) e individuare tutti i processi denominati WUDFHost.exe (potrebbero non essere presenti). Se sono presenti processi denominati WUDFHost.exe, annotare gli identificatori di processo per riferimento futuro.
  4. In Gestione dispositivi abilitare il driver.
  5. Ripetere il passaggio 2 e individuare una nuova istanza di WUDFHost.exe. Se non viene visualizzata una nuova istanza di WUDFHost.exe, fare clic su Annulla e scegliere di nuovo Connetti a processo . Quando si trova la nuova istanza di WUDFHost.exe, selezionarla e fare clic su OK.

Se il pool di dispositivi è in uso e si imposta il valore del Registro di sistema HostProcessDbgBreakOnDriverLoad , è possibile che vengano visualizzate interruzioni del debugger a causa del caricamento di altri driver. È possibile disattivare il pool di dispositivi usando la modalità di debug UMDF.

Per usare la modalità di debug, usare l'opzione F5 in Visual Studio oppure impostare i valori DebugModeFlags e DebugModeBinaries nel Registro di sistema.

Per informazioni dettagliate sui valori del Registro di sistema UMDF, vedere Valori del Registro di sistema per il debug dei driver WDF (KMDF e UMDF).

Uso di WinDbg per eseguire il debug remoto da un computer host (debug in modalità kernel)

Da un host remoto stabilire una sessione di debug in modalità kernel e quindi impostare il processo corrente sull'istanza di Wudfhost che ospita il driver. Se si esegue il debug da un debugger del kernel remoto, è possibile impostare HostProcessDbgBreakOnDriverStart o HostProcessDbgBreakOnDriverLoad su 0x80000000 per non specificare alcun timeout, ma interrompere il debugger del kernel.

Usare i passaggi seguenti:

  1. Disabilitare il pooling. attivare DebugModeFlags ed elencare il driver in DebugModeBinaries

  2. Se il driver usa UMDF 1.11 o versione successiva, HostFailKdDebugBreak è abilitato per impostazione predefinita. Ignorare questo passaggio.

    Se il driver usa UMDF 1.9 o versioni precedenti, impostare HostFailKdDebugBreak su 1.

  3. Se si verificano problemi di debug correlati ai timeout, disattivare HostProcessDbgBreakOnDriverStart e HostProcessDbgBreakOnDriverLoad. Quando HostProcessDbgBreakOnDriverStart o HostProcessDbgBreakOnDriverLoad è diverso da zero, il framework disabilita i timeout in modo che il reflector non termini l'host mentre un debugger in modalità utente è collegato al processo host. Se è necessario eseguire il debug del codice di inizializzazione del driver, invece di usare questi due valori, provare a eseguire il comando seguente in WinDbg prima del caricamento del driver: sxe ld:MyDriver.dll (interruzione al caricamento del modulo)

  4. Riavviare se sono state apportate modifiche al Registro di sistema.

  5. A seconda delle selezioni effettuate in precedenza, il debugger del kernel remoto dovrebbe interrompersi quando il driver carica o scarica nella destinazione.