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);
}
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:
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
memcpyresulted in a write into the subsequent segment, which resulted in the exception during thememcpycall. If the overwrite is less in this simple example, the break doesn’t occur until thefreecall, but that is still better than no exception. It’s a pretty cool utility.