WinAPP ExitInstance ExitProcess

Question

Hi , 

Issue: I have a class WinApp with MMC SnapIn registered OCX , application after launch when closed , there is always a background process running unless I kill it from task Manager 

I have a overridden ExitInstance() where I unload/freeLibrary of  all the modules , temp directories cleaned, deleting any of allocations 

solution : after all the process in ExitInstance() which can I invoke ExitProcess(0) to make sure all the threads and process is exited safely , are there any consequences with this ? Is there any other way of closing the application properly ? please share better or right approach to deal with this situation.

will there be any dangling pointers to after ExitProcess(0) ?       

PostQuitMessage() is not working                                                                                      

Thanks,

Arathi

---

Arathi

Answer 1

I have a overridden ExitInstance() where I unload/freeLibrary of  all the modules , temp directories cleaned, deleting any of allocations

When your process terminates Windows will automatically unload dlls and there is no need to deallocate memory since the entire process will be destroyed.  Remove these actions from ExitInstance().

Answer 2

It appears you are deadlocking the MMC process by putting cleanup code in ExitInstance.

For MFC DLL and OCX projects CWinApp::InitInstance and CWinApp::ExitInstance are invoked in DllMain and it is a bad idea to load or unload DLL in the function. See

Q143084 FIX: Problems with Using the MFC DAO Classes in a .DLL or .OCX

Q322909 FIX: DLL That Uses ATL CImage Class May Cause a Deadlock in a Process

MSConnect 1470256 MFC hangs when unloading a regular DLL when using GDI+

and 

Some reasons not to do anything scary in your DllMain, part 3 on Raymond Chen's blog Old New Thing

You should clean up before that. You don't really have control over your ActiveX's lifecycle (its controlled by the container) but a common place to clean up is in COleControl::OnSetClientSite. If m_pClientSite is NULL after the base implementation is called, the ActiveX is closing by the parent and you should reduce your static reference counting otherwise the ActiveX is being hosted and you should increase your reference counting. When your reference count reaches 0, you can free your resources.

For some control containers OnDestroy may be followed by another OnCreate so OnDestroy may not be a good place to cleanup. 

---

---

Visual C++ MVP

Answer 3

will there be any dangling pointers to after ExitProcess(0)

does this solve the problem of having the process in the background even after closing 

---

Arathi

Answer 4

you don't need to worry about memory after calling ExitProcess. Issue is you should not call it in the first place. Your code in ExitInstance is blocking the hosting process from exiting. 

---

---

Visual C++ MVP

Answer 5

Thanks for reply 

This is my overridden ExitInstance() API which is required to free up the memory allocated and loaded modules to be unload 

after close my process keep running in the background

when I add exit(0) OR  ExitProcess(0) works fine . no more running background tasks 

WITHOUT ExitProcess(0) process is not exited still there is a background task even after CLOSE "X"

int EDMSnapApp::ExitInstance()
{
//Clear tmp folder 
try
{
//Clear tmp folder 
CString strTmpDir;
DWORD dwRes = ::GetTempPath(255, strTmpDir.GetBuffer(255)); 
strTmpDir.ReleaseBuffer();
if (0 != dwRes)
{
strTmpDir += L"TmpImages";
CMN::CTempFolder tmpFolder(strTmpDir);
CString sPath = tmpFolder.GetFolderPath().c_str();
tmpFolder.Clean();
}
}
catch(TException* pEx)
{
ASSERT(FALSE);
pEx->Delete();
}

//  Initializing low-level modules and global vars
    TMcException::ReleaseAllModules();
//  save settings to profile
    TWinApp::WriteProfileInt    (ESDC_strSettings, g_cszTryGIT, TComAnpPtrBase::ms_bTryGit);

    TSettingsStorageModeEnum enMode  = TSettings::GetStorageMode();
    TWinApp::WriteProfileInt    (ESDC_strSettings, g_cszSettingsStorageMode, enMode);    
    TWinApp::WriteProfileInt    (ESDC_strSettings, g_cszEncryption, ESDCInterface::ms_bEncryption);    

TWinApp::WriteProfileInt (ESDC_strSettings, g_cszShowEditAttributesButton, ESWNewWizard97FinishPage::GetShowEditAttributesButton() || ESWNewObjectFinishPage::GetShowEditAttributesButton());

TWinApp::WriteProfileInt    (ESDC_strSettings, g_cszReportPageSize, ESVReportData::GetReportPageSize());
TWinApp::WriteProfileInt    (ESDC_strSettings, g_cszReportPageSize2, ESVGMReportData::GetGMReportPageSize());

    // TWinApp::WriteProfileInt    (ESDC_strSettings, g_cszDumpContextDepth,  TGetReleaseDumpContext().GetDepth());
    TWinApp::WriteProfileString (ESDC_strSettings, ESDC_strSchemaCache,     m_strSchemaCachePath);

    // destroy message filter (may be derived class)
    delete m_pMessageFilter;
    m_pMessageFilter = NULL;


    _Module.Term();
    TTrace(traceAll, _T("[EDMSnapApp::ExitInstance]\n\n"));

    int iCode = TWinApp::ExitInstance();

    if (m_pMainWnd)
    {
        m_pMainWnd->Detach();
        delete m_pMainWnd;
    }

#ifdef _DEBUG
TAtlTraceOutput::Unregister();

#endif

    ScriptEditUninitModule();

    return iCode;
}

---

Arathi

Answer 6

Hello,

If your issue is solved, please "Mark as answer" or "Vote as helpful" post to the appropriate answer , so that it will help other members to find solution quickly if they faces similar issue.

Best Regards,

Suarez Zhou

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].