Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Access Denied problem with CreateFile

890 views
Skip to first unread message

vinay

unread,
Jul 23, 2004, 10:05:39 AM7/23/04
to
Hallo,
I have a problem when using the CreateFile function to access the COM
port.In my application i create a dialog box.When the initdialog
function is called i initialise the port and then do the other things
that i have to with the port. It works fine. The funny part is that
once i close this dialog box and open it again without closing the
entire application the CreatFile function returns ACCESS_DENIED
error.But if i close the entire application and then restart it
everythin is fine.I have a class that accesses the serial port.This
class also uses threads to access the port.But when the dialog box is
closed the thread is killed and the handle to the COM port is also set
back to NULL.However the CreateFile still returns ACCESS_DENIED
error.I read in the MSDN manuals that

"Set of bit flags that specifies how the object can be shared. If
dwShareMode is 0, the object cannot be shared. Subsequent open
operations on the object will fail, until the handle is closed"

I have used dwShareMode as 0 since its a COM port.However subsequent
open operations return ACCESS_DENIED inspite of the fact that the
handle to the com port is closed.
Has anyone had a problem like this before ......its really taking me a
lot of time and i cant figure it out at all.
thanx in advance and regards
vinay

Vishal Doshi

unread,
Jul 23, 2004, 11:40:49 AM7/23/04
to
"vinay" <vinaym...@yahoo.com> wrote in message
news:1651d118.0407...@posting.google.com...

> Hallo,
> I have a problem when using the CreateFile function to access the COM
> port.In my application i create a dialog box.When the initdialog
> function is called i initialise the port and then do the other things
> that i have to with the port. It works fine. The funny part is that
> once i close this dialog box and open it again without closing the
> entire application the CreatFile function returns ACCESS_DENIED
> error.But if i close the entire application and then restart it


Do you call CloseHandle() on the handle that you get from CreateFile()?

Try something like this:

class CComPort
{
HANDLE m_Handle ;

public:
CComPort( int portId );
virtual ~CComPort();
};

CComPort::CComPort( int PortId ) :
m_Handle( INVALID_HANDLE_VALUE )
{
m_Handle = CreateFile( ..., FILE_SHARE_NONE, OPEN_EXISTING, ... );
if ( m_Handle == 0 || m_Handle == INVALID_HANDLE_VALUE )
throw std::runtime_error("Could not open Com port");
}


CComPort::~CComPort()
{
if ( m_Handle != INVALID_HANDLE_VALUE )
::CloseHandle( m_Handle );
}


Vishal.


Trevor

unread,
Jul 23, 2004, 10:41:51 AM7/23/04
to

closed".

Does that tell you anything?

You said you close the COM port by setting the handle to NULL. This
effectively wipes out the handle and you get a nice resource leak. You
are supposed to call CloseHandle on the CreateFile HANDLE (as the
CreateFile documentation says). I suspect you are not calling
CloseHandle. This isn't Java where setting things to NULL makes them
magically clean themselves up ;)

Joseph M. Newcomer

unread,
Jul 23, 2004, 5:11:59 PM7/23/04
to
Well, it means access is denied. You have already opened the handle somewhere, and a
subsequent attempt to open COM1 will fail with an access denied error.

Setting the handle to NULL doesn't close the handle, and it sounds like you are not
closing the handle.

I believe serial ports always ignore dwShareMode, and it is impossible to open them other
than exclusive anyway.

I don't believe the handle is closed. Note that if you duplicate the handle, pass it down
to a process as inherited, etc., then the COM1 port will not be available until ALL
handles are closed.

Put a breakpoint at your CloseHandle, and make sure that (a) you are calling it and (b) it
succeeds. Most people don't notice or care that CloseHandle is a boolean function. But if
you ARE callilng it, and are not using duplication or inheritance, make sure that the
CloseHandle is really succeeding. For example, write
VERIFY(CloseHandle(h));
and examine, in a watch-window, the value
@ERR,hr
which will give you the last error code for the current thread, and its textual
explanation.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Kurt Grittner

unread,
Jul 26, 2004, 2:21:59 PM7/26/04
to
Hi vinay,

You have to open COM ports in exclusive mode. Do something like this:

hTemp = CreateFile(_T("COM1"),
GENERIC_READ | GENERIC_WRITE,
0, // Must use exclusive mode
NULL, // No security attributes
OPEN_EXISTING, // Must use open existing
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, // Use zero here if
only using a single thread
NULL // Comm devices must use null template
);

Examine the MTTTY.EXE sample program from MSDN to see how to use
overlapped IO with separate threads for reading and writing.

Hope this helps,
Kurt


On 23 Jul 2004 07:05:39 -0700, vinaym...@yahoo.com (vinay) wrote:

vinay

unread,
Aug 2, 2004, 5:23:41 AM8/2/04
to
Hi guys,
Thanx for all ur replies and sorry for the delay in answering ..my
computer was down for the past few days. Neways i realised the problem
in my code....a silly one actually.I hadnt called the CloseHandle()
function and that was causing all the problems for me.Now its working
fine.
Thanx again for the help
regards
vinay

Kurt Grittner <grittkmg...@mailbag.com> wrote in message news:<kiiag0tbg0vsj4gq5...@4ax.com>...

0 new messages