This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 4%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJD%3C/text%3E%3C/svg%3E)
I have an MFC app in VS 2022 that throws exception when InitInstance calls pMainFrame->LoadFrame(IDR_MAINFRAME)... it used to compile fine until now!! Please help!!
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(92.8, 12%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDL%3C/text%3E%3C/svg%3E)
So, what's the exception, and where specifically does it occur inside LoadFrame?
Have you tried debugging deeper to identify the cause?
Yes: it happens in BOOL CWinAppEx::ReloadWindowPlacement(CFrameWnd* pFrameWnd)
and in line containing:
if (pFrameWnd->GetActiveView() == NULL) { // InitialUpdateFrame wasn't called yet pViewFirst = DYNAMIC_DOWNCAST(CView, pFrameWnd->GetDescendantWindow(AFX_IDW_PANE_FIRST, TRUE)); AFXASSUME(pViewFirst != NULL);
In the AFXASSUME() pViewFirst == NULL!!
The critical function that is not working properly is
BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
where pClassThis has name CMDIClientAreaWnd and pClass has name CView and of course
return pClassThis->IsDerivedFrom(pClass); returns false
and this causes CObject* AFX_CDECL AfxDynamicDownCast(CRuntimeClass* pClass, CObject* pObject) to return NULL which then triggers exception in AFXASSUME(pViewFirst != NULL); inside method
`BOOL CWinAppEx::ReloadWindowPlacement(CFrameWnd* pFrameWnd)`
The bug disappears by setting to false the following instance variable: m_bLoadWindowPlacement in the application class ctor...
Disappears ... because you're then no longer calling that code?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 87%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGH%3C/text%3E%3C/svg%3E)
I have encountered the same issue. I reported it here this morning:
https://developercommunity.visualstudio.com/t/MFC-is-broken-with-1721--Worked-in-17/10049381
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(201.6, 57.00000000000001%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMY%3C/text%3E%3C/svg%3E)
A fix for this issue has been internally implemented and is being prepared for release.
The bug disappears by setting to false the following instance variable: m_bLoadWindowPlacement in the application class ctor...
That's why the first time the app runs fine but stops running after the first run.....
This is an MFC bug!!!
I reproduced the problem with an MFC MDI application created by the MFC APP wizard in VS2022. Debug builds ASSERT while Release builds run without problems. After clicking "Ignore" the application continues running without apparent problems. The noted AFXASSUME is NOT present in the VS2019 MFC source code.
If you report this problem and post a link to your report I'll be happy to upvote it.
That's intriguing, I wonder why that was added.
If the AFXASSUME is ignored, the subsequent lines of code are OK because GetSafeHwnd checks the this pointer.
It doesn't take much for this bug to manifest. Starting the application twice was sufficient. It makes you wonder about QA testing. And its more than a little ironic that the bug is in the usage of a debugging macro.
I suspect it was done because it superficially looks like it could give rise to a null pointer usage, though as you say, you'd have thought testing would have been done - and it is very ironic.
Apparently it's already fixed and should be available in 17.3 preview 2.
That's good to hear.
You know what they say about AFXASSUMPTIONS...
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 22%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER%3C/text%3E%3C/svg%3E)
I just created an MDI project using VS 2022 Preiview 3.0 and got the same assertion. Not fixed yet I guess. Or the fix got lost in versioning.
As far as I'm aware VS 2022 17.3.0 is only up to Preview V1.1 so far.
Got it. Yes, V1.1 still. So waiting for V2 fix.