The program '.exe' has exited with code 3221226356 (0xc0000374).

[cedric56]

Hello, can someone knows why sometimes this exception occurs when i try to launch my application. This crashs occurs on Microsoft.UI.Xaml.Hosting.WindowsXamlManager.InitializeForCurrentThread().

I am trying to launch an winui3 window from avalonia.

internal sealed class Program
{
    // Initialization code. Don't use any Avalonia, third-party APIs or any
    // SynchronizationContext-reliant code before AppMain is called: things aren't initialized
    // yet and stuff might break.
    [STAThread]
    public static void Main(string[] args) => BuildAvaloniaApp()
        .StartWithClassicDesktopLifetime(args);

    // Avalonia configuration, don't remove; also used by visual designer.
    public static AppBuilder BuildAvaloniaApp()
    {
        var app = AppBuilder.Configure<App>()
            .UsePlatformDetect()
            .WithInterFont()
            .LogToTrace()
            .UseReactiveUI();
        app.AfterSetup(builder =>
        {

            Microsoft.UI.Dispatching.DispatcherQueueController.CreateOnCurrentThread();
            var windowsXamlManager = Microsoft.UI.Xaml.Hosting.WindowsXamlManager.InitializeForCurrentThread();
            var winUIWindow = new Microsoft.UI.Xaml.Window();
            Microsoft.Maui.ApplicationModel.Platform.OnPlatformWindowInitialized(winUIWindow);
        });
        return app;
    }
}

[DarranRowe]

The NTSTATUS 0xC0000374 is STATUS_HEAP_CORRUPTION. This means that something is corrupting the native process heap.

To give a quick example of how this error can occur:

#include <Windows.h>
#include <string>

int wmain()
{
	auto pdw = HeapAlloc(GetProcessHeap(), 0, sizeof(DWORD));
	//The following line is deliberately incorrect and will cause a heap
	//corruption. 
	*reinterpret_cast<uint64_t *>(static_cast<BYTE *>(pdw)-4) = 50;

	HeapFree(GetProcessHeap(), 0, pdw);
	pdw = nullptr;

	return 0;
}

Heap corruption is caused when a write to memory corrupts the heap control block. This above example deliberately decreases the pointer so that it is in the heap control block allocated by HeapAlloc. There are other ways of triggering this bug too.

The problem is, if Avalonia is doing thigs properly, then a class that acts like the Xaml App must be declared too. But the issue here is that there is metadata querying going on too. This unfortunately means that there could be a bug in Avalonia.

[cedric56]

@DarranRowe This is also happening when i move the instantiation out of avalonia. Could it be a bug in avalonia ?

[STAThread]
public static void Main(string[] args)
{
    Microsoft.UI.Dispatching.DispatcherQueueController.CreateOnCurrentThread();
    var windowsXamlManager = Microsoft.UI.Xaml.Hosting.WindowsXamlManager.InitializeForCurrentThread();
    var winUIWindow = new Microsoft.UI.Xaml.Window();
    Microsoft.Maui.ApplicationModel.Platform.OnPlatformWindowInitialized(winUIWindow);
    
    BuildAvaloniaApp()
    .StartWithClassicDesktopLifetime(args, builder =>
    {
        builder.Exit += (sender, e) => winUIWindow.Close();
    });

}
// Avalonia configuration, don't remove; also used by visual designer.
public static AppBuilder BuildAvaloniaApp()
{
    var app = AppBuilder.Configure<App>()                
        .UsePlatformDetect()
        .WithInterFont()
        .LogToTrace()
        .UseReactiveUI();
    return app;
}

[DarranRowe]

The heap corruption doesn't happen for C++ applications.

But here is something interesting to try. Try not calling WindowsXamlManager.InitializeForCurrentThread. There is something in the documentation that allows this.

"You need to explicitly call this method only if your application creates the Windows.UI.Xaml.UIElement objects before it creates the DesktopWindowXamlSource object that will host them."

Essentially, Microsoft.UI.Xaml.Window does the same thing. But there is one problem, and that is how early the UI elements are made in your code.

	winrt::init_apartment(winrt::apartment_type::single_threaded);
	auto dispatcherQueueController{ winrt::DispatcherQueueController::CreateOnCurrentThread() };

	auto xamlIslandApp{ winrt::make<winrt::XamlIslandTest3New::implementation::XamlIslandApp>() };

	const wchar_t szWindowClass[] = L"XamlIslandTest2Class";
	const wchar_t szTitle[] = L"Xaml Island Test 3";

	MyRegisterClass(hInstance, szWindowClass);

	HWND topLevelWindow = InitInstance(hInstance, nCmdShow, szTitle, szWindowClass);

This is the code that I use in the sample application that I took the screenshot from. The general flow of it is:

1. Initialise the thread for WinRT, this is equivalent of [STAThread]
2. Create the dispatcher queue.
3. Create the Application object, XamlIslandApp "derives" from Microsoft.UI.Xaml.Application. This object also has the metadata provider.
4. The Window stuff is created, this is where the WindowsXamlManager/DesktopWindowXamlSource are initialised.

