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

Questo argomento descrive come analizzare il motivo per cui il riflettore ha terminato il processo host del driver (WUDFHost.exe) o perché il processo host del 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 dei file di 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 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 hai bisogno di acquisire dump dell'heap, durante il testing imposta i seguenti valori del Registro di sistema e riavvia il sistema di test prima di eseguire i test. È anche possibile esaminare la cronologia segnalazione errori Windows 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 attaccarsi a un obiettivo in modalità kernel live per determinare il motivo per cui il riflettore ha terminato il processo host. Per configurare la sessione di debug, seguire i passaggi descritti in Come abilitare il debug di un driver UMDF.

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

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

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

  !process<process addr>0x1f

• Se il driver non ha completato rapidamente un IRP annullato, determina quale IRP è stato annullato e il motivo per cui 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.