USB device on serial port locks program when disconnected

[JDS]

I have an application that interfaces with a USB device using the .Net
serial port. The code works fine, displaying live data on the screen;
that is until the USB lead is pulled out from the PC when the program
hangs.

The obvious answer is not to pull the lead out, but unfortunately the
application is one in which there is a high possibility the lead will
be pulled out so the code needs to be more robust.

The form has a timer (System.Windows.Forms.Timer) that sends a request
to the device for data. The returning data is handled by the
DataReceived event of the serial port and uses a delegate to process
the data, ultimately displaying it on the form.

The timer code first checks to ensure the port exists (Not IsNothing)
and that it is open (IsOpen) before sending the request data command.

I am struggling to see what I can do to prevent the application from
hanging when the lead is disconnected (and the port is open).

Any help greatly appreciated.

Jeremy.

[Dick Grier]

Hi,

Comments inline>>>
I was assuming that the .Net SerialPort would be the best option but
it seems not. Are you saying that there is an inherent problem with
it?
<<<

For devices that use USB, AND that might be disconnected during operation,
the (IMO) the best option is DesktopSerialIO. The problem with the built-in
serial port object is that it uses SetCommMask/WaitCommState APIs. The
WaitCommState callback is not properly processed when the USB device is
disconnected. (I think this may be a problem in the API, not in the actual
serial port object).

If you take a look at the DesktopSerialIO code on the CD ROM that
accompanies my book, you will see that I do not use the WaitCommState API.
The result is that my code has approximately 5% poorer raw serial receive
throughput (though this is never an issue in a practical application), but
it doen't suffer a hang when the USB serial device is disconnected.

>>>

I am programming in VS2008 but targeting .Net version 2.0 as I have
seen various reports of problems of the SerialPort object in .Net 3.5
in a few forums. Would the dll in the fourth edition or your website
be suitable for this?
<<<

Yes. I recommend that you actually built the dll as part of your project.
Thus, the targeted framework is handled as you build or rebuild you project.

If your copy of the book is even a year or so old, you may want to purchase
an updated CD ROM. I keep it up to date, with new examples and utility
programs, even though I have not changed the actual printed text. The
current CD content exceeds 500 MB. See my website, under books, for
purchase information.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[JDS]

On Aug 30, 5:47*pm, "Dick Grier" <dick_grierNOSPAM@.msn.comwrote:

Hi,

Comments inline>>>
I was assuming that the .Net SerialPort would be the best option but
it seems not. Are you saying that there is an inherent problem with
it?
<<<

For devices that use USB, AND that might be disconnected during operation,
the (IMO) the best option is DesktopSerialIO. *The problem with the built-in
serial port object is that it uses SetCommMask/WaitCommState APIs. *The
WaitCommState callback is not properly processed when the USB device is
disconnected. *(I think this may be a problem in the API, not in the actual
serial port object).

If you take a look at the DesktopSerialIO code on the CD ROM that
accompanies my book, you will see that I do not use the WaitCommState API..
The result is that my code has approximately 5% poorer raw serial receive
throughput (though this is never an issue in a practical application), but
it doen't suffer a hang when the USB serial device is disconnected.

I am programming in VS2008 but targeting .Net version 2.0 as I have
seen various reports of problems of the SerialPort object in .Net 3.5
in a few forums. Would the dll in the fourth edition or your website
be suitable for this?
<<<

Yes. *I recommend that you actually built the dll as part of your project.
Thus, the targeted framework is handled as you build or rebuild you project.

If your copy of the book is even a year or so old, you may want to purchase
an updated CD ROM. *I keep it up to date, with new examples and utility
programs, even though I have not changed the actual printed text. *The
current CD content exceeds 500 MB. *See my website, under books, for
purchase information.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.

Fantastic. Thanks for all your help.

[JDS]

On Aug 30, 5:47*pm, "Dick Grier" <dick_grierNOSPAM@.msn.comwrote:

Hi,

Comments inline>>>
I was assuming that the .Net SerialPort would be the best option but
it seems not. Are you saying that there is an inherent problem with
it?
<<<

For devices that use USB, AND that might be disconnected during operation,
the (IMO) the best option is DesktopSerialIO. *The problem with the built-in
serial port object is that it uses SetCommMask/WaitCommState APIs. *The
WaitCommState callback is not properly processed when the USB device is
disconnected. *(I think this may be a problem in the API, not in the actual
serial port object).

If you take a look at the DesktopSerialIO code on the CD ROM that
accompanies my book, you will see that I do not use the WaitCommState API..
The result is that my code has approximately 5% poorer raw serial receive
throughput (though this is never an issue in a practical application), but
it doen't suffer a hang when the USB serial device is disconnected.

I am programming in VS2008 but targeting .Net version 2.0 as I have
seen various reports of problems of the SerialPort object in .Net 3.5
in a few forums. Would the dll in the fourth edition or your website
be suitable for this?
<<<

Yes. *I recommend that you actually built the dll as part of your project.
Thus, the targeted framework is handled as you build or rebuild you project.

If your copy of the book is even a year or so old, you may want to purchase
an updated CD ROM. *I keep it up to date, with new examples and utility
programs, even though I have not changed the actual printed text. *The
current CD content exceeds 500 MB. *See my website, under books, for
purchase information.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.

UPDATE:

For the benefit of anyone else coming across this thread with similar
problems.

I have written a test application using Dick's DesktopSerialIO and
restructered the rest of the code. This has had mixed results. If I
stream data to the port I seem to be able to unplug the USB connection
OK. However, if I use a timer (on this occasion using
System.Timers.Timer) to send a request to the device and wait for the
data to return, this works fine until I unplug the USB and then I get
the blue screen of death with a reference to
MULTIPLE_IRP_COMPLETE_REQUESTS. I have tried to keep the timer
implementation as simple as possible with auto_reset set to false to
re-enabling it when data is received to try and prevent timing issues.

However, a quick Google on the error message and there seems to be an
underlying problem with Vista and hardware issues. For some other
similar problems there is a recommendation to install SP1. I have now
installed SP1 and all seems to be OK; I can poll for data, unplug the
USB and no crashes. (However, I am not sure why the difference with
Vista pre-SP1 between polling and not).

Hope this is of help to anyone else encountering similar difficulties.

Jeremy.

[Dick Grier]

Hi,

>>

However, I am not sure why the difference with
Vista pre-SP1 between polling and not).
<<

I have no idea, "why." I haven't had a previous report. Naturally, my
systems have SP1 installed (but I don't use the Vista machines for my
day-to-day work, anyway).

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.