Question Regarding Multiple Device Interfaces

NTDEV
21

I had time to look at the code you posted…

LxEvtFileCleanup
KMDF will automatically cancel all i/o with the file object being cleaned up for you. The purge might be more of the semantic you want, but i wanted to let you know that KMDF does work for you here.

fileContext->pDataQueue
Why are you storying the pointer to the queue handle? it is just a handle, you can store the value itself. That way you don’t have to dereference it and you don’t have to compare addresses (pDataQueue == &pDeviceContext->BeadDataQueue), rather you can compare ordinal values (dataQueue == pDeviceContext->BeadDataQueue)

WdfRequestGetFileObject returning a NULL handle in LxEvtIoRead (and any other callback for that matter)
you should never have to check for NULL, the file object will always be there if you are receiving handle based i/o (e.g. from an application). The only time you may have to check for NULL is if another driver is sending you I/O (that is the only way it could possibly not be in the PIRP), but even then, the sending driver has a bug in it if it doesn’t properly format the IRP before sending it to your driver.

Same goes for GetFileObjectContext, it will never return NULL if you setup the file object config properly during device init

LxEvtIoRead
You will double complete the request in the path where WdfRequestForwardToIoQueue fails since status will != STATUS_PENDING, so you complete the request the first time immediately after the !NT_SUCCESS check and then again at the bottom of the function at the status != STATUS_PENDING check.

additionally, you could easily fold the pDataQueue check into

if (pDataQueue == NULL) { complete with error }
else { forwardtoqueue(request, *pDataQueue); }

without checking which queue you are forwarding to.

Overall, i see nothing wrong with the initialization of your device or how you are setting up your queues (WdfDeviceConfigureRequestDispatching is not a problem here). Again, I think you need to look at your application since the framework does not represent I/O on cancellation…I do wonder how the application will know which instance of the GUID_CLASS_LX_DETECTOR device interface will be associated with status data or bead data since the device interface string is supposed to be opaque. I would have thought that you would have used 2 different GUIDs, this way the app enumerates both interfaces and definitively knows which interface instance has what i/o contract.

d

22

Doron, I found the problem. It was in an obscure area of the application and was being caused because I was pointing to an old version of the dll. So, the code that I was changing was changing but there was still an Old Dll using an old version of the code which was in fact sending down those requests.

And the reason for keeping the guid really has to do with legacy support for old hardware and drivers. The Goal here is that the application should still work with the old drivers. Although this may not have been the best, I think it will work fine. This Application has to work with previous generations. By using the same GUID, If this driver is present, I will see the device Interface Strings (symbolic links). If these are present, I know which version of the driver is present and the application can just append the interface string when opening the device (using CreateFile). It seemed logical to me at the time, however your method may be better for future use.

I appreciate you taking the time to answer my questions as you have saved me a ton of time. With the schedule we have been on, every bit helps. I would have figured it all out eventullay on my own but it would have taken more time.

Best Regards,
Brad

23

reference strings don’t work that way. they are transparent to the application, read http://blogs.msdn.com/doronh/archive/2006/08/18/706717.aspx on how to use reference strings.

In your scheme where you register the device interface GUID with a reference string and then append the reference in the application, the file name being passed to the driver during create would be \ + LX_BEAD_DATA_INTERFACE + . Instead a better way to do this would be to register the device interface GUID once without a reference string and then have the application append the correct ref string as it does today, and then in your create callback you will get the filename \ + . The KMDF sample usbsamp demonstrates this technique (to be able to address different endpoints with different file handles).

d