Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Dear All,
I am try to enable and disable one particular USB interface on USB composite device from device manager. The interface has function driver(driver1) and lower filter driver(driver2). Issue is device manager getting hanged indefinitely, using notmyfault crashed system to get dump, corresponding to drivers two threads are in blocked state. Thread-1 from driver1, synchronously sending vendor request to device which goes through lower filter driver, lower filter driver2 receives on EvtIoWrite this request is again framed and sent to lower level, lower level is waiting on "KeWaitForSingleObject" indefinitely , even though timeout value is set.
I am trying to see arguments passed to KeWaitForSingleObject function, since timeout value is 5th argument, I want to make sure timeout is set. I am assuming 5th argument is pushed to stack.
when checked value it is showing "zero", this issue I am checking on windows 10 x64, quite difficult to get assured value. kindly please let me know how to debug this issue.
1) why request is not completed even though timeout value is set?
2) how to view 5th argument in case of x64( value stored on stack is assured?).
ffffdd07
73496000 fffff802
6f1c908d : ffff88019f744180 00000004
fffffffe ffff8801ffffffff 00000000
00000001 : nt!KiSwapContext+0x76
ffffdd0773496140 fffff802
6f1c7f14 : ffffc704bb549040 00000000
00000000 ffffde8000000000 ffffde80
00000000 : nt!KiSwapThread+0xbfd
ffffdd07734961e0 fffff802
6f1c76b5 : 0000000000000000 fffff802
00000000 ffffdd0773498000 00000000
00000000 : nt!KiCommitThreadWait+0x144
ffffdd0773496280 fffff802
6fa2f9f4 : ffffdd0773496430 00000000
00000000 0000000000000000 00000000
00000000 : nt!KeWaitForSingleObject+0x255
ffffdd0773496360 fffff802
6fa2ee6e : ffffdd0773496430 00000000
00000102 ffffdd0773496470 00000000
0000001d : nt!ViKeWaitForSingleObjectCommon+0x984: kd> dqs ffffdd07`73496360
ffffdd07
73496360 ffffdd07
73496430ffffdd07
73496368 00000000
00000000ffffdd07
73496370 00000000
0000000ffffdd07
73496378 00000000
00000000ffffdd07
73496380 00000000
00000000----> is it 5th argument timeout value for "KeWaitForSingleObject" ?ffffdd07
73496388 ffffdd07
73496400ffffdd07
73496390 00000000
0000001d
Thread -1 sent synchronous request which is not getting completed, Thread-2( PNP remove) waiting on Thread-1 handle to get terminate. That's why device manager is not hanged.
WDF_WRITE_REQUEST_TIMEOUT 1 WDF_REQUEST_SEND_OPTIONS_INIT(&options,WDF_REQUEST_SEND_OPTION_TIMEOUT | WDF_REQUEST_SEND_OPTION_SYNCHRONOUS); WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&options,WDF_ABS_TIMEOUT_IN_SEC(WDF_WRITE_REQUEST_TIMEOUT) WdfRequestSend(wdfRequest, deviceContext->UsbDeviceIoTargets, &options);
SEND_ENCAP_REQ_TIMEOUT 1 WDF_REQUEST_SEND_OPTIONS_INIT(&requestSendOptions, WDF_REQUEST_SEND_OPTION_TIMEOUT); WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&requestSendOptions, WDF_REL_TIMEOUT_IN_SEC(SEND_ENCAP_REQ_TIMEOUT)); WdfUsbTargetDeviceSendControlTransferSynchronously( pDeviceContext->UsbContext.UsbDevice,WDF_NO_HANDLE, &requestSendOptions,&usbControlSetupPacket,&memoryDescriptor,&numberOfBytesTransferred);
thread-1 and thread-2 stacks are attached.
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 9-13 Sept 2024 | Live, Online |
Developing Minifilters | 15-19 July 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 20-24 May 2024 | Live, Online |
Comments
(Not a WinDbg issue... Moved to NTDEV.... where the right people are likely to read it).
Peter Viscarola
OSR
@OSRDrivers
You have the sources for the driver? And a PDB? Can you just not look the the locals?
Sorry... I know that sounds simple, but...
Peter
Peter Viscarola
OSR
@OSRDrivers
@Peter_Viscarola_(OSR) thank you for reply ,
I have PDB files related to driver1 and driver2, I saw local variables, timeout value is set.
when I try to see KeWaitForSingleObject local variables it is saying private symbols.
I am sharing local variables for requests sent by two drivers driver1 and driver2.
Driver2:
Driver1:
Source where timeout is set for driver1 and driver2.
Thread-1 WdfRequestSend driver1
Thread-1 WdfUsbTargetDeviceSendControlTransferSynchronously driver2
The source code for KMDF is all publicly available. We have to trust that your code actually looks like you posted, but if it did, then the KMDF code would have passed a timeout to KeWaitForSingleObject, Can you cut-and-paste the exact code?
Tim Roberts, [email protected]
Software Wizard Emeritus
@Tim_Roberts thanks for your reply I have download WDF framwork and synched with windbg.
I am attaching source "Thread1&Thread2_functions.txt" as well. code is trimmed.
from windbg I tried see local variables. struct _WDF_REQUEST_SEND_OPTIONS * Options = .
Have you dumped the log with !wdflogdump ?
Let’s assume the timeout is working. In that case, after the timeout, your Request will be canceled. Perhaps the lower driver isn’t completing the Request... or ?
Peter
Peter Viscarola
OSR
@OSRDrivers
So, the timeout is set correctly, and the request does have a status value of STATUS_TIMEOUT. Now, do you understand that STATUS_TIMEOUT is a positive value, and hence will be seen as a success code by NT_SUCCESS? Is it possible that you are continuing to send more requests because you don't realize there's a problem? Sending another request after a USB request has timed out can cause issues like the one you see.
Tim Roberts, [email protected]
Software Wizard Emeritus
@Peter_Viscarola_(OSR) , !wdflogdump. I will go through the logs, I am matching with driver flow. will update soon.
how can to get notified wdf request cancelled ? in this case "WdfUsbTargetDeviceSendControlTransferSynchronously " will not return? I take your comment as reference and go through WDF source code "FxIoTarget::SubmitSync". There is issue with device whatever control request sent reponse is not coming, code is like it will try couple of times based on retry machanism, i will check lower level also if request is still pending with bus driver
@Tim_Roberts @Peter_Viscarola_(OSR) with help your comments, i am able to understand how wdf framework sending IRP to lower level drivers. looks like the wdf request after timeout, getting cancel, which is not getting completed(cancel) by lower level driver. In wdf framwork its waiting for cancel. currently looking into lower level drivers.