CMFCVisualManager memory leak, still there?

Owen Ransen 541 Reputation points
2021-11-05T17:39:58.913+00:00

I see that there was a post about this in 2017 (4 years ago), but I'm wondering if it was a bug of of the solution was the correct way of handling it. I'm using VS2019.

It looks like when you use a control like CMFCEditBrowseCtrl it can cause a memory leak unless you explicitly delete it (or maybe its system) in your program's ExitInstance.

Otherwise you'll get a message like:

a CMFCVisualManager object at $028ECBF0, 184 bytes long

So in ExitInstance I do this:

int CCollMakeApp::ExitInstance()
{
    // This appears to be required when using advanced MFC controls like CMFCEditBrowseCtrl
    CMFCVisualManager::DestroyInstance () ;

    return CWinApp::ExitInstance();
}

Is it a bug that I have to do this?

Windows API - Win32
Windows API - Win32
A core set of Windows application programming interfaces (APIs) for desktop and server applications. Previously known as Win32 API.
1,895 questions
No comments
{count} votes

Accepted answer
  1. Junjie Zhu - MSFT 6,036 Reputation points Microsoft Employee
    2021-11-08T03:44:43.323+00:00

    Hello,
    Welcome to Microsoft Q&A!

    I have just tested the memory changes during CMFCEditBrowseCtrl usage and found that the memory increases when the control is opened and is not completely freed after the OnEnChangeMfceditbrowse event ends. Memory leaks was detected using _CrtDumpMemoryLeaks and recreates your situation. This bug may not have been fixed.You can send a bug issue to Microsoft with the Feedback Hub appMemoryTestlog.png.

    Thank you.


    If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    No comments

0 additional answers

Sort by: Most helpful