Loading simple RTF containing an image does not release memory on subsequent loads

Question

Loading simple RTF containing an image does not release memory on subsequent loads

roy nelson 25

Consider this code it uses the MSFTEdit Richedit 50 control, every time you click the caption it will load the oom.rtf which contains an image, it displays the private bytes used by the process, (you can Task manager or Process explorer to the see the memory increase). There appear to be no way to stem the leak.

#include <windows.h>
#include <richedit.h>
#include <psapi.h>
static const TCHAR RTFFilename[] = TEXT("oom.rtf");
HWND RichEditHandle, MainWindowHandle;
DWORD CALLBACK MyRead(DWORD dwCookie, LPBYTE pbBuffer, LONG cb, LONG *pcb)
{
	HFILE	hf = (HFILE) dwCookie;
	if(hf == HFILE_ERROR)
		return (DWORD) E_FAIL;
	*pcb = _lread(hf, pbBuffer, cb);
	return (DWORD) (*pcb >= 0 ? NOERROR : (*pcb = 0, E_FAIL));
}
SIZE_T GetCurrentProcessMemoryInfo()
{
    PROCESS_MEMORY_COUNTERS_EX pmc;
	pmc.cb = sizeof(pmc);
	GetProcessMemoryInfo(GetCurrentProcess(), (PPROCESS_MEMORY_COUNTERS)&pmc,sizeof(pmc));
	return (pmc.PrivateUsage / 1024);
}
void ReadRTFFile(HWND hwndRE,  LPCSTR szFile)
{
	EDITSTREAM es;
    DWORD dwFormat;
	es.dwCookie = (DWORD) _lopen(szFile, OF_READ);
	if(es.dwCookie == (DWORD) HFILE_ERROR) return;
    dwFormat = SF_RTF;
	es.dwError = 0;
	es.pfnCallback = MyRead;
	SendMessage(hwndRE,EM_STREAMIN,dwFormat, (LPARAM) &es);
	_lclose((HFILE) es.dwCookie);
	SendMessage(hwndRE, EM_SETMODIFY, (WPARAM) FALSE, 0);
	InvalidateRect(hwndRE, NULL, TRUE);
	UpdateWindow(hwndRE);
}
void ShowMemoryUser(HWND WindowH)
{
	TCHAR szT[256];
    wsprintf(szT, TEXT("Loaded... %s memory used: %dkb"), RTFFilename,GetCurrentProcessMemoryInfo());
	SetWindowText(WindowH, szT);
}
void ShowLoading(HWND WindowH)
{
	TCHAR szT[256];
    wsprintf(szT, TEXT("Loading... %s memory used: %dkb"),RTFFilename, GetCurrentProcessMemoryInfo());
	SetWindowText(WindowH, szT);
}
#ifdef MSFTEDIT_CLASS
#undef MSFTEDIT_CLASS
#define MSFTEDIT_CLASS		"RICHEDIT50W"
#endif
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) {
    switch (msg) {
    case WM_CREATE: {
        LoadLibrary(TEXT("Msftedit.dll")); // Ensure the RichEdit DLL is loaded
        RichEditHandle = CreateWindowEx(0, MSFTEDIT_CLASS, TEXT(""),
            WS_CHILD | WS_VISIBLE | WS_BORDER | ES_MULTILINE | ES_AUTOVSCROLL,
            10, 10, 750, 550, hwnd, NULL, GetModuleHandle(NULL), NULL);
        ReadRTFFile(RichEditHandle,RTFFilename);
    }
       break;
    case WM_NCLBUTTONDOWN:
    {
       if (wp == HTCAPTION)
       {
        ShowLoading(MainWindowHandle);
       	ReadRTFFile(RichEditHandle, RTFFilename);
       	ShowMemoryUser(MainWindowHandle);
       } else
        return DefWindowProc(hwnd, msg, wp, lp);
    }
    break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hwnd, msg, wp, lp);
    }
    return 0;
}
int PASCAL
WinMain(HINSTANCE hinstCurr, HINSTANCE hinstPrev, LPSTR szCmdLine, int nCmdShow)
{
	WNDCLASS wc = { 0 };
	wc.lpfnWndProc = WndProc;
	wc.hInstance = hinstCurr;
	wc.lpszClassName = TEXT("MyLeaktestWindowClass");
	RegisterClass(&wc);
	MainWindowHandle = CreateWindow(wc.lpszClassName, TEXT("Click here.."),
		WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT,
		800, 600, NULL, NULL, hinstCurr, NULL);
	ShowWindow(MainWindowHandle, nCmdShow);
	UpdateWindow(MainWindowHandle);
    ShowMemoryUser(MainWindowHandle);
	MSG msg;
	while (GetMessage(&msg, NULL, 0, 0)) {
		TranslateMessage(&msg);
		DispatchMessage(&msg);
	}
	return 0;
}

Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-06T07:35:00.2733333+00:00

