Determining Why an Application Request Does Not Complete
This topic describes how you can use the Wudfext.dll debugger extensions in conjunction with a User-Mode Driver Framework (UMDF) version 1 driver to determine why an application request does not complete.
Starting with UMDF version 2, you should instead use the Wdfkd.dll debugger extensions. For more info, see Windows Driver Framework Extensions (Wdfkd.dll).
You can perform the following steps to determine why an application request does not complete:
Use the !wudfext.umirps UMDF debugger extension to display all the outstanding user-mode I/O request packets (IRPs) in the host process. The information for each user-mode IRP includes the original kernel-mode IRP for which the user-mode IRP was created.
Determine the user-mode IRP that corresponds to the kernel-mode IRP that the application originated.
Use the !wudfext.umirp UMDF debugger extension as shown in the following example to obtain information about a particular user-mode IRP:
The information for the user-mode IRP includes the stack locations. If you know the stack locations, you can determine where the IRP is being processed. Stack location 0 represents the stack below UMDF (that is, the kernel-mode stack or some other sub-system, such as Microsoft Win32 or Winsock).
- If the IRP is at your driver's layer (that is, the layer in which your driver processes the IRP), perform the following steps:
View the I/O queues that are set up at your driver's layer. You can use the !wudfext.wudfdevicequeues UMDF debugger extension to view all the I/O queues that are set up at your driver's layer. You can also use the !wudfext.wudfqueue UMDF debugger extension as shown in the following example to obtain information about a particular queue:
- If there are multiple requests outstanding, you can use the !wudfext.wudfrequest UMDF debugger extension to obtain information about a request, which includes the underlying user-mode IRP. From the user-mode IRP information, you can determine the request that you are interested in.
- Verify whether the request is owned by a queue or by the driver. This information is displayed as part of the output from the !wudfext.wudfqueue UMDF debugger extension. Perform one of the following verifications depending on whether the queue or the driver owns the request:
- If the request is owned by the queue, check the state of the queue to determine why the queue did not deliver the request to the driver.
- If the request is owned by the driver, check the threads in the host process to determine if a thread became stuck or deadlocked while processing the request.
If the IRP is at another UMDF driver layer, you can repeat the preceding steps for that layer. Remember that the !wudfext.umdevstack UMDF debugger extension shows information about all stack layers.
If the IRP is beyond the UMDF stack (for example, if stack location 0 is where the IRP is currently being processed), determine why the corresponding kernel-mode IRP did not complete.
Build date: 11/16/2013