Skin Framework - LoadSkin causes ASSERT on exit in another DLL

Print Page | Close Window

LoadSkin causes ASSERT on exit in another DLL

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Skin Framework
Forum Description: Topics Related to Codejock Skin Framework
URL: http://forum.codejock.com/forum_posts.asp?TID=19545
Printed Date: 24 November 2024 at 4:08pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: LoadSkin causes ASSERT on exit in another DLL

Posted By: g_j_a_i_n
Subject: LoadSkin causes ASSERT on exit in another DLL
Date Posted: 05 March 2012 at 5:31am

Hello,

I have a MFC project which is dependent on another dll.

In the exe I call LoadSkin. Everything works fine.

But when I exit, it ASSERTS inside the dll code.

BOOL WINAPI RawDllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID)
{
    hInstance;
    if (dwReason == DLL_PROCESS_ATTACH)
    {
#ifdef _AFXDLL
        // make sure we have enough memory to attempt to start (8kb)
        void* pMinHeap = LocalAlloc(NONZEROLPTR, 0x2000);
        if (pMinHeap == NULL)
            return FALSE;   // fail if memory alloc fails
        LocalFree(pMinHeap);

        // set module state before initialization
        _AFX_THREAD_STATE* pState = AfxGetThreadState();
        pState->m_pPrevModuleState = AfxSetModuleState(&afxModuleState);
    }
    else if (dwReason == DLL_PROCESS_DETACH && !__mixedModuleStartup)
    {
        // restore module state after cleanup
        _AFX_THREAD_STATE* pState = AfxGetThreadState();
Here >>        VERIFY(AfxSetModuleState(pState->m_pPrevModuleState) == &afxModuleState);
        DEBUG_ONLY(pState->m_pPrevModuleState = NULL);

#endif //_AFXDLL
    }
    return TRUE;
}

When I don't use SkinFramework (comment LoadSkin line), this ASSERT does not happen.

Please help.

Regards,
Gautam Jain

Replies:

Posted By: tim00005
Date Posted: 23 July 2013 at 12:29pm

Hi is there any update to this? I am just about to start debugging the same problem. Code Jock version 16.2.0. VS 2012.

Cheers,

Tim.

Posted By: mgampi
Date Posted: 24 July 2013 at 2:02am

Hi;

Try this in your ExitInstance() function:

int CMyCoreApp::ExitInstance() {
XTPSkinManager()->LoadSkin(L"", L"");
return CWinApp::ExitInstance();
}

I've several DLLs used in my app and skinning too. But in my case the app closes without an assert.

-------------
Martin

Product: Xtreme Toolkit v 22.1.0, new Projects v 24.0.0
Platform: Windows 10 v 22H2 (64bit)
Language: VC++ 2022

Posted By: tim00005
Date Posted: 26 July 2013 at 3:58am

Hi, thanks for the help.

I am not sure what happened but the assert no longer happens and the app closes correctly. I did change a number of project settings for different reasons so I guess it could be project settings related.

If it reappears I will try your suggestion. Hopefully I won't have to.

Tim.

Posted By: mgampi
Date Posted: 26 July 2013 at 3:20pm

Hi,
Would be fine if you could tell us more about your changed project settings.

-------------
Martin

Product: Xtreme Toolkit v 22.1.0, new Projects v 24.0.0
Platform: Windows 10 v 22H2 (64bit)
Language: VC++ 2022

Posted By: tim00005
Date Posted: 06 August 2013 at 11:04am

Sorry for the delay getting back on this - I have been away.

It was not project settings in the end, I noticed I was building in release so was not getting the assertion - duh.

However i have found a solution:

I was subclassing the m_hWndMDIClient in CMainFrame::CreateClient. If I call UnsubclassWindow in CMainFrame::OnDestroy then the problem goes away.

Posted By: tim00005
Date Posted: 06 August 2013 at 11:07am

Scrap that - too quick on the post. Just tried again and it is still here. I give up:)

Posted By: Kalyani
Date Posted: 07 January 2014 at 12:12am

Hi,

I am facing the same problem of crash in:
it ASSERTS inside the dll code.

BOOL WINAPI RawDllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID)
{
    hInstance;
    if (dwReason == DLL_PROCESS_ATTACH)
    {
#ifdef _AFXDLL
        // make sure we have enough memory to attempt to start (8kb)
        void* pMinHeap = LocalAlloc(NONZEROLPTR, 0x2000);
        if (pMinHeap == NULL)
            return FALSE;   // fail if memory alloc fails
        LocalFree(pMinHeap);

        // set module state before initialization
        _AFX_THREAD_STATE* pState = AfxGetThreadState();
        pState->m_pPrevModuleState = AfxSetModuleState(&afxModuleState);
    }
    else if (dwReason == DLL_PROCESS_DETACH && !__mixedModuleStartup)
    {
        // restore module state after cleanup
        _AFX_THREAD_STATE* pState = AfxGetThreadState();
Here >>        VERIFY(AfxSetModuleState(pState->m_pPrevModuleState) == &afxModuleState);
        DEBUG_ONLY(pState->m_pPrevModuleState = NULL);

#endif //_AFXDLL
    }
    return TRUE;
}

I am not sure of the reason, I commented the loadskin code as suggested here, but it still crashes.
It happens only in Debug mode of my application.
PS: codejock v16.2.6 and Visual Studio 2010, Windows 7 64bit

Request you to please help me wth the same.

Regards,
Kalyani

Posted By: Kalyani
Date Posted: 13 January 2014 at 1:12am

Hi,

Any update on above problem?

Regards,
Kalyani

Posted By: rdhd
Date Posted: 31 July 2014 at 4:26pm

Did anyone solve this?

It appears the module state has not been correctly managed.

Would adding the AFX_MANAGE_SATE macro in your routine that loads the skin help?

Also, with side by side MFC modules, I have found that one can mess up module states if an access violation or some other exception occurs and the module state switching that should occur doesn't happen. But usually I get an invalid context activation exception eventually when it does. Of course you are shutting down (?) and that might not happen. I use the debugger and turn on first chance exception handling (win32, in particular access violations but usually just all) and then run my workflow and see if I am trapping some exception we have been ignoring, say with catch(...).

Posted By: mcmastl
Date Posted: 20 April 2015 at 2:06pm

Thank you all for bringing this to our attention, we have informed our development team and we will be looking into the issue. If the matter has been resolved please let us know.

-------------
Luke McMasters, Support Team
CODEJOCK SOFTWARE SOLUTIONS