UMDF WdfRequestSend STATUS_FILE_CLOSED

NTDEV
1

All,

I happen to be converting my existing UMDF 2 virtual smart card reader driver into being enumerated by the bus driver of mine. The code now needs to forward the SCardSvr service ioctls into the bus driver. However, the following pseudo-code in the driver’s ioctl handler results in the “CompletionRoutine” being called with the STATUS_FILE_CLOSED failure:

WdfRequestFormatRequestUsingCurrentType(Request);
WdfRequestSetCompletionRoutine(Request, CompletionRoutine, Device);
WdfRequestSend(Request, WdfDeviceGetIoTarget(Device), WDF_NO_SEND_OPTIONS);

The bus driver is never reached. The target’s WdfIoTargetGetState is WdfIoTargetStarted. The WdfRequestGetFileObject of the request is the file object the SCardSvr service opens the SCR driver with. There was neither PFN_WDF_FILE_CLEANUP nor PFN_WDF_FILE_CLOSE on that object, only PFN_WDF_DEVICE_FILE_CREATE. Interestingly enough, the same code works just fine with the UMDF virtual HID driver on the same bus. Sounds like something is different about the file object created by the SCardSvr user mode service as opposed to the hidclass driver? Is there anything extra I need to configure to allow SCR UMDF requests to be forwarded to the local I/O target? The UmdfFileObjectPolicy is set to AllowNullAndUnknownFileObjects but I don’t think it matters here. Any ideas?

Many thanks,

Ilya Faenson
Rockville, MD USA

2

I would like to report that I’ve worked around this issue by terminating Windows user mode requests in the UMDF driver proper and rolling matching WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_FILE based target requests between the UMDF and the bus driver. It is really ugly in my opinion though: this UMDF limitation basically defeats the purpose of the device I/O stack. Oh well, no time to pontificate.

Regards,
Ilya Faenson
Rockville, MD USA