Hi @roy nelson , sorry for late response. Have you solved your issue yet? If you still have any question, please let us know! Thanks
roy nelson 25 Reputation points

2025-11-06T08:55:09.8666667+00:00

No, this seems to be a core bug in the how rtf containing images is handled the memory is never released and there appears to be no way of releasing it.
Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-10T06:38:26.96+00:00

Thanks for update, @roy nelson ! We'll investigate and return an answer asap!
Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-27T09:27:22.6766667+00:00

Hi @roy nelson , we just posted our response, I hope you can have a check! Thanks

Answer accepted by question author

2 additional answers

Your answer

Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-06T07:35:00.2733333+00:00

Hi @roy nelson , sorry for late response. Have you solved your issue yet? If you still have any question, please let us know! Thanks
roy nelson 25 Reputation points

2025-11-06T08:55:09.8666667+00:00

No, this seems to be a core bug in the how rtf containing images is handled the memory is never released and there appears to be no way of releasing it.
Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-10T06:38:26.96+00:00

Thanks for update, @roy nelson ! We'll investigate and return an answer asap!
Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-27T09:27:22.6766667+00:00

Hi @roy nelson , we just posted our response, I hope you can have a check! Thanks

Answer 1

@roy nelson You can control the memory usage when an rtf file contains images by implementing the IRichEditOleCallback interface. I haven't tested every type of image, but in a minimal test that loaded and reloaded an rtf file containing two images the memory leak appeared to be eliminated.

I added some modifications to your posted code, including using the right mouse button to initiate the reload of the rtf file.

Give this a try -

#include <windows.h>
#include <richedit.h>
#include <RichOle.h>
#include <psapi.h>
#include <crtdbg.h>

class RichCallback : public IRichEditOleCallback
{
public:
    RichCallback();
    // *** IUnknown methods ***
    STDMETHOD(QueryInterface) (REFIID riid, LPVOID FAR* ppvObj)
    {
        HRESULT	hr = E_NOINTERFACE;
        if (ppvObj == NULL)
            hr = E_POINTER;
        else
        {
            *ppvObj = NULL;
            if (riid == IID_IRichEditOleCallback || riid == IID_IUnknown)
            {
                *ppvObj = (LPVOID)this;
                AddRef();
                hr = S_OK;
            }
        }

        return hr;
    }

    STDMETHOD_(ULONG, AddRef) ()
    {
        m_ref++;
        return m_ref;
    }

    STDMETHOD_(ULONG, Release) ()
    {
        ULONG l = --m_ref;
        if (m_ref == 0)
            delete this;
        return l;
    }

