Access to Port COM1 is denied

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am getting this error trying to run a win forms .net app using the .net 2.0
serial port control. This occurs when the app tries to open the port. I knwo
this is some type of security access problem but I have no clue where to fix
it. Help....
 
I believe I have discovered the problem here. The machine the app runs on has
2 comm ports and a PS/2 mouse. There are scales that send their weight via
the serial port 1 for each port. It appears that the operating system is
confusing the scale attached to com one as some type of system device and is
grabbing it. If I unplug the scale from com1 during boot, and plug it in
after logging in, the it works fine.

How can I keep the system from grabbing com1 during boot? I removed the
fastdetect option from boot.ini but that did no good.
 
Lee said:
I am getting this error trying to run a win forms .net app using the .net
2.0
serial port control. This occurs when the app tries to open the port. I
knwo
this is some type of security access problem but I have no clue where to
fix
it. Help....
Click to expand...

No dotNet help here but.... you may have a device that's tying up Com1 and
not even know it. Mouse drivers are famous for that.

See: Available switch options for the Windows XP and the Windows Server 2003
Boot.ini files
http://support.microsoft.com/kb/833721/en-us

/fastdetect may be the culprit. We had to mess with Boot.ini on every NT4
machine we shipped because of this (fastdetect was called noserialmice on
NT4) We haven't had a problem since updating to Win2k though so.... I may be
way off.
 
Lee said:
I believe I have discovered the problem here. The machine the app runs on
has
2 comm ports and a PS/2 mouse. There are scales that send their weight via
the serial port 1 for each port. It appears that the operating system is
confusing the scale attached to com one as some type of system device and
is
grabbing it. If I unplug the scale from com1 during boot, and plug it in
after logging in, the it works fine.

How can I keep the system from grabbing com1 during boot? I removed the
fastdetect option from boot.ini but that did no good.
Click to expand...

hmmm... if anything fastdetect should be added, not removed.

Here's the NT4 doc we went by.

How to Disable Detection of Devices on Serial Ports
http://support.microsoft.com/kb/131976/

If that's correct, and the word has simply changed, you might want to try:

/fastdetect:COM1

or just

/fastdetect

<quote from http://support.microsoft.com/kb/833721/en-us>
/fastdetect:comnumber
This switch turns off serial and bus mouse detection in the Ntdetect.com
file for the specified port. Use this switch if you have a component other
than a mouse that is attached to a serial port during the startup process.
For example, type /fastdetect:comnumber, where number is the number of the
serial port. Ports may be separated with commas to turn off more than one
port. If you use /fastdetect, and you do not specify a communications port,
serial mouse detection is turned off on all communications ports.
Note In earlier versions of Windows, including Windows NT 4.0, this switch
was named /noserialmice.
</quote>
 
Hi,

Look to see if some other application is using the port. The most common
cause of this problem is Windows itself. When Windows boots, it attempts to
identify (PnP) connected devices, including the posibility of a serial mouse
on Com1. If it "thinks" that it has detected a mouse, Windows assigns a
mouse driver to the port -- this means that the port CANNOT be used by any
other application!

What causes this? The way that Windows attempts to locate a mouse is by
toggling DTR and RTS during boot. It looks for serial data after this
toggle. And, unfortunately, Windows is not very smart about this. If it
sees ANY data (even data with framing, parity, or overrun errors), is still
says, "Mouse. Assign driver!" If you have some sort of device on Com1 that
spits out data at regular intervals, without a specific command, you system
will be subject to this problem.

The only real solution (the work arounds published in KB articles on the
subject simply do not work, IME), is to make sure that any device on Com1 is
disabled, or is not connected, until after Windows has finished PnP device
identification.

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.
 
Hi,

Yes, as you see from my other reply... The cause is a combination of Windows
and the device. As I said, the only solution is to make sure that the scale
is not connected during startup. The KB solutions simply do not work.

I have thought about marketing hardware that could be installed "in-line" to
solve this problem. However, the market seems rather small, so I haven't
pursued the idea.

BTW, I didn't mention the one solution that does work. Move the scale to
another input. I.e., spend a few $ on a serial to USB adapter, and use that
port. USB serial devices are not part of this PnP mouse fiddle-fardle.

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.
 
Back
Top