The important thing is that the application is created before Xaml is initialised on the thread. But even calling things in the wrong order results in an E_UNEXPECTED error, not heap corruption. So there is something that isn't related to WinUI 3 that is failing.

[cedric56]

So, i replaced with the code under and it's happening. I also tried what you have mentionned running an Microsoft.UI.Xaml.Application (with and without an maui application) and the crash occurs as well. I assume that you have right an the bug comes from avalonia.

              Microsoft.UI.Dispatching.DispatcherQueueController.CreateOnCurrentThread();

               var desktop = new Microsoft.UI.Xaml.Hosting.DesktopWindowXamlSource();

               //Microsoft.UI.Xaml.Hosting.WindowsXamlManager.InitializeForCurrentThread();

               WinUIWindow = new MauiWinUIWindow();
               
               Microsoft.Maui.ApplicationModel.Platform.OnPlatformWindowInitialized(WinUIWindow);

Then i tried directly with avalonia source code here is the stack trace

ntdll.dll!RtlReportCriticalFailure()	Unknown
 	ntdll.dll!RtlpHeapHandleError()	Unknown
 	ntdll.dll!RtlpHpHeapHandleError()	Unknown
 	ntdll.dll!RtlpLogHeapFailure()	Unknown
 	ntdll.dll!RtlpFreeHeapInternal()	Unknown
 	ntdll.dll!RtlFreeHeap()	Unknown
 	iertutil.dll!00007ff92cb0aad4()	Unknown
 	iertutil.dll!00007ff92cb15bf2()	Unknown
 	iertutil.dll!00007ff92cb07ca3()	Unknown
 	iertutil.dll!00007ff92cb079a6()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bb4239()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899a86b10()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899a867c6()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899b76c7c()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899b76db7()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899b76bc0()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899f36863()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899dee793()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bbbce4()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bbac42()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899c0cf63()	Unknown
 	Microsoft.ui.xaml.dll!00007ff89a41a39c()	Unknown
 	Microsoft.ui.xaml.dll!00007ff89a419f6c()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899d8010a()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899aba69e()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899ab67ed()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899ab78d7()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bb95e4()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899ee6e24()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899cac7f3()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899ca1b08()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899ca1a40()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bbdc76()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bbdb8a()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bbc147()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899bbb309()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899c0cfbb()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899c0cb95()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899c0f22c()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899c0f121()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899d1b14f()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899d048fd()	Unknown
 	Microsoft.ui.xaml.dll!00007ff899d0480e()	Unknown
>	Microsoft.ui.xaml.dll!00007ff899d04752()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff89979ca6f()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff89979fb7e()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997c9f1a()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997b2174()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997b6870()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997aa1d2()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997a9f6e()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997c8db9()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997c7e16()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997cb6cb()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997c7833()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff899880c82()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff8997399c0()	Unknown
 	Microsoft.VisualStudio.DesignTools.WinUITap.dll!00007ff89987951d()	Unknown
 	CoreMessagingXP.dll!00007ff90f933715()	Unknown
 	CoreMessagingXP.dll!00007ff90f8e09fd()	Unknown
 	CoreMessagingXP.dll!00007ff90f8e4a56()	Unknown
 	CoreMessagingXP.dll!00007ff90f8eb090()	Unknown
 	CoreMessagingXP.dll!00007ff90f8bb8cf()	Unknown
 	CoreMessagingXP.dll!00007ff90f8f9022()	Unknown
 	CoreMessagingXP.dll!00007ff90f8bc880()	Unknown
 	CoreMessagingXP.dll!00007ff90f8bc5ed()	Unknown
 	CoreMessagingXP.dll!00007ff90f8afd7c()	Unknown
 	CoreMessagingXP.dll!00007ff90f8b2c66()	Unknown
 	CoreMessagingXP.dll!00007ff90f8b2fdc()	Unknown
 	CoreMessagingXP.dll!00007ff90f8f36a3()	Unknown
 	CoreMessagingXP.dll!00007ff90f8f3836()	Unknown
 	CoreMessagingXP.dll!00007ff90f8f3dae()	Unknown
 	user32.dll!00007ff93eb48ed8()	Unknown
 	user32.dll!00007ff93eb4898c()	Unknown
 	user32.dll!00007ff93eb53e3d()	Unknown
 	ntdll.dll!KiUserCallbackDispatcherContinue()	Unknown
 	win32u.dll!00007ff93c841584()	Unknown
 	user32.dll!00007ff93eb5616a()	Unknown
 	[Managed to Native Transition]	
 	Avalonia.Win32.dll!Avalonia.Win32.Win32DispatcherImpl.RunLoop(System.Threading.CancellationToken cancellationToken) Line 107	C#
 	Avalonia.Base.dll!Avalonia.Threading.DispatcherFrame.Run(Avalonia.Threading.IControlledDispatcherImpl impl) Line 121	C#
 	Avalonia.Base.dll!Avalonia.Threading.Dispatcher.PushFrame(Avalonia.Threading.DispatcherFrame frame) Line 53	C#
 	Avalonia.Base.dll!Avalonia.Threading.Dispatcher.MainLoop(System.Threading.CancellationToken cancellationToken) Line 80	C#
 	Avalonia.Controls.dll!Avalonia.Controls.ApplicationLifetimes.ClassicDesktopStyleApplicationLifetime.StartCore(string[] args) Line 143	C#
 	Avalonia.Controls.dll!Avalonia.Controls.ApplicationLifetimes.ClassicDesktopStyleApplicationLifetime.Start(string[] args) Line 120	C#
 	Avalonia.Controls.dll!Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime(Avalonia.AppBuilder builder, string[] args, System.Action<Avalonia.Controls.ApplicationLifetimes.IClassicDesktopStyleApplicationLifetime> lifetimeBuilder) Line 277	C#
 	AvaloniaApplication1.Desktop.dll!AvaloniaApplication1.Desktop.Program.Main(string[] args) Line 13	C#
 	[Native to Managed Transition]	
 	hostpolicy.dll!00007ff91e0926ac()	Unknown
 	hostpolicy.dll!00007ff91e09297c()	Unknown
 	hostpolicy.dll!00007ff91e09328a()	Unknown
 	hostfxr.dll!00007ff91e0ed9a6()	Unknown
 	hostfxr.dll!00007ff91e0eff26()	Unknown
 	hostfxr.dll!00007ff91e0f200c()	Unknown
 	hostfxr.dll!00007ff91e0f04f3()	Unknown
 	hostfxr.dll!00007ff91e0e8350()	Unknown
 	AvaloniaApplication1.Desktop.exe!00007ff69bacf888()	Unknown
 	AvaloniaApplication1.Desktop.exe!00007ff69bacfc96()	Unknown
 	AvaloniaApplication1.Desktop.exe!00007ff69bad11b8()	Unknown
 	kernel32.dll!00007ff93e0e259d()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

