Memory leaks in unpackaged C++-Desktop-App about microsoft-ui-xaml HOT 3 OPEN

For the first leak you mention here, it is a harmless leak.
When you create an instance of Application, via App, the runtime stashes an extra reference to Application somewhere. This is never released when the process exits. You can verify this by defining a destructor in App and placing a breakpoint in it, the breakpoint is never hit.
If you do some nasty things and release that final reference to App, the leaks almost completely go away. For example, if I override the Xaml defined entry point function and use the following:

#include "pch.h"
#include "App.xaml.h"

void nasty_stuff_that_frees_the_application(const winrt::Microsoft::UI::Xaml::Application &app);
void check_process_requirements();

int APIENTRY wWinMain(_In_ HINSTANCE, _In_opt_ HINSTANCE, _In_ LPWSTR, _In_ int)
{
	check_process_requirements();

	auto flags = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
	flags = (flags & 0x0000ffff) | _CRTDBG_LEAK_CHECK_DF;
	_CrtSetDbgFlag(flags);

	winrt::Microsoft::UI::Xaml::Application app = nullptr;

	winrt::Microsoft::UI::Xaml::Application::Start(
		[&app](auto &&)
		{
			app = winrt::make<winrt::Meh::implementation::App>();
		});

	nasty_stuff_that_frees_the_application(app);
	app = nullptr;

	return 0;
}

The following is the left over detected blocks of memory left allocated:

Detected memory leaks!
Dumping objects ->
{406} normal block at 0x000002D3241429D0, 32 bytes long.
 Data: <0 E       E     > 30 86 45 00 F6 7F 00 00 00 86 45 00 F6 7F 00 00 
{272} normal block at 0x000002D324142E50, 24 bytes long.
 Data: < -              > 18 2D 07 17 FF 7F 00 00 01 00 00 00 00 00 00 00 
Object dump complete.
The program '[15928] Meh.exe' has exited with code 0 (0x0).

I'm not going into how I released that last reference to Application because it is guaranteed to leave a dangling pointer somewhere in the Xaml runtime. While it doesn't cause problems now for short periods after it is deleted, there is no guarantee that there will never be a use after free in the future. If you want to work it out yourself, it is basically obtaining the ABI interface and releasing it without an AddRef or QI. But this is certainly not something that you should do, I'm only doing it here to illustrate a point.

The remaining two blocks could be related to the dispatcher queue, which I don't believe gets shut down either. But these are harmless because the amount of blocks does not grow and Windows will reclaim the memory when the process' heap gets destroyed when the process exits. However, I understand that these leaks can get in the way of debugging.

from microsoft-ui-xaml.

Thank you, Darran, for clarifying the facts. That at least explains that part. And yes, of course this makes troubleshooting more difficult and should definitely be fixed.
However, the second problem pointed out by the application is much more problematic (see points 5 and 6). The constantly growing memory requirements of the application will paralyse the system in a relatively short time. For our actual application, the memory problem is even worse, as it has to update an extensive GUI at very short intervals. This is currently preventing us from delivering the product and is absolutely critical.
It may not be a memory leak in the classic sense, but only in the sense that the memory is apparently still being released correctly before the app is exited. But not as long as the app is running. So it's just a question of timing.
Of course, it is important that this problem is fixed, because it is serious. For the moment, however, an explanation would help me, and above all a workaround.

from microsoft-ui-xaml.

In my opinion, an application that generates its own graphical elements and updates their display regularly is a standard use case. If such applications cause the user systems to crash, this is highly critical. Accordingly, this problem should also be classified here!
Is there anyone in the Microsoft team who can help with this?

from microsoft-ui-xaml.