COM Port being locked up

I have an application running on a Windows Embedded CE 6.0 device that establishes an internet connection via a GSM modem connected via SerialPort using port COM5. However if my application crashes and/or the device is turned off without properly disconnecting the GSM connection, I am unable to connect again when I turn the device back on, I get the error "Port unavailable, it may be in use by another program." The only way to solve this is too physically unplug the modem and cut the power, then plug everything back in and it works. However when we deploy these devices they will be installed in vehicles, and the modem cables etc will not be accessible to the driver to do this. So I need to be able to "free" the port and tell the device that it really isn't in use when this happens so that the GSM connection can be re-established. Is there anyway to do this? Are there any commands I can write to the serial port that will do this, or anything?

Thanks!

If your application crashes, Windows should automatically release the handle/lock on the port.

On NT Windows (as opposed to CE Windows) in cases where you need to remove a lock or handle (with the process still running) you can do some magic with Windows' handles functions to remove it, of course this renders the application that created the handle to an unstable state, but it works. I imagine something similar can be done on CE.

Thank you W3bbo, for the very speedy feedback.

Yes sir you are right, windows should automatically release the lock the port, however my problem, it seems, is that for some reason it does not.

And that is exctly what I've been trying to, I've been digging through google/msdn trying to find some sort of functions that can release/remove the lock on the port, but I have had no luck. Do you have any more specific details on where I might be able to find some documentation on these handles function for CE?

edit - Or what about accessing the port in the registry? I feel if I knew where the com port information is stored in registry I could access the locked port and possibley *unlock* it. This would be a crude way of doing things, but if I have no other way...

Thanks!

Yes sir you are right, windows should automatically release the lock the port, however my problem, it seems, is that for some reason it does not.

Are you using the SerialPort class within a using(){} block? If not, consider wrapping it in one, so that way if your program does encounter an unhandled exception the port will be released. This won't protect against any other kind of abnormal termination though.

I wonder what device the issue is on?  If you app crashes, I suspect the modem never knows it and keeps listening.  The app tries to reconnect to a "connected" port in use on the modem.  Loosing CD I would think reset the modem.  Maybe the manual on the modem would shed light on some CD timeout or some other timeouts.  On the windows side, you should be able to close the comm port in a Catch block on a crash and also possibly send a reset to the modem and restart the app in a top level catch.  If your app just unplugged or losses power, that should be clean on the windows side, because your starting from cold boot.  I suspect it is the modem not resetting and playing with some timeout AT commands may be needed when configuring the modem on start (or firmware settings).  I have similar issues debugging Net MF devices sometimes and VS depending on what state I left the device after detaching the last time. Most of the time resetting the device, allows VS to Deploy right after.  For a production situation, you may need to go as far as a Relay and controlling the modems power from your device.  Another thing you may need some kind of serial port breakout sniffer to shed light on what is going - if you can repro issue this should point to issue directly. I shiver remembering 1200-4800 modems, AT command, serial break outs, etc, in the early days.  Man. I actually did TCP over a 9600 modem on windows 3.x using some Trumpet WinSock IP stack. Ug.

The device is a QSI Treq M4 Mobile Data Terminal.

And the kicker is, its not just an issue with my app crashing. If I just turn on the device, and connect to GSM via the "Network and Dial-Up Connections" interface in the windows control panel, and then turn the device off without disconnecting, I experience the same problem. Even turning the device back on and attempting to connect again from the windows control panel gives me the error "Port unavailable, it may be in use by another program" (without ever even opening up my app) - So it seems to be purely on the windows side, other than my app.

Also, I have searched through the modem manual, but I believe it is not even an issue with the modem as I tried playing around with AT Commands, such as "AT%RESET" to reset the modem, and even just the standard serial device command: "AT" should get a response of "OK", but I get no response from that, or any other commands. So it seems that that while the port is unavailable, I can't even reach the modem to get it to execute any AT commands...

Getting clearer.  Then it would seem is the GSM driver/sw is holding onto the device and not dropping after line drop.  Focus can now be shiffed to this issue. Any config settings in GSM control panel or command line apps?  Maybe look into NetSh command (avail on embedded?)

Yes it does seem as though that is the issue. However fixing the problem through changing settings in the control panel/command line applications really doesn't help me because this needs to be done purely programmatically. If the port is locked up I want my app to be able to free the port and then re-attempt the connection, without the user even having to know that it happened.

I haven't been able to find any classes/libraries for accessing com ports in windows ce (My application is coded in C# by the way), which is why I have been leaning towards fiddling with the registry to free the port, but I haven't had much headway in that regard either...

@tr0x: staceyw is right.  you need to configure the GSM driver/sw so it doesn't exibit the behavior to begin with.  If you can't do that then programatically reboot the device.

EDIT: since this is a CE device check with the OEM regarding the power states.  there might be a simple power state setting that can be used to compensate for the GSM issue.  either way in the long run the GSM issue needs to be addressed.  users aren't going to remember to turn off the GSM then turn off the device no matter how much code you write.

Another idea. Get a GSM that has an .Net object model or comm interface, then you can control it yourself. Or get a gsm module for more control. http://www.sparkfun.com/products/9427 . If your tied to their custom sw, I think turnkey will be hard to get and you may run into more issues.

Hm, I would follow the link to site make.com, and create a COM-toUSB and hack the USB...  Perhaps you need a repeater to "keep Alive"