Take the 2-minute tour ×

I'm using overlapped I/O to read and write to a serial port. When executing the exe from a command prompt, the program will crash ("xxxx.exe has encountered a problem and needs to close..."). The block of code that is using this and is where the application is crashing is called several times before it crashes and works just fine. The weird part is that when I run the executable from VC++ 2010 in debug mode, it does not crash.

This is the block of code where GetOverlappedResult() is crashing...

memset( &ov, 0, sizeof(OVERLAPPED) );
ov.hEvent = CreateEvent( NULL, TRUE, TRUE, NULL );

if( !Comm.Read( lpbBuffer, 1, &dwBytesRead, &ov ) )
    if( GetLastError() != ERROR_IO_PENDING )
        return FALSE;

if( !Comm.GetOverlappedResult(&ov,&dwBytesRead,TRUE) )
    printf("Resync: Comm.GetOverlappedResult() failed with error code %u\n", GetLastError() );
    return FALSE;

Comm.GetOverlappedResult() source

BOOL SerialAsync::GetOverlappedResult( LPOVERLAPPED lpOverlapped, LPDWORD lpNumberOfBytesTransferred, BOOL bWait )
    printf("made it here\n");
    BOOL ret = ::GetOverlappedResult( hComm, lpOverlapped, lpNumberOfBytesTransferred, bWait );
    printf("made it here too\n");
    return ret;

I have made sure that hComm, the overlapped struct and the pointer to lpNumberOfBytesTransferred are valid.


After adding the debugger environment variable, the program will crash in the debugger... the debugger opens the file tidtable.c and points to the first line of code after the #ifdef

* __set_flsgetvalue - crt wrapper for setting up FlsGetValue pointer in TLS
* Purpose:
*       This function helps msvcmXX.dll threadstart and threadstartex APIs
*       to set FlsGetValue pointer before calling __fls_getvalue.

_CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue()
#ifdef _M_IX86
    if (!flsGetValue)
        flsGetValue = DecodePointer(gpFlsGetValue);
        TlsSetValue(__getvalueindex, flsGetValue);
    return flsGetValue;
#else  /* _M_IX86 */
    return NULL;
#endif  /* _M_IX86 */


This is the function is being called before it terminates

BOOL Resync( LPBYTE lpbBuffer )
DWORD dwBytesRead;

while( Comm.Read( lpbBuffer, 1, &dwBytesRead ) )
    if( DDCMP_SOH == *lpbBuffer || DDCMP_ENQ == *lpbBuffer )
        return TRUE;

return FALSE;

This is what I've changed my AsyncSerial::Read() command to be

BOOL SerialAsync::ReadOverlapped( LPBYTE lpbBuffer, DWORD dwSize, LPDWORD dwBytesRead, LPOVERLAPPED lpOverlapped )
return ReadFile( hComm, lpbBuffer, dwSize, dwBytesRead, lpOverlapped );

BOOL SerialAsync::Read( LPBYTE lpbBuffer, DWORD dwSize, LPDWORD dwBytesRead )
BOOL bResult = TRUE;


if( !ReadOverlapped(lpbBuffer,dwSize,dwBytesRead,&ov) )
    bResult = GetLastError() == ERROR_IO_PENDING;

if( bResult )
    bResult = GetOverlappedResult(&ov,dwBytesRead,TRUE);

CloseHandle( ov.hEvent );

return bResult;
share|improve this question
We need some more code. What does SerialAsync::Read look like? What is the lifetime of the ov variable? What is every piece of code that touches ov? –  Adam Rosenfield Nov 3 '11 at 21:11
add comment

closed as too localized by Anna Lear Dec 17 '11 at 7:29


2 Answers

Ahh C++ and its memory problems. You seem to have a heap corruption. The reason why it does work under the debugger is most likely due to the Debug Heap. This symptom is also called Heisenbug which is a bug that goes away when you look closer at it. You can set the environment variable _NO_DEBUG_HEAP=1 in the process environment in the debugger options of your project see your application crashing under the debugger as well.

The code you did provide does not contain any memory allocations so I cannot guess what your actual problem is.

Personally I would switch over to the dark side (C#,F#) where a Garbage Collector cleans up after me.

share|improve this answer
It crashes on this line: BOOL ret = ::GetOverlappedResult( hComm, lpOverlapped, lpNumberOfBytesTransferred, bWait ); I believe it has something to do with the fact there is no data on the serial port to read. –  druciferre Nov 3 '11 at 19:57
Was it an access violation or something else? Could you find out what the "crash" actually was under the debugger? You could try Windbg which is very powerful but not so easy to use. Do you reuse the overlapped instance for different calls? Could it be that the OVERLAPPED structure was freed in the meantime by your class?. –  Alois Kraus Nov 3 '11 at 20:17
I don't think it's an access violation. I noticed that just when it crashes the number of handles shoots up to the maximum number. I've gone back through the code and made sure I closed all the handles.I do indeed reuse the overlapped instance for multiple calls. I also tried not reusing it and creating a new one each time, but it crashes in the same spot. See my edit for what the debugger is pointing to.. –  druciferre Nov 3 '11 at 20:35
How does your callstack look like? This sounds like you are getting at some point in time into recursion (stack overflow). How often are you calling this? You are not allowed to reuse the OVERLAPPED structure while it is used by the OS to pump data in it. Create a new one for each request and you are fine. –  Alois Kraus Nov 3 '11 at 21:03
I redefined my SerialAsync::Read() function to make sure I wasn't re-using the OVERLAPPED structs. Problem still occurs at the point during runtime. This seems to be occurring whenever there is no more data on the serial port to read. –  druciferre Nov 4 '11 at 16:33
add comment
up vote 0 down vote accepted

I finally solved my crashes. It appears it was not directly related to the GetOverlappedResult() function. The problem was thread related. I have three threads in my program, the main thread, a thread that reads from the serial port, and a thread that writes to the serial port. I knew the thread that was writing had exited before it got to this point, and instead of assuming the problem was in my read thread, I should have been looking at my main thread.

Thank you for all your help.

share|improve this answer
add comment
