Resuming EvtIOWrite after device restart

NTDEV
1

Hi,

We are working on USB serial driver using KMDF.

Currently facing issue with communication restore.

Here, test application is opening the com port it got from the driver,
after opening trying to send/write continuous data to the USB device,
in the mean time I restart the USB device, the driver is not getting the write events from the already running test application (i.e. my EvtIOWrite is not getting called second time)

But If I manually exit the “test application” and restarted again, communication is getting resumed.

Do I need to change anywhere for retaining the session from the application?
w.r.t IRP_MJ_CLOSE and IRP_MJ_CREATE ?

Here is my code:
Adddevice:
ntstatus = WdfDeviceInitAssignWdmIrpPreprocessCallback(
DeviceInit,
UsbWdmDeviceFileCreate,
IRP_MJ_CREATE,
NULL, // pointer minor function table
0); // number of entries in the table

ntstatus = WdfDeviceInitAssignWdmIrpPreprocessCallback(
DeviceInit,
UsbWdmFileClose,
IRP_MJ_CLOSE,
NULL, // pointer minor function table
0); // number of entries in the table

In both callbacks UsbWdmDeviceFileCreate and UsbWdmFileClose,
I am just completing the IRP received with status success.

Rest of my AddDevice Callback is:

ntstatus = RtlUnicodeStringPrintf(&deviceName, L"%ws%d",
L"\Device\USBTEST",
currentInstance++);

WdfDeviceInitAssignName(DeviceInit,&deviceName);

WdfDeviceInitSetExclusive(DeviceInit, TRUE);

WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_SERIAL_PORT);

WdfDeviceInitSetRequestAttributes(DeviceInit, &attributes);
.
.
.
WdfDeviceInitAssignWdmIrpPreprocessCallback
WdfDeviceInitAssignWdmIrpPreprocessCallback
.
.
.
WdfDeviceCreate(&DeviceInit, &attributes, &device);
.

2

>Here, test application is opening the com port it got from the driver, after opening trying to >send/write continuous data to the USB device, in the mean time I restart the USB device, the >driver is not getting the write events from the already running test application (i.e. my EvtIOWrite >is not getting called second time)

The problem is not in your driver but in test application. Getting surprise removal event the driver is unloaded. After attaching the device the test application must open com port again.

Igor Sharovar

3

Thanks agreed,
but for the user application its just comport plug-out and plug-in right?

4

Yes… which means the device DISAPPEARS (plug-out) and then REAPPEARS (plug-in). Windows doesn’t attempt to match-up state from devices that disappear to new devices that are plugged-in. Think about this for a second… how could Windows know that the remove action isn’t permanent? Given this, it couldn’t keep state around in the HOPE that SOMEDAY the EXACT SAME DEVICE will be plugged in again, right?

Mr. Sharovar is correct: The problem’s with your test app.

Peter
OSR

5

xxxxx@gmail.com wrote:

Thanks agreed,
but for the user application its just comport plug-out and plug-in right?

I don’t know what you mean here. Once the application detects that the
device has been removed, the open handle that it already has is dead,
and will never come back to life. When device reappears, it will
reappear as a new driver in a new stack. The application needs to close
the dead handle and open a new one.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

Thanks All,

Agree, its application problem