CreateEx Causes Unhandled exception The activation context being deactivated is not the most recently activated one

Question

itsAnalysisDataTable.CreateEx( WS_EX_CLIENTEDGE, AfxRegisterWndClass( CS_DBLCLKS, LoadCursor( NULL, IDC_ARROW ), (HBRUSH)::GetStockObject( NULL_BRUSH ), NULL ), "AnalysiysTable", WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, dialogItemRect, this, IDC_ANALYSIS_DATA_TABLE );

This line has cost me two days of effort with no solution. itsAnalysisDataTable is a custom windows control having CWnd as its grand grand grand parent. The control has been successfully used in other paces without issues in our code. this is a CPropertyPage.

The problem I have is the line causes (and it does it every time) an Unhandled exception at 0x76f7fd5c in MyProduct (x64).exe: 0xC015000F: The activation context being deactivated is not the most recently activated one.

The exception occurs in 32-bit as well. I'm on Windows 7 x64, VS 2008.

What I have already tried:

1. Enabling break on win32 exceptions in the debugger. No exception occurs (except first chance exceptions of which there are a lot in our code and have no effect)
2. Recompiling the whole project
3. Debugging the OnCreate handler for the control for exceptions.

Call Stack:

ntdll.dll!0000000076f7fd5c()    
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] 
kernel32.dll!0000000076df42d3()     
mfc90d.dll!AfxDeactivateActCtx(unsigned long dwFlags=0, unsigned __int64 ulCookie=2077018657900210161)  Line 260 + 0x19 bytes   C++

Observations:

1. If I skip the WS_CHILD flag the exception does not happen, but OnCreate is also not called on the control!
2. If I ignore the exception and continue, the application works fine, the control also works fine.
3. Calling AfxSetAmbientActCtx(FALSE) during app init suppresses the exception. But I think this is a hack, unless I can justify it.

Answer 1

After hitting a lot of these, I've found the simple way to track down the root issue is to go to Debug -> Exceptions and enable ALL Thrown exceptions. Then you'll find there is some other exception that is firing, being silently caught, BUT messing up the activation context. Once you fix the first exception, the activation context exception won't happen.