Freigeben über

Ermitteln, warum der Reflektor den Hostprozess beendet hat

  • Artikel

In diesem Thema wird beschrieben, wie Sie analysieren können, warum der Reflektor den Treiberhostprozess (WUDFHost.exe) beendet hat oder warum der Treiberhostvorgang abgestürzt ist.

Der häufigste Grund für den Reflektor, den Hostprozess zu beenden, ist der Ablauf von UMDF-Hostprozesstimeouts.

Es wird dringend empfohlen, alle Entwicklung und Tests Ihres UMDF-Treibers mit einem Kerneldebugger durchzuführen, der an das Testsystem angefügt ist, und anwendungsprüfer (AppVerif.exe) auf WUDFHost.exe zu aktivieren. Verwenden Sie den folgenden Befehl, fügen Sie einen Kerneldebugger an, und starten Sie dann neu.

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

Speichern von Dumpdateien

Wenn der UMDF-Treiber abstürzt oder ein Problem auftritt, wird im Kerneldebugger ein Unterbrechungswechsel gemeldet. Diese Probleme sollten gedebuggt werden, wenn Ausnahmen im Benutzermodus im Kerneldebugger gemeldet werden. Kerneldebuggerunterbrechungen werden auch von WudfRd.sys gemeldet, bevor ein Treiberhostprozess aufgrund eines problematischen (nicht reaktionsfähigen) UMDF-Treibers beendet wird. Außerdem finden Sie Protokolle und Heapabbilder, die am folgenden Speicherort gemeldet wurden. Führen Sie die folgenden Schritte aus, um die von UMDF erfassten Abbilddateien zu überprüfen:

  1. Suchen Sie die neueste .dmp Datei im Verzeichnis %ProgramData%\Microsoft\WDF. Vor UMDF 2.15, die mit Windows 10 1507 ausgeliefert wurden, befindet sich das Protokollverzeichnis unter %windir%\system32\LogFiles\WUDF.

  2. Laden Sie die neueste .dmp Datei mithilfe des folgenden Befehls in den Debugger:

    WinDbg -z <path to the .dmp file>

  3. Sehen Sie sich den Status der Threads zum Zeitpunkt der Beendigung an.

Wenn Heapabbilder erfasst werden müssen, legen Sie zum Zeitpunkt des Tests die folgenden Registrierungswerte fest und starten Das Testsystem vor dem Ausführen von Tests erneut. Sie können auch Windows-Fehlerberichterstattung Verlauf aus dem Anwendungsereignisprotokoll des Systems unter %SystemRoot%\System32\Winevt\Logs\Application.evtx untersuchen.

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

Verwenden des Debuggers

In anderen Fällen müssen Sie möglicherweise an ein Ziel im Live-Kernelmodus anfügen, um zu bestimmen, warum der Reflektor den Hostprozess beendet hat. Führen Sie zum Einrichten der Debugsitzung die unter How to Enable Debugging of a UMDF Driver beschriebenen Schritte aus.

Nachdem Sie eine Verbindung hergestellt haben, verwenden Sie !wdfkd.wdfumtriage, um die UMDF-Treiber zu untersuchen, zeigen Sie die ausstehenden IRPs mithilfe der UMDF-Debuggererweiterung !wdfkd.wdfumirps (!wudfext.umirps für UMDF, Version 1) an.

  • Wenn ein PnP-IRP oder ein Strom-IRP aussteht, bestimmen Sie, warum der Treiber das IRP hängen lässt, indem Sie Threads im Hostprozess untersuchen.

    Sie können die Erweiterung !process verwenden, um die Threads zu untersuchen, die im Hostprozess ausgeführt werden. Der Wert für 0x1f Flags zeigt Ihnen die Stapelablaufverfolgung für jeden Thread an.

    !Prozess-Addr-0x1f <>

  • Wenn Ihr Treiber ein abgebrochenes IRP nicht schnell abgeschlossen hat, bestimmen Sie, welche IRP abgebrochen wurde und warum es nicht abgeschlossen wurde.

  • Wenn ein Bereinigungs- oder Schließ-IRP aussteht, bestimmen Sie, warum das IRP lange dauert.