15

I'm working on an application that uses COM port for communication with external controller. When I reboot the PC with communication cable connected, Windows (7) opens the port, without any application running, so I can't access it any more. I tried to close it programatically, but it just stays taken.

Anyone got an idea how can I force it to close, any program I can run before my app, or a way to programatically close it no matter what?

animuson
  • 53,861
  • 28
  • 137
  • 147
Clone
  • 535
  • 1
  • 6
  • 14
  • Sounds to me like there is another app, or even your app that runs on startup that is opening the port, regardless of cable disconnected/connected. Never had issues like this on 98, XP, Vista or 7. Are you saying that if the cable is disconnected when rebooting, you are able to control the port? – Andy Aug 26 '11 at 17:19
  • Exactly, if the cable is disconnected, or the controller turned off, I get the access to the port. I don't think it's my app, since I close the port when exiting app, and I can run it again after it's closed, only happens when I reboot the machine. – Clone Aug 26 '11 at 17:25
  • I also tried without my app running on startup, and even not running it at all before reboot. – Clone Aug 26 '11 at 17:28

5 Answers5

19

I didn't manage to close the port, but after a lot of searching and testing I found what was the source of my problems. I'm posting the solution to help anyone who has the same problem.

Windows identifies devices with constant data stream connected to serial port as serial mouse (in this system it was Microsoft Serial Ballpoint), and tries to install them, taking over the control over the port without any process using it. The solution is to wait for Windows to install the device (check Device Manager under Mouses And Other Pointing Devices) and then DISABLING it. If you uninstall the device it will be installed again, and the problem is back.

Thanks to everyone who tried to help, and I hope others will find this solution useful.

Clone
  • 535
  • 1
  • 6
  • 14
  • 1
    This is a continuous problem where I work. All of our proprietary devices use some form of COM port to connect. A lot of our devices automatically spew data out their data port(s) when power is applied, if you reboot your machine while one of these is connected, Windows detects it as an Intel Ballpoint mouse and refuses to give up the port. We've found that you can force the port to disable enumeration to prevent it from installing the mouse on boot, but we don't have a universal solution for it, it gets applied piecemeal to our various machine, which is not ideal. – delliottg Mar 03 '17 at 17:53
  • This was precisely the issue that has been plaguing me for a while. Have scales attached to real COM ports, and every so often would get access denied when trying to start the program. Process Explorer does NOT show anything using the port, yet once I found this, I went into Device Manager and saw the Ballpoint mouse "working properly" on COM1. WTF?!?!? Thank you for discovering this issue! – topshot Apr 10 '17 at 12:23
10

No there's no way to force the port to close (see this question). There is no way to force another process to close the port so you can take it.

But Windows isn't opening up the port by itself - some other application running in the background is probably doing it. Download Process Explorer and use the "Find Handle or DLL" on the Find menu to find the process with the com port open. If it is a physical COM port on the machine it will be named Serial0, Serial1, ..., or SerialN where COM1 maps to Serial0. If it's a USB to COM adapter I'm not sure what the device ID will be.

You could also try using PortMon to watch for activity on the port. PortMon will show you the process that has the port open.

Community
  • 1
  • 1
shf301
  • 31,086
  • 2
  • 52
  • 86
  • I'll try with Process Explorer to see what occupies the port. Thanks for the tip. – Clone Aug 26 '11 at 17:27
  • 3
    Just a quick update, since I'm still dealing with the same thing: There's no process or any handle connected to the port, but it just stays reserved. – Clone Feb 07 '12 at 23:25
2

how i resolved was turned off the device with the continuous output, unplug the usb, plug it in again to let windows to detect the com number, then turn the device on again.

Jianhong
  • 899
  • 9
  • 11
1

My guess is that when you close your app and reboot the PC, the external controller is not closing it's side of things gracefully and is left in an undefined state.

When the PC is rebooted the controller is still in this illegal state and it gives the appearance that you cannot open the port on the PC because comms cannot be re-established correctly.

Perhaps the external controller is not handling changes of state of the DTR/DSR lines correctly?

How is the cable between PC and controller wired?

Hard to say much more without knowing any specifics.

Andy
  • 5,188
  • 10
  • 42
  • 59
  • 1
    It might be something like that, the controller uses RTS/DTR lines, and I think that might the thing causing the Windows to "see" that the port is active. It's my first attempt to try and fix it from the program, and the next thing will be to send the controller to standby until it detects that PC is "awake" – Clone Aug 26 '11 at 17:46
0

What I did was to disable the controller, turn it off, restart my computer, turn it on (as soon as windows loads) and go back to enable it. It worked for me with two microcontrollers with this problem.

Juan Fer Montufar
  • 1