[DarranRowe]

One of the big problems with heap corruption is that by the time the exception is thrown, the corruption has been and gone. It is even possible that the code that corrupted the heap has been unloaded if it is in a DLL.

To show another C++ example:

#include <Windows.h>
#include <string>

void *allocate_a()
{
	return HeapAlloc(GetProcessHeap(), 0, sizeof(uint32_t));
}

void deallocate_a(void *a)
{
	HeapFree(GetProcessHeap(), 0, a);
}

void *allocate_b()
{
	return HeapAlloc(GetProcessHeap(), 0, sizeof(uint32_t));
}

void deallocate_b(void *b)
{
	HeapFree(GetProcessHeap(), 0, b);
}

bool corrupt_memory(void *a, void *b)
{
	bool result = false;
	auto ca = static_cast<char *>(a);
	auto cb = static_cast<char *>(b);

	if (a < b)
	{
		//Indicates that a was at a lower address.
		//This means that the write to a corrupted b,
		//and b should be deallocated first.

		ptrdiff_t pdiff = cb - ca;

		memset(a, 0, pdiff);
		result = true;
	}
	else
	{
		ptrdiff_t pdiff = ca - cb;

		memset(b, 0, pdiff);
	}

	return result;
}

int wmain()
{
	auto a = allocate_a();
	auto b = allocate_b();

	//The way the Windows heap works currently means that b
	//will be at a lower address than a. So we take the
	//difference in address and just write however many bytes are
	//between the two pointers.
	//This works because the implementation has the initial heap
	//in one large block, so it is possible to write between the
	//two, and the vital structure that is being corrupted is
	//just before the block of memory.
	//The name of the function should give it away, but the
	//code in the function is bad. It deliberately writes outside
	//of its allocated block. DO NOT THINK THAT THIS IS ENDORSING
	//THIS KIND OF CODE.
	auto corrupt_result = corrupt_memory(a, b);

	//The return from the memory corruption function indicates
	//what pointer was at a lower address. It should be b, but
	//implementation can change. We want to know this so that we
	//free the block of memory we never wrote to first.
	//This shows that the exception doesn't have to be raised on
	//the bad write of memory, or even in relation to the pointer
	//that was written to. In this case, the first block freed is
	//unrelated to the bug, but the exception is raised when we
	//try to free it.
	if (corrupt_result)
	{
		deallocate_b(b);
		deallocate_a(a);
	}
	else
	{
		deallocate_a(a);
		deallocate_b(b);
	}
	return 0;
}

This is more interesting for this case because the corruption is caused by a write to one pointer, and this corrupts the heap control block for another. This is a bit heavy on comments to try to explain what is going on.

To give a general overview, the code allocates two pointers. It figures out which pointer is at the lowest address and then writes to it. But it overruns the block of memory by a lot. The code then frees the block of memory that WAS NOT written to. I highlight this for an important reason, the heap corruption exception is raised when deallocating an unrelated pointer.

This is one of the biggest problems with heap corruptions, the code that corrupts the heap can be completely unrelated to the block of memory that gets corrupted. Also, since the corruption is mostly detected when the application tries to deallocate the corrupted block, then the exception can be raised in a completely unrelated location.