PySerial could not open port COM4: [Error 5] Access is denied - please help

[Adam]

Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3


I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in
open
raise SerialException("could not open port %s: %s" % (self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.

 

[John Nagle]

Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3


I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in
open
raise SerialException("could not open port %s: %s" % (self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.

Are you trying to access serial ports from a virtual machine?
Which virtual machine environment? Xen? VMware? QEmu? VirtualBox?
I wouldn't expect that to work in most of those.

What is "COM4", anyway? Few machines today actually have four
serial ports. Is some device emulating a serial port?

John Nagle

 

[Adam]

Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3


I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
in
open
raise SerialException("could not open port %s: %s" % (self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.

Are you trying to access serial ports from a virtual machine?
Which virtual machine environment? Xen? VMware? QEmu? VirtualBox?
I wouldn't expect that to work in most of those.

What is "COM4", anyway? Few machines today actually have four
serial ports. Is some device emulating a serial port?

John Nagle

Thanks, and yes, I am using VirtualBox. My laptop does not have a serial
port so
I use a USB-to-serial converter, which is assigned COM4.

 

[Paul]

Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3


I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
in
open
raise SerialException("could not open port %s: %s" % (self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.

Are you trying to access serial ports from a virtual machine?
Which virtual machine environment? Xen? VMware? QEmu? VirtualBox?
I wouldn't expect that to work in most of those.

What is "COM4", anyway? Few machines today actually have four
serial ports. Is some device emulating a serial port?

John Nagle

Thanks, and yes, I am using VirtualBox. My laptop does not have a serial
port so
I use a USB-to-serial converter, which is assigned COM4.

Doesn't VirtualBox allow "remapping" serial ports ? I thought you
could have COM 4 in the host OS, and make it COM 1 or COM 2 in
the guest. Something like that.

http://virtuatopia.com/images/6/60/Virtualbox_serial_port_settings.jpg

Also, Windows (as a host), is notorious for stealing control of
COM ports. Even Windows software, when you run it, would report
"COM 4 is busy". Then, you have to track down *why* it's busy.
Is it that FAX software you installed ? The GPS software
that talks to your GPS serial interface ?

In theory, the "Handle" program is supposed to identify what
is keeping a COM port busy, but I don't get the desired
results from it very often. You need to know the naming
convention for virtual COM ports (COM4 via USB to serial, is
more virtual than physical). That's what makes it harder
to track down.

These are some names for COM ports, in Windows. The last two entries,
are my USB to serial adapters. VCP1 functions as COM3.
VCP0 functions as COM4. The VCP part is what would be
listed in "Handle" from Sysinternals. The \device\serial
format, is more likely to be used with true "native"
motherboard serial ports.

\device\serial

ups.exe pid: 1072 NT AUTHORITY\SYSTEM
98: File (---) \Device\VCP0
hypertrm.exe pid: 3404 ComputerName\UserID (claims to use COM3)
E0: File (---) \Device\VCP1

You can download "Handle" and play with it here.

http://technet.microsoft.com/en-us/sysinternals/bb896655

Note that, in my Handle results, at the time I was running
the Windows provided ups.exe to talk to my external UPS
(uninterruptible power supply). So that's what that
reference is. The "hypertrm" one, is me using the
built-in Windows terminal software, to talk to COM3,
to keep the port artificially busy for the purposes
of testing.

If things were working well in your case, you *might*
see something of this form. If not, you'd instead
see the name of the process that has "stolen" the
com port.

virtualbox.exe pid: 1234 ComputerName\UserID
E0: File (---) \Device\VCP0

HTH,
Paul

 

[Grant Edwards]

On 6/26/2012 9:12 PM, Adam wrote:
Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3

I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in open
raise SerialException("could not open port %s: %s" % (self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.

Are you trying to access serial ports from a virtual machine? Which
virtual machine environment? Xen? VMware? QEmu? VirtualBox? I
wouldn't expect that to work in most of those.

Except he says it _does_ work with his terminal emulator.

It shouldn't matter. If other apps can open COM4, then pyserial
should be able to open COM4.

Then it is a Virtual COM port. Often software will want to
communicate directly to the COM4 port which is usually at: IRQ3 and
I/O 2E8h.

Pyserial doesn't do that. It uses the standard win32 serial API, and
it should work just fine with any Win32 serial device (what you call a
"virtual" COM port).

 

[Adam]

On 6/26/2012 9:12 PM, Adam wrote:
Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3


I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
in
open
raise SerialException("could not open port %s: %s" %
(self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.
Are you trying to access serial ports from a virtual machine?
Which virtual machine environment? Xen? VMware? QEmu? VirtualBox?
I wouldn't expect that to work in most of those.

What is "COM4", anyway? Few machines today actually have four
serial ports. Is some device emulating a serial port?

John Nagle

Thanks, and yes, I am using VirtualBox. My laptop does not have a serial
port so
I use a USB-to-serial converter, which is assigned COM4.

Doesn't VirtualBox allow "remapping" serial ports ? I thought you
could have COM 4 in the host OS, and make it COM 1 or COM 2 in
the guest. Something like that.

http://virtuatopia.com/images/6/60/Virtualbox_serial_port_settings.jpg

Also, Windows (as a host), is notorious for stealing control of
COM ports. Even Windows software, when you run it, would report
"COM 4 is busy". Then, you have to track down *why* it's busy.
Is it that FAX software you installed ? The GPS software
that talks to your GPS serial interface ?

In theory, the "Handle" program is supposed to identify what
is keeping a COM port busy, but I don't get the desired
results from it very often. You need to know the naming
convention for virtual COM ports (COM4 via USB to serial, is
more virtual than physical). That's what makes it harder
to track down.

These are some names for COM ports, in Windows. The last two entries,
are my USB to serial adapters. VCP1 functions as COM3.
VCP0 functions as COM4. The VCP part is what would be
listed in "Handle" from Sysinternals. The \device\serial
format, is more likely to be used with true "native"
motherboard serial ports.

\device\serial

ups.exe pid: 1072 NT AUTHORITY\SYSTEM
98: File (---) \Device\VCP0
hypertrm.exe pid: 3404 ComputerName\UserID (claims to use COM3)
E0: File (---) \Device\VCP1

You can download "Handle" and play with it here.

http://technet.microsoft.com/en-us/sysinternals/bb896655

Note that, in my Handle results, at the time I was running
the Windows provided ups.exe to talk to my external UPS
(uninterruptible power supply). So that's what that
reference is. The "hypertrm" one, is me using the
built-in Windows terminal software, to talk to COM3,
to keep the port artificially busy for the purposes
of testing.

If things were working well in your case, you *might*
see something of this form. If not, you'd instead
see the name of the process that has "stolen" the
com port.

virtualbox.exe pid: 1234 ComputerName\UserID
E0: File (---) \Device\VCP0

HTH,
Paul

Thanks (Guru Paul), I've been using the USB-to-serial converter successfully
without
enabling/remapping via VBox Settings=>Serial Ports (which are both "not"
enabled).
I can see the serial port COM4 under Device Manager though. So, maybe
enabling is
necessary when the host has "native" serial ports, which my laptop does not
have.

From the output generated by Handle.exe, here's the section for TeraTerm ...
------------------------------------------------------------------------------
ttermpro.exe pid: 596 VBOX_WINXPPRO\adam (claims to use COM4)
C: File (RW-) D:\downloads\Tera Term Pro\ttpro313
2C: Section \BaseNamedObjects\ttset_memfilemap
44: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
54: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86
70: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5-21-1801674531-1078145449-1957994488-1004
78: File (RWD) C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
AC: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5-21-1801674531-1078145449-1957994488-1004
100: Section
\BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
108: File (RW-) D:\downloads\Tera Term Pro\ttpro313\httplog.log
120: Section
\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449-1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
128: Section \BaseNamedObjects\ShimSharedMemory
138: Section \BaseNamedObjects\MSCTF.Shared.SFM.IAB
------------------------------------------------------------------------------

 

[Paul]

On 6/26/2012 9:12 PM, Adam wrote:
Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3


I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
in
open
raise SerialException("could not open port %s: %s" %
(self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.
Are you trying to access serial ports from a virtual machine?
Which virtual machine environment? Xen? VMware? QEmu? VirtualBox?
I wouldn't expect that to work in most of those.

What is "COM4", anyway? Few machines today actually have four
serial ports. Is some device emulating a serial port?

John Nagle

Thanks, and yes, I am using VirtualBox. My laptop does not have a serial
port so
I use a USB-to-serial converter, which is assigned COM4.

Doesn't VirtualBox allow "remapping" serial ports ? I thought you
could have COM 4 in the host OS, and make it COM 1 or COM 2 in
the guest. Something like that.

http://virtuatopia.com/images/6/60/Virtualbox_serial_port_settings.jpg

Also, Windows (as a host), is notorious for stealing control of
COM ports. Even Windows software, when you run it, would report
"COM 4 is busy". Then, you have to track down *why* it's busy.
Is it that FAX software you installed ? The GPS software
that talks to your GPS serial interface ?

In theory, the "Handle" program is supposed to identify what
is keeping a COM port busy, but I don't get the desired
results from it very often. You need to know the naming
convention for virtual COM ports (COM4 via USB to serial, is
more virtual than physical). That's what makes it harder
to track down.

These are some names for COM ports, in Windows. The last two entries,
are my USB to serial adapters. VCP1 functions as COM3.
VCP0 functions as COM4. The VCP part is what would be
listed in "Handle" from Sysinternals. The \device\serial
format, is more likely to be used with true "native"
motherboard serial ports.

\device\serial

ups.exe pid: 1072 NT AUTHORITY\SYSTEM
98: File (---) \Device\VCP0
hypertrm.exe pid: 3404 ComputerName\UserID (claims to use COM3)
E0: File (---) \Device\VCP1

You can download "Handle" and play with it here.

http://technet.microsoft.com/en-us/sysinternals/bb896655

Note that, in my Handle results, at the time I was running
the Windows provided ups.exe to talk to my external UPS
(uninterruptible power supply). So that's what that
reference is. The "hypertrm" one, is me using the
built-in Windows terminal software, to talk to COM3,
to keep the port artificially busy for the purposes
of testing.

If things were working well in your case, you *might*
see something of this form. If not, you'd instead
see the name of the process that has "stolen" the
com port.

virtualbox.exe pid: 1234 ComputerName\UserID
E0: File (---) \Device\VCP0

HTH,
Paul

Thanks (Guru Paul), I've been using the USB-to-serial converter successfully
without
enabling/remapping via VBox Settings=>Serial Ports (which are both "not"
enabled).
I can see the serial port COM4 under Device Manager though. So, maybe
enabling is
necessary when the host has "native" serial ports, which my laptop does not
have.

From the output generated by Handle.exe, here's the section for TeraTerm ...
------------------------------------------------------------------------------
ttermpro.exe pid: 596 VBOX_WINXPPRO\adam (claims to use COM4)
C: File (RW-) D:\downloads\Tera Term Pro\ttpro313
2C: Section \BaseNamedObjects\ttset_memfilemap
44: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
54: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86
70: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5-21-1801674531-1078145449-1957994488-1004
78: File (RWD) C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
AC: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5-21-1801674531-1078145449-1957994488-1004
100: Section
\BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
108: File (RW-) D:\downloads\Tera Term Pro\ttpro313\httplog.log
120: Section
\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449-1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
128: Section \BaseNamedObjects\ShimSharedMemory
138: Section \BaseNamedObjects\MSCTF.Shared.SFM.IAB
------------------------------------------------------------------------------

For Handle to give a positive result, the TeraTerm program would need to
currently have the serial port open. If you haven't started a terminal session,
it might not be listed.

Handle has some kind of filter function, and you can try searching for the name
of the port that way.

I don't see anything in that snipping, which looks like a serial port.

Paul

 

[Adam]

Adam wrote:
On 6/26/2012 9:12 PM, Adam wrote:
Host OS: Ubuntu 10.04 LTS
Guest OS: Windows XP Pro SP3


I am able to open port COM4 with Terminal emulator.

So, what can cause PySerial to generate the following error ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line
56, in
open
raise SerialException("could not open port %s: %s" %
(self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error
5]
Access is denied.
Are you trying to access serial ports from a virtual machine?
Which virtual machine environment? Xen? VMware? QEmu? VirtualBox?
I wouldn't expect that to work in most of those.

What is "COM4", anyway? Few machines today actually have four
serial ports. Is some device emulating a serial port?

John Nagle

Thanks, and yes, I am using VirtualBox. My laptop does not have a
serial port so
I use a USB-to-serial converter, which is assigned COM4.

Doesn't VirtualBox allow "remapping" serial ports ? I thought you
could have COM 4 in the host OS, and make it COM 1 or COM 2 in
the guest. Something like that.

http://virtuatopia.com/images/6/60/Virtualbox_serial_port_settings.jpg

Also, Windows (as a host), is notorious for stealing control of
COM ports. Even Windows software, when you run it, would report
"COM 4 is busy". Then, you have to track down *why* it's busy.
Is it that FAX software you installed ? The GPS software
that talks to your GPS serial interface ?

In theory, the "Handle" program is supposed to identify what
is keeping a COM port busy, but I don't get the desired
results from it very often. You need to know the naming
convention for virtual COM ports (COM4 via USB to serial, is
more virtual than physical). That's what makes it harder
to track down.

These are some names for COM ports, in Windows. The last two entries,
are my USB to serial adapters. VCP1 functions as COM3.
VCP0 functions as COM4. The VCP part is what would be
listed in "Handle" from Sysinternals. The \device\serial
format, is more likely to be used with true "native"
motherboard serial ports.

\device\serial

ups.exe pid: 1072 NT AUTHORITY\SYSTEM
98: File (---) \Device\VCP0
hypertrm.exe pid: 3404 ComputerName\UserID (claims to use COM3)
E0: File (---) \Device\VCP1

You can download "Handle" and play with it here.

http://technet.microsoft.com/en-us/sysinternals/bb896655

Note that, in my Handle results, at the time I was running
the Windows provided ups.exe to talk to my external UPS
(uninterruptible power supply). So that's what that
reference is. The "hypertrm" one, is me using the
built-in Windows terminal software, to talk to COM3,
to keep the port artificially busy for the purposes
of testing.

If things were working well in your case, you *might*
see something of this form. If not, you'd instead
see the name of the process that has "stolen" the
com port.

virtualbox.exe pid: 1234 ComputerName\UserID
E0: File (---) \Device\VCP0

HTH,
Paul

Thanks (Guru Paul), I've been using the USB-to-serial converter
successfully without
enabling/remapping via VBox Settings=>Serial Ports (which are both "not"
enabled).
I can see the serial port COM4 under Device Manager though. So, maybe
enabling is
necessary when the host has "native" serial ports, which my laptop does
not have.

From the output generated by Handle.exe, here's the section for TeraTerm
...
------------------------------------------------------------------------------
ttermpro.exe pid: 596 VBOX_WINXPPRO\adam (claims to use COM4)
C: File (RW-) D:\downloads\Tera Term Pro\ttpro313
2C: Section \BaseNamedObjects\ttset_memfilemap
44: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
54: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86
70: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5-21-1801674531-1078145449-1957994488-1004
78: File (RWD)
C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
AC: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5-21-1801674531-1078145449-1957994488-1004
100: Section
\BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
108: File (RW-) D:\downloads\Tera Term Pro\ttpro313\httplog.log
120: Section
\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449-1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
128: Section \BaseNamedObjects\ShimSharedMemory
138: Section \BaseNamedObjects\MSCTF.Shared.SFM.IAB
------------------------------------------------------------------------------

For Handle to give a positive result, the TeraTerm program would need to
currently have the serial port open. If you haven't started a terminal
session,
it might not be listed.

Handle has some kind of filter function, and you can try searching for the
name
of the port that way.

I don't see anything in that snipping, which looks like a serial port.

Paul

Okay, this time I am sure that serial port COM4 is open and
receiving data via telnet.exe (also listed below).

From the output generated by Handle.exe, here's the sections for TeraTerm &
Telnet ..
------------------------------------------------------------------------------
ttermpro.exe pid: 3808 VBOX_WINXPPRO\adam (claims to use COM4)
C: File (RW-) D:\downloads\Tera Term Pro\ttpro313
2C: Section \BaseNamedObjects\ttset_memfilemap
44: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
54: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86
70: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5-21-1801674531-1078145449-1957994488-1004
78: File (RWD) C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
AC: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5-21-1801674531-1078145449-1957994488-1004
100: Section
\BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
108: File (RW-) D:\downloads\Tera Term Pro\ttpro313\httplog.log
120: Section
\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449-1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
128: Section \BaseNamedObjects\ShimSharedMemory
138: Section \BaseNamedObjects\MSCTF.Shared.SFM.IN
150: Section \BaseNamedObjects\MSCTF.Shared.SFM.IIM
------------------------------------------------------------------------------
telnet.exe pid: 2408 VBOX_WINXPPRO\adam
D8: File (RW-) D:\Handle
6EC: Section \BaseNamedObjects\ShimSharedMemory
6F4: Section
\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449-1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
710: Section
\BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
740: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5-21-1801674531-1078145449-1957994488-1004
774: File (RWD) C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
77C: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5-21-1801674531-1078145449-1957994488-1004
798: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86
79C: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
------------------------------------------------------------------------------


usage: handle [[-a [-l]] [-u] | [-c <handle> [-y]] | [-s]] [-p
<process>|<pid>] [name]
-a Dump all handle information.
-l Just show pagefile-backed section handles.
-c Closes the specified handle (interpreted as a hexadecimal number).
You must specify the process by its PID.
WARNING: Closing handles can cause application or system
instability.
-y Don't prompt for close handle confirmation.
-s Print count of each type of handle open.
-u Show the owning user name when searching for handles.
-p Dump handles belonging to process (partial name accepted).
name Search for handles to objects with <name> (fragment accepted).

No arguments will dump all file references.


Handle type summary:
Desktop : 56
Directory : 165
Event : 3470
File : 1463
IoCompletion : 142
Job : 1
Key : 1540
KeyedEvent : 49
Mutant : 632
Port : 566
Process : 221
Section : 373
Semaphore : 1327
SymbolicLink : 2
Thread : 1009
Timer : 46
Token : 93
WaitablePort : 3
WindowStation : 99
WmiGuid : 98
Total handles: 11355


This is a tough one.

 

[Paul]

This is a tough one.

Try

handle -a > allhand.txt

Then open the allhand.txt with Notepad and look for interesting entries.

*******

I tested right now, and first opened a session in HyperTerminal with one
of my USB to serial adapters. The second serial adapter, is connect to a
UPS, looking for a shutdown message. So the second entry should be present
at all times.

hypertrm.exe pid: 3452
....
120: File (---) \Device\VCP1


ups.exe pid: 1568 NT AUTHORITY\SYSTEM
....
98: File (---) \Device\VCP0

I don't have any "serial" entries on this machine. But one of
my other machines, has a real COM port on the SuperI/O chip,
so the entries for that would involve the word "serial" in some
way. The USB ones, at least the ones I've got, say VCP. Possibly
because one of the driver files sets up virtual COM ports. There
is a control panel for the driver, that maps a virtual COM port,
to a COM port number, like COM3 and COM4 in this case.

Paul

 

[Adam]

Try

handle -a > allhand.txt

Then open the allhand.txt with Notepad and look for interesting entries.

*******

I tested right now, and first opened a session in HyperTerminal with one
of my USB to serial adapters. The second serial adapter, is connect to a
UPS, looking for a shutdown message. So the second entry should be present
at all times.

hypertrm.exe pid: 3452
...
120: File (---) \Device\VCP1


ups.exe pid: 1568 NT AUTHORITY\SYSTEM
...
98: File (---) \Device\VCP0

I don't have any "serial" entries on this machine. But one of
my other machines, has a real COM port on the SuperI/O chip,
so the entries for that would involve the word "serial" in some
way. The USB ones, at least the ones I've got, say VCP. Possibly
because one of the driver files sets up virtual COM ports. There
is a control panel for the driver, that maps a virtual COM port,
to a COM port number, like COM3 and COM4 in this case.

Paul

Thanks (Guru Paul), you're the best. I think we may have something this
time ...

144: File (---) \Device\ProlificSerial3

And, TeraTerm (using COM4) is open and receiving data wirelessly.

From the output generated by "handle -a", here's the section for TeraTerm
....
------------------------------------------------------------------------------
ttermpro.exe pid: 3648 VBOX_WINXPPRO\adam (claims to use COM4)
4: KeyedEvent \KernelObjects\CritSecOutOfMemoryEvent
8: Directory \KnownDlls
C: File (RW-) D:\downloads\Tera Term Pro\ttpro313
10: Event
14: Directory \Windows
18: Port
1C: WindowStation \Windows\WindowStations\WinSta0
20: Desktop \Default
24: WindowStation \Windows\WindowStations\WinSta0
28: Directory \BaseNamedObjects
2C: Section \BaseNamedObjects\ttset_memfilemap
30: Semaphore
34: Semaphore
38: Key HKLM
3C: Event
40: Semaphore
\BaseNamedObjects\shell.{A48F1A32-A340-11D1-BC6B-00A0C90312E1}
44: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
48: File (---) \Device\KsecDD
4C: Key HKCU
50: Key HKCU\CLSID
54: File (RW-)
C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86
58: Mutant
5C: Event \BaseNamedObjects\crypt32LogoffEvent
60: Event
64: Mutant
68: Event
6C: Event
70: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5-21-1801674531-1078145449-1957994488-1004
74: Event
78: File (RWD) C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
7C: Semaphore
80: Semaphore
84: Semaphore
88: Semaphore
8C: Semaphore
90: Semaphore
94: Semaphore
98: Semaphore
9C: Semaphore
A0: Semaphore
A4: Semaphore
A8: Semaphore
AC: Section
\BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5-21-1801674531-1078145449-1957994488-1004
B0: Port
B4: Section
B8: Key HKCU
BC: Mutant
\BaseNamedObjects\CTF.LBES.MutexDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
C0: File (---) \Device\Tcp
C4: File (---) \Device\Tcp
C8: File (---) \Device\Ip
CC: File (---) \Device\Ip
D0: File (---) \Device\Ip
D4: Semaphore
D8: Semaphore
DC: Key HKLM\SYSTEM\ControlSet001\Services\Tcpip\Linkage
E0: Key HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters
E4: Key
HKLM\SYSTEM\ControlSet001\Services\NetBT\Parameters\Interfaces
E8: Key HKLM\SYSTEM\ControlSet001\Services\NetBT\Parameters
EC: Thread ttermpro.exe(3648): 3684
F0: Event
F4: Key
HKLM\SYSTEM\ControlSet001\Services\WinSock2\Parameters\Protocol_Catalog9
F8: Event
FC: Key
HKLM\SYSTEM\ControlSet001\Services\WinSock2\Parameters\NameSpace_Catalog5
100: Section
\BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
104: Key HKLM\SOFTWARE\Microsoft\SystemCertificates\My
108: File (RW-) D:\downloads\Tera Term Pro\ttpro313\httplog.log
10C: Mutant
\BaseNamedObjects\CTF.Compart.MutexDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
110: Mutant
\BaseNamedObjects\CTF.Asm.MutexDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
114: Mutant
\BaseNamedObjects\CTF.Layouts.MutexDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
118: Mutant
\BaseNamedObjects\CTF.TMD.MutexDefaultS-1-5-21-1801674531-1078145449-1957994488-1004
11C: Mutant
\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449-1957994488-1004MUTEX.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
120: Section
\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449-1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
124: Mutant \BaseNamedObjects\ShimCacheMutex
128: Section \BaseNamedObjects\ShimSharedMemory
12C: Mutant \BaseNamedObjects\MSCTF.Shared.MUTEX.IN
130: Event \BaseNamedObjects\ReadEnd4
134: Event
138: Section \BaseNamedObjects\MSCTF.Shared.SFM.IN
13C: Event \BaseNamedObjects\Write4
140: Event \BaseNamedObjects\ReadEnd4
144: File (---) \Device\ProlificSerial3
148: Event \BaseNamedObjects\Read4
14C: Thread ttermpro.exe(3648): 272
150: Section \BaseNamedObjects\MSCTF.Shared.SFM.EGO
154: Event
158: Mutant \BaseNamedObjects\MSCTF.Shared.MUTEX.EGO
------------------------------------------------------------------------------


The Python script needed a call to ser.close() before ser.open() in order to
work.
Yes, that's right ... things are working fine now.

 

[Grant Edwards]

The Python script needed a call to ser.close() before ser.open() in
order to work.

IOW, the port opened OK, but when you tried to open it a second time
without closing it first, _that's_ when the .open() call failed.

That's a restriction built in to Win32. You can't open a serial port
that's already open. [Linux doesn't have that restriction.]

Why do you need to open it a second time?

 

[Adam]

The Python script needed a call to ser.close() before ser.open() in
order to work.

IOW, the port opened OK, but when you tried to open it a second time
without closing it first, _that's_ when the .open() call failed.

That's a restriction built in to Win32. You can't open a serial port
that's already open. [Linux doesn't have that restriction.]

Why do you need to open it a second time?

--
Grant Edwards grant.b.edwards Yow! Send your
questions to
at ``ASK ZIPPY'', Box
40474,
gmail.com San Francisco, CA 94140,
USA

As far as I can tell, the wireless hardware connected to the USB-to-serial
converter is
receiving data (which may have the serial port open?). I can see the data
being
received in TeraTerm (using COM4). After closing TeraTerm,
I start up the Python script and get the following error message ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in
open
raise SerialException("could not open port %s: %s" % (self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.


Searching for similar encounters of this error message,
some people said that calling ser.close() before ser.open()
solved the problem. And, it worked for me as well.

Is this considered a chicken & egg situation?

 

[Grant Edwards]

The Python script needed a call to ser.close() before ser.open() in
order to work.

IOW, the port opened OK, but when you tried to open it a second time
without closing it first, _that's_ when the .open() call failed.

That's a restriction built in to Win32. You can't open a serial port
that's already open. [Linux doesn't have that restriction.]

Why do you need to open it a second time?

As far as I can tell, the wireless hardware connected to the
USB-to-serial converter is receiving data (which may have the serial
port open?). I can see the data being received in TeraTerm (using
COM4). After closing TeraTerm, I start up the Python script and get
the following error message ...

C:\Wattcher>python wattcher.py
Traceback (most recent call last):
File "wattcher.py", line 56, in <module>
ser.open()
File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in
open
raise SerialException("could not open port %s: %s" % (self.portstr,
ctypes.WinError()))
serial.serialutil.SerialException: could not open port COM4: [Error 5]
Access is denied.


Searching for similar encounters of this error message, some people
said that calling ser.close() before ser.open() solved the problem.
And, it worked for me as well.

Is this considered a chicken & egg situation?

Can you post a small example showing what you're doing?

If you're getting that error (and calling ser.close() makes that error
go away), then it's because you're trying to re-open a port that you
already have open.

What happens if you just get rid of both the ser.close() and
ser.open() calls? IOW, the port is apparently already open -- why do
you want to close() and then re-open() it?

 

[Grant Edwards]

Why do you need to open it a second time?

As far as I can tell, the wireless hardware connected to the
USB-to-serial converter is receiving data (which may have the serial
port open?). I can see the data being received in TeraTerm (using
COM4). After closing TeraTerm, I start up the Python script and get
the following error message ... [...]
Searching for similar encounters of this error message, some people
said that calling ser.close() before ser.open() solved the problem.
And, it worked for me as well.

Is this considered a chicken & egg situation?

Can you post a small example showing what you're doing?

The best way to get help is to write as small a program as possible
that demonstrates the problem, and post it. I'll help you get
started...

Does this program work?

import serial
ser = serial.Serial("COM4")
ser.close()

At the moment, I don't have access to a Windows machine, but I think
the above should run without any errors. If it works, then you've
successfully opened and closed the COM4 port. Start adding
"features", in increments as small as possible, until the program
fails.

Then try to remove stuff that's not needed while still keeping the
failure.

IOW, try to find the smallest possible program that fails.

Usually, in the process of doing that, you'll figure out what you were
doing wrong. If not, post the smallest failing program you can come
up with, and somebody will be able to help.

If you won't show us what you're doing, we can't tell you what you're
doing wrong.

 

[Temia Eszteri]

The best way to get help is to write as small a program as possible
that demonstrates the problem, and post it. I'll help you get
started...

Does this program work?

import serial
ser = serial.Serial("COM4")
ser.close()

At the moment, I don't have access to a Windows machine, but I think
the above should run without any errors. If it works, then you've
successfully opened and closed the COM4 port. Start adding
"features", in increments as small as possible, until the program
fails.

Then try to remove stuff that's not needed while still keeping the
failure.

IOW, try to find the smallest possible program that fails.

Usually, in the process of doing that, you'll figure out what you were
doing wrong. If not, post the smallest failing program you can come
up with, and somebody will be able to help.

If you won't show us what you're doing, we can't tell you what you're
doing wrong.

Actually, I believe someone in an earlier thread in the newsgroup or
elsewhere pointed out that serial ports automatically open under
Windows. I'd have to look it back up when I have the time, which I
don't have at the moment, unfortunately.

~Temia

 

[Adam]

Actually, I believe someone in an earlier thread in the newsgroup or
elsewhere pointed out that serial ports automatically open under
Windows. I'd have to look it back up when I have the time, which I
don't have at the moment, unfortunately.

~Temia

Thanks, I think I read that as well but can't recall where.

I am just running Python scripts (downloaded),
which is not opening the serial port more than once (as Grant keeps
assuming).

 

[Grant Edwards]

What they're referring to is that on startup, Windows used to open
serial ports and query them to see if there was a serial mouse
connected. If it _thought_ it found a mouse, it would then hold the
port. I don't think that behavior has been enabled by default for a
long time.

If that were the case, then your terminal program wouldn't be able to
open the port either.

However, IIRC, some versions of windows do open and then close the
ports during the bus/device enumeration step of startup. However, they
don't keep the port open, so it doesn't affect the ability of user
applications to later open the port.

Thanks, I think I read that as well but can't recall where.

I am just running Python scripts (downloaded), which is not opening
the serial port more than once (as Grant keeps assuming).

Well, I'm assuming your description of what you're doing is accurate.

If you're telling the truth, then the program is opening the port more
than once.

If the port wasn't already open, then calling ser.close() wouldn't do
_anything_. Here's the close() implmentation from pyserial:

def close(self):
"""Close port"""
if self._isOpen:
if self.hComPort:
# Restore original timeout values:
win32.SetCommTimeouts(self.hComPort, self._orgTimeouts)
# Close COM-Port:
win32.CloseHandle(self.hComPort)
win32.CloseHandle(self._overlappedRead.hEvent)
win32.CloseHandle(self._overlappedWrite.hEvent)
self.hComPort = None
self._isOpen = False

There's only _one_ place where self._isOpen is set to True, and that's
at the end of the open() call:

def open(self):
"""Open port with current settings. This may throw a SerialException
if the port cannot be opened."""
[...]
self._overlappedWrite.hEvent = win32.CreateEvent(None, 0, 0, None)
self._isOpen = True

If you have to add the call "ser.close()" before you can open the port
with "ser.open()", then that means that the port _was_already_open_.

 

[Adam]

What they're referring to is that on startup, Windows used to open
serial ports and query them to see if there was a serial mouse
connected. If it _thought_ it found a mouse, it would then hold the
port. I don't think that behavior has been enabled by default for a
long time.

If that were the case, then your terminal program wouldn't be able to
open the port either.

However, IIRC, some versions of windows do open and then close the
ports during the bus/device enumeration step of startup. However, they
don't keep the port open, so it doesn't affect the ability of user
applications to later open the port.

Thanks, I think I read that as well but can't recall where.

I am just running Python scripts (downloaded), which is not opening
the serial port more than once (as Grant keeps assuming).

Well, I'm assuming your description of what you're doing is accurate.

If you're telling the truth, then the program is opening the port more
than once.

If the port wasn't already open, then calling ser.close() wouldn't do
_anything_. Here's the close() implmentation from pyserial:

def close(self):
"""Close port"""
if self._isOpen:
if self.hComPort:
# Restore original timeout values:
win32.SetCommTimeouts(self.hComPort, self._orgTimeouts)
# Close COM-Port:
win32.CloseHandle(self.hComPort)
win32.CloseHandle(self._overlappedRead.hEvent)
win32.CloseHandle(self._overlappedWrite.hEvent)
self.hComPort = None
self._isOpen = False

There's only _one_ place where self._isOpen is set to True, and that's
at the end of the open() call:

def open(self):
"""Open port with current settings. This may throw a
SerialException
if the port cannot be opened."""
[...]
self._overlappedWrite.hEvent = win32.CreateEvent(None, 0, 0, None)
self._isOpen = True

If you have to add the call "ser.close()" before you can open the port
with "ser.open()", then that means that the port _was_already_open_.

Obviously pySerial considers the serial port open and will not open an
already open serial port.
However, why is it that TeraTerm can open the serial port?

Here's the link where I read about calling ser.close() before ser.open() ...

Trying to open a serial port with pyserial on WinXP -> "Access denied"
http://stackoverflow.com/questions/...ial-port-with-pyserial-on-winxp-access-denied


Here's the Python scripts ...
https://github.com/adafruit/Tweet-a-Watt/downloads
Click on the "Download as ..." button for the Python scripts

 

[Grant Edwards]

Obviously pySerial considers the serial port open

Because it's already been opened by the Python program.

and will not open an already open serial port.

Pyserial will happily try if you call the open() of a port that's
already open, but Windows will return an error.

However, why is it that TeraTerm can open the serial port?

Because TeraTerm only opens it once.

Here's the link where I read about calling ser.close() before
ser.open() ...

Trying to open a serial port with pyserial on WinXP -> "Access denied"

http://stackoverflow.com/questions/...ial-port-with-pyserial-on-winxp-access-denied

That code is broken.

The port is opened by this line:

self.ser=serial.Serial(port='\\.\COM1', baudrate=9600, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=1)

And then the author tries to _open_it_a_second_time_ here:

self.ser.open()

Here's the Python scripts ...
https://github.com/adafruit/Tweet-a-Watt/downloads
Click on the "Download as ..." button for the Python scripts

Like I kept telling you, those programs are trying to re-open a port
that they've already open. Here's the erroneous code:

wattcher.py:

53
54 # open up the FTDI serial port to get data transmitted to xbee
55 ser = serial.Serial(SERIALPORT, BAUDRATE)
56 ser.open()
57

Line 55 opens the serial port.

Line 56 tries to _open_it_again_. _The_port_is_already_open_.
Windows doesn't allow a serial port to be opened twice, therefore the
ser.open() call raises an exception.

Just delete line 56.


The same thing happens here:

gmeter-wattcher.py

83
84 # open up the FTDI serial port to get data transmitted to xbee
85 ser = serial.Serial(SERIALPORT, BAUDRATE)
86 ser.open()
87

Just delete line 86.

See how simple it was to get the problem solved once you posted the
actual code?

 

[Roel Schroeven]

Temia Eszteri schreef:

Actually, I believe someone in an earlier thread in the newsgroup or
elsewhere pointed out that serial ports automatically open under
Windows. I'd have to look it back up when I have the time, which I
don't have at the moment, unfortunately.

That doesn't have anything to do with Windows, but with how pySerial
works. See the documentation for __init__():

"The port is immediately opened on object creation, when a port is
given. It is not opened when port is None and a successive call to
open() will be needed."

So if your script does something like

prt = serial.Serial('COM4')

then pySerial automatically opens the port, and you shouldn't call
prt.open() anymore.

If, on the contrary, you do something like

prt = serial.Serial()
prt.port = 'COM4'

then pySerial doesn't open the port, and you have to call prt.open() to
do it.

PySerial has this same behavior on both Windows and Linux. The
difference might be that on Linux it is possible to open serial ports
more than once, while that doesn't work on Windows.

Best regards,
Roel