Condividi tramite

Determinazione del motivo per cui il riflettore ha terminato il processo host

  • Articolo

Questo argomento descrive come analizzare il motivo per cui il riflettore ha terminato il processo host del driver (WUDFHost.exe) o perché il processo dell'host driver si è arrestato in modo anomalo.

Il motivo più comune per cui il riflettore termina il processo host è la scadenza dei timeout del processo host UMDF.

È consigliabile eseguire tutte le attività di sviluppo e test del driver UMDF con un debugger del kernel collegato al sistema di test e abilitare Application Verifier (AppVerif.exe) in WUDFHost.exe. Usare il comando seguente, collegare un debugger del kernel e quindi riavviare.

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

Uso di file dump

Quando il driver UMDF si arresta in modo anomalo o rileva un problema, nel debugger del kernel verrà segnalata un'interruzione. È consigliabile eseguire il debug di questi problemi quando nel debugger del kernel vengono segnalate eccezioni in modalità utente. Le interruzioni del debugger del kernel vengono segnalate anche da WudfRd.sys prima di terminare un processo host del driver a causa di un driver UMDF problematico (non reattivo). Si troveranno anche i log e i dump dell'heap segnalati nella posizione seguente. Per esaminare i file di dump acquisiti da UMDF, seguire questa procedura:

  1. Individuare il file .dmp più recente nella directory %ProgramData%\Microsoft\WDF. Prima di UMDF 2.15 fornito con Windows 10 1507, la directory di log è in %windir%\system32\LogFiles\WUDF.

  2. Caricare il file .dmp più recente nel debugger usando il comando seguente:

    WinDbg -z <path to the .dmp file>

  3. Esaminare lo stato dei thread al momento della terminazione.

Se sono necessari dump dell'heap acquisiti, al momento del test impostare i valori del Registro di sistema seguenti e riavviare il sistema di test prima di eseguire i test. È anche possibile esaminare Segnalazione errori Windows cronologia dal registro eventi dell'applicazione del sistema in %SystemRoot%\System32\Winevt\Logs\Application.evtx

reg add "HKLM\Software\Microsoft\windows NT\CurrentVersion\Wudf" /v LogMinidumpType /t REG_DWORD /d 0x1122
reg add "HKLM\Software\Microsoft\windows NT\CurrentVersion\Wudf" /v LogEnable /t REG_DWORD /d 1

Uso del debugger

In altri casi, potrebbe essere necessario connettersi a una destinazione in modalità kernel live per determinare il motivo per cui il riflettore ha terminato il processo host. Per configurare la sessione di debug, seguire la procedura descritta in Come abilitare il debug di un driver UMDF.

Dopo aver stabilito una connessione, usare !wdfkd.wdfumtriage per esaminare i driver UMDF, visualizzare i runtime di integrazione in sospeso usando l'estensione del debugger UMDF !wdfkd.wdfumirps (!wudfext.umirps per UMDF versione 1).

  • Se un IRP PnP o un IRP di alimentazione è in sospeso, determinare il motivo per cui il driver causa il blocco di IRP esaminando i thread nel processo host.

    È possibile usare l'estensione !process per esaminare i thread in esecuzione nel processo host. Il valore dei flag 0x1f mostra l'analisi dello stack per ogni thread.

    !process process <addr> 0x1f

  • Se il driver non ha completato rapidamente un IRP annullato, determinare quale IRP è stato annullato e perché non è stato completato.

  • Se un'operazione di pulizia o chiusura di IRP è in sospeso, determinare il motivo per cui l'IRP richiede molto tempo per l'elaborazione.