OS2 World.Com Forum

Subject  :  com sharing violation
Author  :  nadavsh nadav.shragai@ge.com
Date  :  11 Aug, 2005 on 15:16
I have program (which I didn't write) which open and close the com port all the time using DosOpen.

The problem is that sometimes from unknown reason it get sharing violation error when it trying to open the com port.

When I checked it I try to use the DosOpen directly after closing with DosClose and although DosClose returned without error, DosOpen returned with sharing violation.

I believe no other application is trying to catch the com port at that point.

Did anyone encounter this problem before?

It will also help me if someone know a way to get the process and/or the handle which holding the com port open.

I though maybe to try and use DosClose again assuming that the first time didn't work. But usually when using DosClose on closed file (the com port here) it return with error.

Any advises will be welcome

Thank you

Subject  :  Re:com sharing violation
Author  :  Fahrvenugen
Date  :  13 Aug, 2005 on 17:41
What com port drivers are you using? IBM's or Ray Gwinn's SIO? And if IBM's, are you using the latest drivers? If Ray Gwinn's, are you using SIO 1.6 or SIO2?

If you're using Ray Gwinn's drivers, you could use the PMLM utility to monitor the port, determine if any other application is trying to grab it, or if it isn't closing properly. Also, if you're using eComStation or MCP 1 or MCP 2 and SIO2, try SIO 1.60d - as these older drivers seem to work a little better with eCS then SIO2 which I've had randomly cause lockups.

Just a thought.

Subject  :  Re:com sharing violation
Author  :  nadavsh nadav.shragai@ge.com
Date  :  14 Aug, 2005 on 10:04
I'm using OS2 warp 3.
With patches till 41 or 43, I'm not sure.
As much as I know I don't use any third party dlls. Only IBM's dlls.

Subject  :  Re:com sharing violation
Author  :  Fahrvenugen
Date  :  16 Aug, 2005 on 01:14

Give Ray Gwinn's com port driver a try. They generally work a LOT better then IBM's drivers. If the SIO driver doesn't help (or if it causes more difficulties then previous) you can always revert back to the IBM drivers. But often I've found on machines with Com port problems, Ray's drivers solve the problem.

There are 2 versions of the drivers - SIO Version 2 and the older SIO 1.60d While Version 2 offers more features, development on it stopped while there were still a few difficulties which turned up. Thus, I recommand SIO 1.60D. The older 1.60d version just plain worked the way it was supposed to - with one exception - if I recall - it doesn't support PCI modems. If you have a PCI modem, you'll need the newer version.

It is shareware, so eventually you'll get a "Please register" screen. Ray Gwinn has discontinued development of the driver, I don't know if he still takes registrations or not. You may have to contact him directlly - there is contace information in the ZIP file. You can find a copy of 1.60d at:


Or if you want to give Version 2 a try (or if you've got a PCI modem), you can grab it from Hobbes at:


I should comment - I've run registered copies of both 1.60D and 2.02 on Warp 3 - and I never had a problem with either driver (currently I'm using 1.60d on eCS). Using eCS (OS/2 Version 4.52) - I've run into difficulties with SIO2 - which is why I went back to 1.60d.

Hope this helps

Subject  :  Re:com sharing violation
Author  :  nadavsh nadav.shragai@ge.com
Date  :  16 Aug, 2005 on 14:12

I would have try it if I could.
The program I'm working on is in a stage where changes like that require massive testing of the program which is not acceptable by my bosses.

I'm tring to find a solution or to understand the problem with the dlls I have now.

I think it could help me if I could know which rocess holds the com port or if it is held it all.
Right now the only way I know if the com port is taken is to try and open it again.
Isn't there a better way?

Subject  :  Re:com sharing violation
Author  :  Fahrvenugen
Date  :  18 Aug, 2005 on 19:34
Hi again,

I'm not sure if I can solve your problem. But a few things.

Since you have good reasons for sticking with IBM Com port drivers, you might want to double-check that your drivers are recent ones. Especially if you're running Warp 3 with a Fixpak above FP40, Fixpaks above 40 didn't include Device Driver Updates, as these were spun off into a separate Fixpak just for device drivers. Old drivers were (are) buggy, so best to check the revision. To do this, go to a command prompt and type:

bldlevel c:\os2\boot\com.sys

Make sure it is Revision / Version 9.28 or higher. Also, check the Date on the file - should be 2-9-98 or newer. Also check the date on VCOM.SYS (it will be in the \os2\mdos directory) - it should be 12-04-98 or later. Earlier versions of COM.SYS and VCOM.SYS can be buggy.

For identifying which process is grabbing the Com port, have you tried Theseus? It will let you see what is accessing a particular device driver. It can also give you other info about memory usage. Grab a copy from IBM at:


Run that in its own directory (it is a self-extracting ZIP). You'll then need to add to the config.sys:


Where x: is the drive you put it on, and xxxx is the directory.

Then start up theseus3.exe

Under the System menu, you'll find a General System sub-menu, with Device Drivers as an option.

Find the Com port you're having trouble with and double click on the Strategy option, it will tell you which process currently has that device.

Also, on the main Process Hierarchy screen, you can double-click on a process, and under the Handles section it will usually show you if a process is using a particular device (in this case, \dev\comX - where X is the port in use).

I don't know if this will help, but it might at least identify what's holding the Com port.

Subject  :  Re:com sharing violation
Author  :  nadavsh nadav.shragai@ge.com
Date  :  21 Aug, 2005 on 07:31
Thank you for your help!

I found the problem by myself.
Apparently somewhere in the program after opening the com port the program using DosExecPgm to call a program on another thread.
This thread isn't closed by the time I close the com port and reopen it.
As default the file handle for the open com port is inherited by that process.
My guess is that closing the port on the parent thread doesn't work as it should because the child also has the handle to the com port.

So my solution is either preventing the inheritance of the handle to the child or not creating the child thread at all.

Thank for your help.
The last message you wrote me won't help me with this problem but it looks like a good tool and I may use it in the future for other things.

Powered by UltraBoard 2000 <www.ub2k.com>