Serial Communication through Virtual COM Port

NTDEV
1

Hi,

I am using Virtual COM port as a serial communication port in my application.

I plug the cable in the port and lauch my application. My application can create the handle for the port. With the application open, I plugged out and plugged in the cable again. However, now, my application will fail to create the handle.

Even if I close my application and re-open again, it still fail to create the handle.

Why is it happening? Any way to solve this problem?

 

Thanks.

Regards,

Tan Teik Chuan

Get your ringtones, operator logos and picture messages from MSN Mobile.

2

IF the port is virtual, how is there a cable? I am assuming this is a
usb device which exposes itself as a com port. In that case, the driver
for the usb device is not properly handling surprise remove and cleaning
up the symbolic link. You need to get the driver manufacturer to fix
the problem

d

3

Oppss… so sorry for confusion. I should make it clear that, I am using USB-to-serial cable.

So, it is driver’s problem and nothing can be done at my Windows application?

Regards,

Tan Teik Chuan

 




From: “Doron Holan”
Reply-To: “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Serial Communication through Virtual COM Port
Date: Wed, 24 May 2006 08:02:53 -0700
>IF the port is virtual, how is there a cable? I am assuming this is a
>usb device which exposes itself as a com port. In that case, the driver
>for the usb device is not properly handling surprise remove and cleaning
>up the symbolic link. You need to get the driver manufacturer to fix
>the problem
>
>d
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR
Online at http://www.osronline.com/page.cfm?name=ListServer

Get an advanced look at the new version of MSN Messenger

4

You can register for pnp notifications on the handle via RegisterDeviceNotification() and then close the handle immediately during the unplug. If you close the handle, the device will be completely removed and the bug in the driver might be avoided.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tan Teik Chuan
Sent: Wednesday, May 24, 2006 5:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

Oppss… so sorry for confusion. I should make it clear that, I am using USB-to-serial cable.
So, it is driver’s problem and nothing can be done at my Windows application?
Regards,
Tan Teik Chuan
?

From: “Doron Holan”
Reply-To: “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Serial Communication through Virtual COM Port
Date: Wed, 24 May 2006 08:02:53 -0700
>IF the port is virtual, how is there a cable? I am assuming this is a
>usb device which exposes itself as a com port. In that case, the driver
>for the usb device is not properly handling surprise remove and cleaning
>up the symbolic link. You need to get the driver manufacturer to fix
>the problem
>
>d
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

________________________________________
Get an advanced look at the new version of MSN Messenger
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Tan Teik Chuan Wrote;

With the application open, I plugged out and plugged in the cable again.
However, now, my application will fail to >create the handle.
During device handle is opening by your application, driver may not be
removed when you plug out. The point is driver should inform AP that
device has been removed and go on removing. And sometimes, if the delay
you plug in device after plug-out is very short, I find driver’s AddDevice
will be invoked before RemoveDevice. It’s the error root. Any one has
solution about this?

Best Regards,

Dengwen

6

I have developed a WDM driver for usb-to-serial device. I will create a flag
in pdx, like pdx->opened. When the application open the com port handle, I
will set pdx->opened = TRUE in IRP_MJ_CREATE dispatch routine. Then, when
in the application we regularly close the handle, I will clear the flag in
IRP_MJ_CLOSE dispatch routine. The drivers may always work like this.

So, if you plug out the device without having closed the device handle, you
may encountered some problems. The device can??t be opened again until you
reboot your windows. Of course, we can do something in driver to avoid this
kind of issues, if you can modify the driver and rebuild it.

Thanks,

Phillip

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@sunmedia.com.cn
Sent: 2006??5??25?? 11:52
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

Tan Teik Chuan Wrote;

With the application open, I plugged out and plugged in the cable again.
However, now, my application will fail to >create the handle.

During device handle is opening by your application, driver may not be
removed when you plug out. The point is driver should inform AP that device
has been removed and go on removing. And sometimes, if the delay you plug in
device after plug-out is very short, I find driver’s AddDevice will be
invoked before RemoveDevice. It’s the error root. Any one has solution about
this?

Best Regards,

Dengwen
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Windows has built in notifications for this. By calling
RegisterDeviceNotification() you can be told that the com port has been
removed from the machine. In that windows message, you close the
handle.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@sunmedia.com.cn
Sent: Wednesday, May 24, 2006 8:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

Tan Teik Chuan Wrote;

With the application open, I plugged out and plugged in the cable
again. However, now, my application will fail to >create the handle.
During device handle is opening by your application, driver may not be
removed when you plug out. The point is driver should inform AP that
device has been removed and go on removing. And sometimes, if the delay
you plug in device after plug-out is very short, I find driver’s
AddDevice will be invoked before RemoveDevice. It’s the error root. Any
one has solution about this?

Best Regards,

