Debugging MFC Applications
Debugging an MFC application means debugging two layers at once: your C++ code and the underlying Win32 message pump that drives it. Visual Studio's debugger gives MFC-aware tooling — the ClassWizard-generated message maps show up in the call stack, and TRACE macros write to the Output window — but effective MFC debugging still depends on understanding how WM_ messages flow, how the framework's exception macros interact with C++ exceptions, and how to use tools like Spy++ to see what messages a window is actually receiving.
Cricket analogy: Debugging MFC is like reading both the scorecard and the ball-by-ball commentary together — the scorecard (your code) tells you the outcome, but the commentary (the message stream) tells you why each event actually happened.
TRACE Macros, ASSERT, and the Debug Heap
MFC provides TRACE (and TRACE0/TRACE1/TRACE2/TRACE3 variants in older code) to write formatted diagnostic strings to the debugger's Output window, and ASSERT/ASSERT_VALID to catch invariant violations in debug builds — ASSERT_VALID in particular calls an object's AssertValid() override, which is invaluable for catching corrupted CObject-derived state (like a CString with a bad length or a CPtrArray with an out-of-bounds index) before it causes a crash further downstream. In debug builds, MFC's memory allocator also tags every allocation, so a memory leak report at shutdown (visible via _CrtDumpMemoryLeaks or automatically in the Output window when compiled with _DEBUG) includes the file and line number of the original allocation, which is often the fastest way to locate a leaked CString, CObject, or raw new that was never deleted.
Cricket analogy: ASSERT_VALID acting like a third umpire reviewing a marginal decision before the game clock moves on — it catches a corrupted state (a bad dismissal) before the scoreboard reflects a run that never should have counted.
// Diagnosing a corrupted CObject-derived state with ASSERT_VALID and TRACE
class CInventoryItem : public CObject
{
public:
CString m_strName;
int m_nQuantity;
#ifdef _DEBUG
virtual void AssertValid() const
{
CObject::AssertValid();
ASSERT(m_nQuantity >= 0);
ASSERT(!m_strName.IsEmpty());
}
virtual void Dump(CDumpContext& dc) const
{
CObject::Dump(dc);
dc << "m_strName = " << m_strName << ", m_nQuantity = " << m_nQuantity << "\n";
}
#endif
};
void CInventoryDoc::AdjustStock(CInventoryItem* pItem, int delta)
{
#ifdef _DEBUG
pItem->AssertValid(); // catches corruption before it's used
#endif
TRACE(_T("AdjustStock: %s delta=%d\n"), pItem->m_strName.GetString(), delta);
pItem->m_nQuantity += delta;
ASSERT(pItem->m_nQuantity >= 0); // catch negative stock immediately
}Using Spy++ and the Message Loop
When a control simply doesn't respond, or responds incorrectly, the fastest diagnosis is often not stepping through C++ code but watching the actual Windows messages a window receives, using Spy++ (included with Visual Studio) to attach to the window handle and log every WM_ message in real time. This reveals problems invisible at the source level, such as a message being intercepted and swallowed by a parent window's WM_NOTIFY or WM_COMMAND reflection before it reaches the control you expected, or a modal dialog unexpectedly disabling the main frame and blocking input you assumed would still work. Combined with breakpoints set directly inside PreTranslateMessage() or WindowProc() overrides, Spy++ lets you correlate an observed UI glitch with the exact message sequence that caused it.
Cricket analogy: Watching the raw message stream in Spy++ is like watching the stump microphone feed instead of the TV broadcast — you hear the actual contact sound that tells you whether it was bat, pad, or nothing at all.
Spy++ (spyxx.exe) ships with Visual Studio's Common Tools. To diagnose a control that isn't receiving expected input, use Spy > Find Window to select the target window, then Spy > Messages to start logging. Filter to WM_COMMAND, WM_NOTIFY, and WM_LBUTTONDOWN to quickly see whether the message ever reaches the control or is consumed earlier in the parent chain.
- MFC debugging spans two layers: your C++ logic and the underlying Win32 message stream driving it.
- ASSERT_VALID calls a CObject-derived class's AssertValid() override, catching corrupted invariants before they cause downstream crashes.
- TRACE macros write timestamped diagnostic output to the Visual Studio Output window without affecting release builds.
- The debug heap tags every allocation with file and line number, making leak reports at shutdown directly actionable.
- Spy++ reveals the actual WM_ message sequence a window receives, exposing problems invisible from source code alone.
- WM_COMMAND and WM_NOTIFY reflection can silently swallow messages before they reach the control you expect.
- Breakpoints in PreTranslateMessage() or WindowProc() overrides correlate observed UI glitches with exact message sequences.
Practice what you learned
1. What does ASSERT_VALID specifically invoke on a CObject-derived object?
2. Where does MFC's debug heap write leak information at application shutdown?
3. What is a key advantage of using Spy++ over stepping through C++ code alone?
4. Why might a control never receive an expected WM_COMMAND message even though the code looks correct?
5. What happens to TRACE macro calls in a release (non-_DEBUG) build?
Was this page helpful?
You May Also Like
MFC Common Pitfalls
The recurring mistakes MFC developers make with message maps, GDI resources, and the Document/View architecture, and how to avoid them.
MFC Quick Reference
A condensed lookup of MFC's core class hierarchy, message map macros, and common string/collection/resource idioms.
MFC Interview Questions
Common conceptual and debugging-style MFC interview questions, with the reasoning strong candidates use to answer them.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics