u

NTDEV
1

Hello again,

another problem raises during development of our USB UMDF driver.

Last time I asked about intercommunication between application and driver (http://www.osronline.com/showthread.cfm?link=200804), which leads to the use of overlapped file operations.

These operations are now implemented, but with the new implementation the driver stops completely its work, when running the scenario with the interrupt pipe.

I show you the affected code (focussed on the essentials)

MyControlQueue::OnDeviceIoControl()
> MyDriver::ReadIntPipe()
> Device->CreateRequest()
> Driver->CreatePreallocatedWdfMemory();
> UsbIntPipe->FormatRequestForRead();
> Request->SetCompletionCallback(this, 0);
> Request->Send(UsbInterruptPipe, 0, 0);
…
<
<

MyDriver::OnCompletion()
…
> Request->CompleteWithInformation(Params->GetCompletionStatus(), Params->GetInformation());

And this is the location, where the driver stops its work.

After a long debugging session on the test computer I found out, what happens. First I thought, there were a wrong implementation in the application, but at least I could see in the debugging windows (memory, calls, disassembly), that inside the function WUDFx!CWdfIoRequest::CompleteWithInformation there was called a WUDFx!WudfVerify() function with the string “Driver created request can’t be completed by the same layer as the one that created it”, which leads to CPlatform::UmdfDriverStop and so on.

Now I have the following questions:

  1. What does this error string mean? I had a look in the ddk umdf examples (biometrics and osrusbfx2), but they work in a similar manner.

  2. It would be very helpful to make these WudfVerify() exception visible (including the strings declaring the error). Either in DebugView or in WinDbg or in TraceView … is this possible? Was really a pain to debug three days and use even the disassembly and memory window to see the verify string!

Many thanks in advance,
Tristan.

2

It means that your driver can’t call WdfRequestComplete on a Request that it created with WdfRequestCreate. The good news is that there’s no NEED for you to complete such a Request. You merely delete it.

Remember the Prime Directive of WDF Request Handling: Your driver MUST complete any WDFRequest presented to it (unless the Request is sent to another driver using SEND_AND_FORGET or the Request is automatically cancelled by WDF while on a Queue). This Request was NOT presented to you, you created it, therefore the driver to which you SENT it completes it and you just delete it.

Usually, in KMDF at least (I am *so* not a UMDF developer) the easy and painless way to debug these things is to view the WDF log.

Peter
OSR