Dengwen
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

If you need to reboot to get the device usable after reboot, there is a bug in your driver. What you need to do is destroy the symbolic link in IRP_MN_SURPRISE_REMOVAL. Also, when you create the device, you must iterate over device names (like \Device\MySerial1,2,3…) until you don’t get a name conflict.

What is happening is that your device object is stuck in the surprise removed state until the last handle to the device is closed. While that first device is in the surprise removed state, another instance of the device can be enumerated. That means that you must destroy all device specific symbolic links and device interfaces that might be created on surprise remove processing so that the new instance can reuse these links.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Phillip Shentu
Sent: Wednesday, May 24, 2006 9:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

I have developed a WDM driver for usb-to-serial device. I will create a flag in pdx, like pdx->opened. ?When the application open the com port handle, I will set pdx->opened? = TRUE in IRP_MJ_CREATE dispatch routine. Then, when in the application we regularly close the handle, I will clear the flag in IRP_MJ_CLOSE dispatch routine. The drivers may always work like this.
So, if you plug out the device without having closed the device handle, you may encountered some problems. The device can’t be opened again until you reboot your windows. Of course, we can do something in driver to avoid this kind of issues, if you can modify the driver and rebuild it.

Thanks,
Phillip

9

Doron Holan wrote:

If you need to reboot to get the device usable after reboot, there is a
bug in your driver. What you need to do is destroy the >symbolic link in
IRP_MN_SURPRISE_REMOVAL. Also, when you create the device, you must
iterate over device names (like >\Device\MySerial1,2,3…) until you don’t
get a name conflict.

What is happening is that your device object is stuck in the surprise
removed state until the last handle to the device is closed. >While that
first device is in the surprise removed state, another instance of the
device can be enumerated. That means that you must >destroy all device
specific symbolic links and device interfaces that might be created on
surprise remove processing so that the new >instance can reuse these
links.

Do you mean before driver stick in surprise remove, it should release
symbolic links and abort all pipes, so that the new instance of driver
could be load and driver device properly. And when last handle is closed,
the first instance will be removed correctly. Right?

Best Regards,

Dengwen

10

I think by “stick in” you mean “stuck in.” Yes, it should delete all
symbolic links and set all device interfaces to FALSE while processing
IRP_MN_SURPRISE_REMOVAL and not complete the irp until it has completed
those actions. How you handle outstanding i/o to the device doesn’t
really matter to the app, but you should do it. When the device is
plugged in again, there will be new pipes and all outstanding i/o on the
old pipes will not affect the new instances of those pipes.

d

11

Thanks for Doron’s explanation. After IRP_MN_SURPRISE_REMOVAL, driver will
go into IRP_MN_REMOVE_DEVICE. I used to remove symbolic links in
IRP_MN_REMOVE_DEVICE and wait outstanding IO in IRP_MN_SURPRISE_REMOVAL,
so that’s may take fault.

Best Regards,

Dengwen

12

You still have to do this on an orderly remove (query remove -> remove).
only in the surprise remove case must you remove the links

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@sunmedia.com.cn
Sent: Thursday, May 25, 2006 12:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

Thanks for Doron’s explanation. After IRP_MN_SURPRISE_REMOVAL, driver
will go into IRP_MN_REMOVE_DEVICE. I used to remove symbolic links in
IRP_MN_REMOVE_DEVICE and wait outstanding IO in IRP_MN_SURPRISE_REMOVAL,
so that’s may take fault.

Best Regards,

Dengwen — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

Thank you Doron for your help. I have resolved this issue now.

Thanks,
Phillip

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: 2006年5月25日 13:24
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

If you need to reboot to get the device usable after reboot, there is a bug in your driver. What you need to do is destroy the symbolic link in IRP_MN_SURPRISE_REMOVAL. Also, when you create the device, you must iterate over device names (like \Device\MySerial1,2,3…) until you don’t get a name conflict.

What is happening is that your device object is stuck in the surprise removed state until the last handle to the device is closed. While that first device is in the surprise removed state, another instance of the device can be enumerated. That means that you must destroy all device specific symbolic links and device interfaces that might be created on surprise remove processing so that the new instance can reuse these links.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Phillip Shentu
Sent: Wednesday, May 24, 2006 9:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

I have developed a WDM driver for usb-to-serial device. I will create a flag in pdx, like pdx->opened. When the application open the com port handle, I will set pdx->opened = TRUE in IRP_MJ_CREATE dispatch routine. Then, when in the application we regularly close the handle, I will clear the flag in IRP_MJ_CLOSE dispatch routine. The drivers may always work like this.
So, if you plug out the device without having closed the device handle, you may encountered some problems. The device can’t be opened again until you reboot your windows. Of course, we can do something in driver to avoid this kind of issues, if you can modify the driver and rebuild it.

