I spoke too soon, it did bong.
It breaks here:
DWORD WaitForRX(COMMS_RX_THREAD_DATA_S& rsThreadData, OVERLAPPED& rsNotifyOverlapData)
{
BOOL bDone ;
COMSTAT sStatus ;
DWORD dwEvent, dwError, dwDummy, dwNumBytes ;
dwNumBytes = 0 ;
if (!::WaitCommEvent(rsThreadData.hPortHandle, &dwEvent,
*** THIS LINE ===> *** &rsNotifyOverlapData) )
{
dwError = ::GetLastError();
if (dwError == ERROR_IO_PENDING)
{
And the (entire) stack trace is this:
WaitForRX(tagCommsRXThreadData & {...}, _OVERLAPPED & {...}) line 533 + 12 bytes
CommsRXThreadProc(void * 0x02f61fb4) line 510 + 10 bytes
_AfxThreadEntry(void * 0x0013ef14) line 112 + 5 bytes
MyCOMMS! _beginthreadex + 202 bytes
KERNEL32! 7c80b50b()
The stack trace seems natural, and I can't see anything wrong with it. But, what is the error you see when it crashes? Is it Access Violation (0xc0000005)? Or something else? If it's an AV, the problem should be with some null pointer most likely, or something's that's being dereferenced by the hardware while pointing to some place it shouldn't (probably the zero address.) So, I'd say that a null pointer is likely to be the culprit (if it's an AV of course.) To make sure, you need to check the exact assembly instruction which brings up the exception. The best thing would be posting it together with some instructions before and after as well from VC's assembly view (which shows what C++ code has been compiled to the shown assembly code.) If the exact break point is inside a system DLL (like kernel32) then it might be because of an invalid handle. The address of the offending instruction (shown on the Windows crash dialog together with error code, reg values, etc.) would be helpful in that case as well.
To check the value of those variables which the debugger can't find in a release build (because of optimizations such as elimination of the variable, or passing a variable inside a register) you can try OutputDebugString( ) for passing it to the debugger (it will appear in the output pane of VC while debugging.) If you start the app under the debugger from the beginning, you may want to set up a __try/__except block in order to print the variable contents *only* when an exception has been raised, otherwise, your app might get slow to a crawl during the debug if the function's called frequently.
Persevere, and you'll defeat this one as well! ;-)
---------
Ehsan Akhgari
www.farda-tech.com
List Owner: [email protected]
[Email: [EMAIL PROTECTED]]
[WWW: http://www.beginthread.com/Ehsan
]
| "In Heaven an angel is nobody in
particular." George Bernard Shaw |
_______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