    // *** IRichEditOleCallback methods ***
    STDMETHOD(GetNewStorage) (LPSTORAGE FAR* ppstg);
    STDMETHOD(GetInPlaceContext) (LPOLEINPLACEFRAME FAR* lplpFrame,
        LPOLEINPLACEUIWINDOW FAR* lplpDoc,
        LPOLEINPLACEFRAMEINFO lpFrameInfo) { return E_NOTIMPL;};
    STDMETHOD(ShowContainerUI) (BOOL fShow) { return E_NOTIMPL; };
    STDMETHOD(QueryInsertObject) (LPCLSID lpclsid, LPSTORAGE lpstg, LONG cp) { return S_OK; };
    STDMETHOD(DeleteObject) (LPOLEOBJECT lpoleobj) { return S_OK; };
    STDMETHOD(QueryAcceptData) (LPDATAOBJECT lpdataobj,
        CLIPFORMAT FAR* lpcfFormat, DWORD reco,
        BOOL fReally, HGLOBAL hMetaPict) { return E_NOTIMPL; };
    STDMETHOD(ContextSensitiveHelp) (BOOL fEnterMode) { return E_NOTIMPL; };
    STDMETHOD(GetClipboardData) (CHARRANGE FAR* lpchrg, DWORD reco,
        LPDATAOBJECT FAR* lplpdataobj) { return E_NOTIMPL; };
    STDMETHOD(GetDragDropEffect) (BOOL fDrag, DWORD grfKeyState, LPDWORD pdwEffect) { return E_NOTIMPL; };
    STDMETHOD(GetContextMenu) (WORD seltype, LPOLEOBJECT lpoleobj, CHARRANGE FAR* lpchrg, HMENU FAR* lphmenu) { return E_NOTIMPL; };

    //RichCallback Methods
    HRESULT ClearAndReallocate();
private:
    ~RichCallback();
    ULONG	m_ref, m_stgNum;
    IStorage* m_pStorage{};
    ILockBytes* m_pLockBytes{};
};

RichCallback::RichCallback() : m_ref(1), m_stgNum(0)
{
    HRESULT hr = ClearAndReallocate();
    _ASSERTE(SUCCEEDED(hr));

}

RichCallback::~RichCallback()
{
    m_pStorage->Release();
    m_pLockBytes->Release();
}

STDMETHODIMP RichCallback::GetNewStorage(LPSTORAGE FAR* ppstg)
{
    HRESULT hr{ E_FAIL };
    WCHAR	stgName[31]{}, wstgNum[4]{};

    wcscpy_s(stgName, _countof(stgName), L"rcbStg");
    _ultow_s(++m_stgNum, wstgNum, _countof(wstgNum), 10);
    wcscat_s(stgName, _countof(stgName), wstgNum);

    hr = m_pStorage->CreateStorage(stgName, STGM_READWRITE | STGM_SHARE_EXCLUSIVE | STGM_CREATE | STGM_DIRECT,
        0, 0, ppstg);

    _ASSERTE(SUCCEEDED(hr));

    return hr;
}

HRESULT RichCallback::ClearAndReallocate()
{
    HRESULT hr;
    if (m_pStorage)
    {
        m_pStorage->Release();
        m_pStorage = nullptr;
    }

    if (m_pLockBytes)
    {
        m_pLockBytes->Release();
        m_pLockBytes = nullptr;
    }

    HGLOBAL hMem = GlobalAlloc(GMEM_MOVEABLE, 1048576 * 20);

    if (hMem)
    {
        hr = CreateILockBytesOnHGlobal(hMem, TRUE, &m_pLockBytes);

        if (SUCCEEDED(hr) && m_pLockBytes)
            hr = StgCreateDocfileOnILockBytes(m_pLockBytes, STGM_READWRITE | STGM_SHARE_EXCLUSIVE | STGM_CREATE | STGM_DIRECT,
                0, &m_pStorage);
    }
    else
        hr = HRESULT_FROM_WIN32(GetLastError());

    _ASSERTE(SUCCEEDED(hr));

    return hr;
}