Thanks,
Phillip

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

> Do you mean before driver stick in surprise remove, it should release

symbolic links and abort all pipes, so that the new instance of driver
could be load and driver device properly. And when last handle is closed,
the first instance will be removed correctly. Right?

Yes.

Surprise removal occurs when the device is unplugged.
Remove occurs after this when the last handle is closed.

If the app does not listen to handle-based notifications (our case), and you
re-plug the device second time before closing the app, then the start path for
the second device instance will run before the remove path of the first
instance.

This can cause namespace conflicts if the symlinks and device interfaces are
not disabled in surprise removal.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

15

Maxim S. Shatskih дµÀ:

Surprise removal occurs when the device is unplugged.
Remove occurs after this when the last handle is closed.

I will ask a related question:

What would happen if I delete this device through DEVICE MANAGER?
I suppose it should incur query remove and then remove operation, not
surprise remove! Is it right? Who will assure there is no handle opened
for this device? The OS before it send query remove irp, or the driver
when it respond to the query remove irp?

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

16

> I suppose it should incur query remove and then remove

operation, not
surprise remove! Is it right?

Correct.

Who will assure there is no handle opened
for this device?

If the app is not registered for handle notifications, then the fact of the
handle (in fact, any FILE_OBJECT) existance on this devnode will veto the
remove and Device Manager will fail to do this.

I expect this to occur even before query remove IRP is sent on the kernel
level, when user mode vetoes are asked for, but I can be wrong here, Doron will
correct if he will want to :slight_smile:

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

17

I can’t remember whether UM or KM is queried first, but by the time you
get an IRP_MN_REMOVE_DEVICE, you know there are no open handles.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Thursday, May 25, 2006 4:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Serial Communication through Virtual COM Port

I suppose it should incur query remove and then remove operation, not

surprise remove! Is it right?

Correct.

Who will assure there is no handle opened for this device?

If the app is not registered for handle notifications, then the fact of
the handle (in fact, any FILE_OBJECT) existance on this devnode will
veto the remove and Device Manager will fail to do this.

I expect this to occur even before query remove IRP is sent on the
kernel level, when user mode vetoes are asked for, but I can be wrong
here, Doron will correct if he will want to :slight_smile:

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

18

Thanks Doron and Maxim. According to your opinion, I think there are some
points here:

  1. In order to load the second driver instance correctly, the first one
    should clean up symbol links and all device interface he opened before
    waiting for handle closed;

  2. In surprise remove case, driver should do this cleaning in
    IRP_MN_SURPRISE_REMOVAL not in IRP_MN_REMOVE_DEVICE because when there is
    any handle still opening, OS may not send IRP_MN_REMOVE_DEVICE to driver;
    In orderly remove case, driver could do cleaning in IRP_MN_REMOVE_DEVICE??

So, I have another quesion. If my driver want to also run in Win98se, I
remember there is no IRP_MN_SURPRISE_REMOVAL request in 98 OS, how can I
arrange clean action in my code?

Best Regards,

Dengwen

19

In win9x, you will get a IRP_MN_REMOVE_DEVICE while there are still open
handles. You should be able to remove the links there, but how are you
writing a WDM driver for a 16 bit driver? Com ports on win9x must be
VXDs, not .sys files. The serial port is not a WDM interface.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@sunmedia.com.cn
Sent: Thursday, May 25, 2006 6:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Serial Communication through Virtual COM Port

Thanks Doron and Maxim. According to your opinion, I think there are
some points here:

  1. In order to load the second driver instance correctly, the first one
    should clean up symbol links and all device interface he opened before
    waiting for handle closed;

  2. In surprise remove case, driver should do this cleaning in
    IRP_MN_SURPRISE_REMOVAL not in IRP_MN_REMOVE_DEVICE because when there
    is any handle still opening, OS may not send IRP_MN_REMOVE_DEVICE to
    driver; In orderly remove case, driver could do cleaning in
    IRP_MN_REMOVE_DEVICE??

So, I have another quesion. If my driver want to also run in Win98se, I
remember there is no IRP_MN_SURPRISE_REMOVAL request in 98 OS, how can I
arrange clean action in my code?

Best Regards,

Dengwen — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

20

Doron wrote:

In win9x, you will get a IRP_MN_REMOVE_DEVICE while there are still open
handles. You should be able to remove the links there, but how are you
writing a WDM driver for a 16 bit driver? Com ports on win9x must be
VXDs, not .sys files. The serial port is not a WDM interface.

Sorry for confuse. My driver is not a virtual com driver. It’s just a
bulk-sample based driver. And in my driver, I also meet the same problem
as this subject described. You know Win98se can support WDM driver also,
but I am not sure whether it can support IRP_MN_SURPRISE_REMOVAL.

Best Regards,

Dengwen