Hello Tim,
I ran !wdftagtracker FFFFF98009CF4BD0 command and it pointed to some
FxTimer. There is a timer in my driver which is used to retry requests
periodically. The timers are created in the EvtIoRead function and the
parent was set to the request.
// Initialize the read-timer
WDF_TIMER_CONFIG_INIT(&timerConfig,Usb_EvtTimerFunc);
timerConfig.AutomaticSerialization = TRUE;
timerConfig.Period = 0;
WDF_OBJECT_ATTRIBUTES_INIT(&timerAttributes);
timerAttributes.ParentObject = Request;
status = WdfTimerCreate(&timerConfig, &timerAttributes,
&(deviceContext->timerRead));
if (!NT_SUCCESS (status))
{
DEBUG_PRINT(“WdfTimerCreate failed 0x%x\n”, status);
goto Exit;
}
else
{
DEBUG_PRINT(“WdfTimerCreate Success 0x%x\n”, status);
}
After that in the ReadCompletion callback if i did not get data, I start
this timer with a delay(around 10ms). That will reuse the request and send
it to the device again.
I removed this code which miraculously made the driver working (working
means in the HCK, eventhough the previous implementation failed in the HCK
it was working well with the appications). I cannot understand why and how
that is possible.
Then I moved this timer creation to EvtDriverAdd event. And kept it in the
device context. This way the HCK test is fine but the driver is really
slow. There are many unknowns now. Why didn’t work and why now working.
Is there anything wrong in my approach? The driver read slowing down is a
big concern.
On a side note,
Since I reuse request in the EvtTimerFunc I need to get the handle of the
Request. Since the parent of the ‘Timer’ is the ‘Device’ I can get the
DeviceContext within the EvtTimerFunc function.
In the current code I’m storing the Request handle in the device context
and retrieving it in the EvtTimerFunc. Is there a better way to achieve
this? Also is there an API to check the validity of a Request?
-Pradeepa
On Fri, Oct 3, 2014 at 10:19 PM, Tim Roberts wrote:
> Pradeepa Senanayake wrote:
>
> Tim Roberts wrote:
>
>>
> You hit an assertion failure in KMDF. You dumped a bunch of KMDF stuff,
>> but not the in-flight recorder log that should tell you what the assertion
>> was.
>>
>> So, do:
>> !wdftmffile \your-ddk-path\tools\tracing\amd64\wdf01009.tmf
>> !wdflogdump ustp2
>>
>
>
> This is the output I got,
>
> 3: kd> !wdflogdump ustp2
> Trace searchpath is:
> …
> 34: FxIoQueue::CancelForQueue - WDFREQUEST 0x0000067FFAB271C8 was
> cancelled while on WDFQUEUE 0x0000067FFCF2D3A8
> 35: FxIoQueue::CancelForQueue - WDFREQUEST 0x0000067FFAA631C8 was
> cancelled while on WDFQUEUE 0x0000067FFCF2D3A8
> 36: FxTagTracker::UpdateTagHistory - releasing tag 0000000000000000 on
> object FFFFF98009CF2E30 that was not acquired, !wdftagtracker
> FFFFF98009CF4BD0
> ---- end of log ----
>
> I cannot quite understand what is happening here.
>
>
> No, I can’t either. It’s referring to a tag failure on an object, but the
> object it’s referring to would be handle 67FF620D1C8, and that is not
> mentioned in the log. We may need a KMDF guru to step in here.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>