static const CHAR RTFFilename[] = "C:\\Users\\RLWA32\\Documents\\PicDoc.rtf";
static const TCHAR RTFFilename_t[] = TEXT("C:\\Users\\RLWA32\\Documents\\PicDoc.rtf");
HWND RichEditHandle, MainWindowHandle;
DWORD CALLBACK MyRead(DWORD_PTR dwCookie, LPBYTE pbBuffer, LONG cb, LONG *pcb)
{
    HFILE	hf = (HFILE) dwCookie;
    if(hf == HFILE_ERROR)
        return (DWORD) E_FAIL;
    *pcb = _lread(hf, pbBuffer, cb);
    return (DWORD) (*pcb >= 0 ? NOERROR : (*pcb = 0, E_FAIL));
}
SIZE_T GetCurrentProcessMemoryInfo()
{
    PROCESS_MEMORY_COUNTERS_EX pmc;
    pmc.cb = sizeof(pmc);
    GetProcessMemoryInfo(GetCurrentProcess(), (PPROCESS_MEMORY_COUNTERS)&pmc,sizeof(pmc));
    return (pmc.PrivateUsage / 1024);
}
void ReadRTFFile(HWND hwndRE,  LPCSTR szFile)
{
    EDITSTREAM es;
    DWORD dwFormat;
    es.dwCookie = (DWORD_PTR) _lopen(szFile, OF_READ);
    if(es.dwCookie == (DWORD_PTR) HFILE_ERROR) return;
    dwFormat = SF_RTF;
    es.dwError = 0;
    es.pfnCallback = MyRead;
    SendMessage(hwndRE,EM_STREAMIN,dwFormat, (LPARAM) &es);
    _lclose((HFILE) es.dwCookie);
    SendMessage(hwndRE, EM_SETMODIFY, (WPARAM) FALSE, 0);
    InvalidateRect(hwndRE, NULL, TRUE);
    UpdateWindow(hwndRE);
}
void ShowMemoryUser(HWND WindowH)
{
    TCHAR szT[256];
    wsprintf(szT, TEXT("Loaded... %s memory used: %dkb"), RTFFilename_t,GetCurrentProcessMemoryInfo());
    SetWindowText(WindowH, szT);
}
void ShowLoading(HWND WindowH)
{
    TCHAR szT[256];
    wsprintf(szT, TEXT("Loading... %s memory used: %dkb"), RTFFilename_t, GetCurrentProcessMemoryInfo());
    SetWindowText(WindowH, szT);
}
#ifndef UNICODE
#undef MSFTEDIT_CLASS
#define MSFTEDIT_CLASS		"RICHEDIT50W"
#endif
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) {
    static RichCallback *pRichCallback = new RichCallback;
   
    switch (msg) {
    case WM_CREATE: {
        LoadLibrary(TEXT("Msftedit.dll")); // Ensure the RichEdit DLL is loaded
        RichEditHandle = CreateWindowEx(0, MSFTEDIT_CLASS, TEXT(""),
            WS_VSCROLL | WS_CHILD | WS_VISIBLE | WS_BORDER | ES_MULTILINE | ES_AUTOVSCROLL,
            10, 10, 750, 550, hwnd, NULL, GetModuleHandle(NULL), NULL);
        SendMessage(RichEditHandle, EM_SETOLECALLBACK, 0, (LPARAM)pRichCallback);
        ReadRTFFile(RichEditHandle,RTFFilename);
    }
       break;
    case WM_NCRBUTTONDOWN:
    {
       if (wp == HTCAPTION)
       {
            pRichCallback->ClearAndReallocate();
            ShowLoading(MainWindowHandle);
            ReadRTFFile(RichEditHandle, RTFFilename);
            ShowMemoryUser(MainWindowHandle);
       }
       else
        return DefWindowProc(hwnd, msg, wp, lp);
    }
    break;
    case WM_DESTROY:
        pRichCallback->Release();
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hwnd, msg, wp, lp);
    }
    return 0;
}
int PASCAL
WinMain(HINSTANCE hinstCurr, HINSTANCE hinstPrev, LPSTR szCmdLine, int nCmdShow)
{
    WNDCLASS wc = { 0 };
    wc.lpfnWndProc = WndProc;
    wc.hInstance = hinstCurr;
    wc.lpszClassName = TEXT("MyLeaktestWindowClass");
    RegisterClass(&wc);

    OleInitialize(NULL);

    MainWindowHandle = CreateWindow(wc.lpszClassName, TEXT("Click here.."),
        WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT,
        800, 600, NULL, NULL, hinstCurr, NULL);
    ShowWindow(MainWindowHandle, nCmdShow);
    UpdateWindow(MainWindowHandle);
    ShowMemoryUser(MainWindowHandle);
    MSG msg;
    while (GetMessage(&msg, NULL, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    OleUninitialize();

    return 0;
}

roy nelson 25 Reputation points

2025-11-27T12:34:37.97+00:00

That looks promising... BUT I still see a leak? I am NOT even seeing the QI?? let alone GetNewStorage maybe I am doing something wrong? This is on Windows 11
RLWA32 51,361 Reputation points

2025-11-27T13:08:58.9433333+00:00

Did you copy my posted code EXACTLY? If you didn't, its possible you omitted a key line of code. For example, the creation of the RichCallback object or sending the EM_SETOLECALLBACK message.

You should be able to step through it in the debugger.
RLWA32 51,361 Reputation points

2025-11-27T13:29:00.26+00:00

I added some logging for the debug version that can be seen without the debugger using Sysinternals DebugView utility -
roy nelson 25 Reputation points

2025-11-27T15:38:20.3333333+00:00

That is very strange this is what I see... on my Win10 machine

I just tried to my file with Wordpad, and guess what it was BLOCKED the images are being blocked. It looks it is HOW the pngs that are embedded in my customer's RTF that is the issue, the OS is blocking. When I created new rtf from scratch and inserted my own pngs in they are inserted with different tags (as metafile and not pngblip )

) and then YOUR code works and there is no leak. So the mystery is resolved...
https://stackoverflow.com/questions/58389804/is-there-any-way-to-alter-security-settings-of-newest-version-of-wordpad-to-prev
Many thanks for your help!
RLWA32 51,361 Reputation points

2025-11-27T16:29:04.3333333+00:00

You are very welcome. If you think my code was helpful please consider accepting it as an Answer.

Answer 2

Michael Le (WICLOUD CORPORATION) 6,020 Microsoft External Staff Moderator

Hello @roy nelson ,

Sorry for the delayed response.

I have investigated this and can confirm the memory leak is reproducible. It appears this is due to internal caching mechanisms within the control that do not free memory even after the control is destroyed.

I attempted to resolve this doing these between loads:

Clearing the undo stack
Destroying the RichEdit window
Unloading the DLL

Unfortunately, none of these steps released the memory. As you can see from the picture, the memory usage continues to grow with each load (20 clicks).

User's image

Since the leak is contained within the current process, I found that creating the RichEdit control in a separate process and then terminating it, which seems to be a viable workaround to avoid running out of memory in this specific case.

User's image

But frankly, this is not an ideal solution. Having to spawn a separate process just to host a control is quite heavy-handed and may introduce additional complexity in terms of inter-process communication.

I doubt there is much that can be done to fix this, as it seems to be an inherent issue with the control itself. This control hasn't received any major updates for years. It is better to look for other alternatives.

roy nelson 25 Reputation points

2025-11-27T10:24:07.9133333+00:00

Indeed this is pretty much what I found as well which is why I created this straight C test case... Is there anywhere that Microsoft clearly states that this is a legacy control? Because I have a customer with this issue, but there appears to be no bug report that states this is a bug.
Michael Le (WICLOUD CORPORATION) 6,020 Reputation points Microsoft External Staff Moderator

2025-11-27T11:01:16.25+00:00

Is there anywhere that Microsoft clearly states that this is a legacy control?

Sorry for the misinformation. While there is technically no formal notice of this component’s deprecation, it has been in maintenance mode for years, receiving only a few compatibility updates. Its documentation has barely changed since the Windows 7/10 era.

For modern Windows app development, WinUI RichEditBox or WPF RichTextBox might be more suitable.

Answer 3

roy nelson 25

Yes, unfortunately I pasted it in... the GetNewStorage only seems to be called when I paste from the clipboard.

My document contains PNGs, I think it will use GDI+ to display those.

RLWA32 51,361 Reputation points

2025-11-27T13:37:32.5166667+00:00

I just created a new rtf document using Wordpad by having it insert 2 png images, not pasted from the clipboard. No memory leak when loading that document into the posted code.
RLWA32 51,361 Reputation points

2025-11-27T13:43:47.7066667+00:00

Also, don't forget that the sample code was based on reading a file. If you look closely at the IRichEditOleCallback implementation notice that it returns E_NOTIMPL for a number of methods. You could try changing those to return S_OK;

Share via

Loading simple RTF containing an image does not release memory on subsequent loads

2 additional answers

Your answer