Blazor WASM AOT Compilation Failure

Is there an existing issue for this?

I have searched the existing issues

Describe the bug

Hi,

We have a problem with Blazor WASM AOT compilation that I cannot seem to diagnose. From dotnet publish, I get the error:
C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\10.0.10\Sdk\WasmApp.Common.targets(672,5): Error : Precompiling failed for G:\source\xxxx\src\xxxx\obj\Release\net10.0\wasm\for-publish\aot-in\xxxxx.dll with exit code -1073741571.

The same error appears when building on our Azure DevOps Linux-based agents.

The build output includes the mono-aot-cross.exe command that failed. When I run that command directly, I end up with:

Failed to load method 0x600014e from 'G:\source\xxxx\src\xxxxx\bin\Release\net10.0\xxxxx.dll' due to Could not resolve type with token 0100001f from typeref (expected class 'System.Collections.Generic.Dictionary`2' in assembly 'System.Collections, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a') assembly:System.Collections, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a type:System.Collections.Generic.Dictionary`2 member:(null).

The xxxx.dll is a custom .NET 10 library. I am not sure what triggers this problem. How do I find which method 0x600014e is, and what type 0100001f is?

The .NET version mentioned here is the current insider preview, but the same issue occurs on the latest stable.

Expected Behavior

Successful compilation, or a more detailed error message pointing to the problem.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

10.0.400-preview.0.26322.102

Anything else?

No response

@ChristopherHaas

@ChristopherHaas we need minimal repro, currently this is not actionable.

How do I find which method 0x600014e is, and what type 0100001f is?

ildasm MyAssembly.dll /text /tokens > output.il
findstr /i "06000042" output.il

Does it happen randomly or deterministically ?
What's interesting about the failing method ? What data types does it use ?
Does the compiler have enough memory and disk space ?

@pavelsavara

Thank you very much for responding @pavelsavara. I am no longer able to reproduce the error by manually invoking mono-aot-cross.exe with the arguments provided in the build output after updating to v10.0.11. When I run the command directly, it succeeds without errors. However, running dotnet publish, or publishing from VS, still gives the same error. I.e.

C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\10.0.11\Sdk\WasmApp.Common.targets(672,5): Error : Precompiling failed for G:\source\Unison\src\xxxxxx\obj\Release\net10.0\wasm\for-publish\aot-in\xxxx.dll with exit code -1073741571.

I have checked disk space and memory as suggested, and there is plenty of headroom. Do you have any suggestions for how I can diagnose this problem further?

With some inspiration from seemingly similar issues (#61053, shimat/opencvsharp_blazor_sample#8), I have tried running publish with following switches:

dotnet publish -c Release -bl -p:DisableParallelAOT=true -p:WasmAllowUndefinedSymbols=true -p:WasmNativeDebugSymbols=false -p:WasmEnableExceptionHandling=false -p:WasmEnableSIMD=false
Unfortunately the AOT build error is the same.

@ChristopherHaas

Does it happen randomly or deterministically ?
What's interesting about the failing method ?
What data types does the method use ?

@ChristopherHaas try to answer my other questions.

Also update to latest Net11 preview and test if that helps.

Work toward reproduction case that you can share with us. Provide as many details as possible.

This issue has been marked needs-author-action and may be missing some important information.

@pavelsavara

@pavelsavara i have taken over investigation from @ChristopherHaas. I am working on narrowing down the piece of code that results in the failure. Will update soon,

@pavelsavara

@pavelsavara i have reduced the failure to a source-only Blazor WebAssembly project.

I have attached the complete project as DotnetRuntime132071Repro.zip

On Windows, global.json requests SDK 10.0.100 with feature-band roll
forward; the validating machine resolves this to SDK 10.0.400. With WASM
SDK 10.0.12, it fails during AOT precompilation with:

DotnetRuntime132071Repro.dll  -1073741571
aot-instances.dll             -1073741571
0xC00000FD                  STATUS_STACK_OVERFLOW

Validation environment:

OS:              Windows 10.0.26200 (win-x64)
.NET SDK:        10.0.400
Workload:        10.0.401
Runtime/host:    10.0.11
wasm-tools:      10.0.112/10.0.100
MSBuild:         18.9.6

The failure is deterministic in my testing. It also reproduces with
DisableParallelAot=true and WasmDedup=false, so it is not dependent on
parallel AOT compilation or generic deduplication. Managed compilation and
trimming complete successfully; the failing process is native
mono-aot-cross.

The attached generated file contains the reduced query shape. Replacing the
closed SpecifiedParameters property with a non-generic placeholder makes
the AOT publish succeed.

I also tested .NET 11 RC1:

SDK:             11.0.100-rc.1.26425.128
WASM workload:   11.0.0-rc.1.26425.128
Emscripten:      6.0.2

The same native exit code and failing assembly set were observed with this
toolchain.

I checked memory and disk space during the investigation and had substantial
headroom. The status is STATUS_STACK_OVERFLOW, rather than an out-of-memory
or out-of-disk error.

Complex generics with constraints.

Let me know if you were able to reproduce or if you need more information from my side. :)

@mafiheron

@mafiheron thank you for the source-only repro, it made this straightforward to track down.

The crash is a stack overflow in the Mono AOT compiler, and generic constraints turn out not to matter. It happens whenever a struct has a field whose type is a generic struct instantiated over the struct itself. In your repro that is ExactTestQuery.SpecifiedParameters : QueryParameterSet<..., ExactTestQuery>. The smallest trigger is:

public struct Box<T> { public object? O; }
public struct Self { public Box<Self> F; }

public static class Calls
{
    public static T Id<T>(T value) => value;
    public static Self Call(Self value) => Id(value);
}

When the compiler builds wrappers for shared generic code, it simplifies a struct's layout by walking its fields, and the type arguments of those fields, without remembering which structs it is already processing. So Self -> Box<Self> -> Self -> ... recurses until the stack overflows. The fix is in #135029.

Until a release contains the fix, the workaround is the one you already found: avoid a struct field whose generic type argument is the containing struct. For example, store SpecifiedParameters through a non-generic placeholder, or make QueryParameterSet a class instead of a struct.

Note

This comment was drafted with GitHub Copilot.

Navigation Menu

Repository navigation

Blazor WASM AOT Compilation Failure #132071

Is there an existing issue for this?

Describe the bug

Expected Behavior

Steps To Reproduce

Exceptions (if any)

.NET Version

Anything else?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Blazor WASM AOT Compilation Failure #132071

Description

Is there an existing issue for this?

Describe the bug

Expected Behavior

Steps To Reproduce

Exceptions (if any)

.NET Version

Anything else?

Activity

pavelsavara commented on Aug 10, 2026

ChristopherHaas commented on Aug 20, 2026

ChristopherHaas commented on Aug 21, 2026

pavelsavara commented on Aug 21, 2026

dotnet-policy-service commented on Aug 21, 2026

mafiheron commented on Sep 14, 2026

mafiheron commented on Sep 15, 2026

pavelsavara commented on Sep 15, 2026

mafiheron commented on Sep 16, 2026

pavelsavara commented on Oct 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions