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.