Why might trigger a breakpoint when I return TRUE from my OnCopyData?

Question

I'm using Visual Studio to debug an ATL application.

When I step over return TRUE in this code, the error occurs:

BOOL CMainFrame::OnCopyData(CWnd* pWnd, COPYDATASTRUCT* pCopyDataStruct) {

    // Code snipped from here - maybe this causes stack/heap corruption?

    // I have a breakpoint here, if I step over (F10), AFX trace message 
    // is shown (as below)
    return TRUE;

}

This is the message box that's shown:

Windows has triggered a breakpoint in foobar.exe.

This may be due to a corruption of the heap, which indicates a bug in foobar.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while phonejournal.exe has focus.

The output window may have more diagnostic information.

The message is a little vague, and I'm wondering what tools I can use to get more information. The debugger breaks on the call to AtlTraceVU in atltrace.h:

 inline void __cdecl CTrace::TraceV(const char *pszFileName, int nLine,
  DWORD_PTR dwCategory, UINT nLevel, LPCWSTR pszFmt, va_list args) const
 {
  AtlTraceVU(m_dwModule, pszFileName, nLine, dwCategory, nLevel, pszFmt, args);
 }

Answer 1

Your memory (perhaps your stack) is corrupted by a wayward pointer somewhere else in the code.

Answer 2

Microsoft's Application Verifier may help with this. If the application has heap corruption, this utility can cause the exception to occur when the error occurs. It can use a lot of memory when running, though, since it can produce big changes in memory allocation schemes.

The following obviously flawed code gives a simple demonstration:

char *pc = malloc( 4 );
memcpy( pc, "abcdabcd", 9 );
free( pc );

When I ran this without application verifier, it ran to completion with no obvious error. With application verifier, though, it caused an exception (0x80000003). Application Verifier forced the allocation to be at the end of a segment (e.g., 0x1e9eff8). The memcpy resulted in a write into the subsequent segment, which resulted in the exception during the memcpy call. If the overwrite is less in this simple example, the break doesn't occur until the free call, but that is still better than no exception. It's a pretty cool utility.