Determining Why the Reflector Terminated the Host Process
You can use the following techniques to analyze why the reflector terminated the driver host process (WUDFHost.exe).
For many crashes, dump file details are sufficient to determine why the termination occurred. To review dump file information, follow these steps:
Locate the latest .dmp file in the %windir%\system32\LogFiles\WUDF directory.
- Load the latest .dmp file into the debugger by using the following command:
WinDbg -z <path to the .dmp file>
Look at the state of the threads at the time of termination.
In other cases, attaching a kernel debugger is necessary.
When the registry value HostFailKdDebugBreak is set to 1, the UMDF reflector breaks into the kernel debugger before terminating the host process. The reflector also breaks into the kernel debugger if there is an unexpected termination of the host process (e.g. by a non-UMDF component or due to an unhandled exception). If there are multiple device stacks pooled in the host process that is being terminated, the reflector breaks into the debugger multiple times, once for each device stack loaded in the host process. Starting in UMDF version 1.11, HostFailKdDebugBreak is enabled by default.
To determine why the reflector terminated the host process, use the following steps:
If your driver uses UMDF 1.9 or earlier, locate HostFailKdDebugBreak under the following key in the registry, and set it to 1.
We recommend that you enable Application Verifier on WUDFHost.exe while testing or debugging your UMDF driver:
AppVerif –enable Heaps Exceptions Handles Locks Memory TLS Leak –for WudfHost.exe
When the reflector breaks into the debugger, attach to the driver host process for the device (WUDFHost.exe). For more information about attaching to or breaking into WUDFHost.exe, see Determining the State of a UMDF Device.
Starting in UMDF version 1.11, before breaking into the kernel debugger, the reflector automatically switches the process context to that of the host process. As a result, you can use UMDF debugger extension commands immediately, without first issuing the .process command to change the process context.
- Display the outstanding IRPs by using the !wdfkd.wdfumirps UMDF debugger extension (!wudfext.umirps for UMDF version 1). Use one of the following possible outputs from the debugger extension to troubleshoot:
If a PnP IRP or a power IRP is pending, determine why the driver causes the IRP to hang by examining threads in the host process.
You can use the !process extension to examine the threads running in the host process, as follows:
!process <process addr> 0x1f
- If your driver has not completed a canceled IRP quickly, determine which IRP was canceled and why it has not completed.
- If a cleanup or close IRP is pending, determine why the IRP is taking a long time to process.
Build date: 11/16/2013