Repository navigation
Blazor WASM AOT Compilation Failure #132071
Description
Activity
- addeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Aug 10, 2026 - addedneeds-author-actionAn issue or pull request that requires more info or actions from the author.An issue or pull request that requires more info or actions from the author.and removeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Aug 10, 2026 @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.ilDoes 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 ?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?
- addedneeds-further-triageIssue has been initially triaged, but needs deeper consideration or reconsiderationIssue has been initially triaged, but needs deeper consideration or reconsiderationand removedneeds-author-actionAn issue or pull request that requires more info or actions from the author.An issue or pull request that requires more info or actions from the author.
on Aug 20, 2026 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.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.
- addedneeds-author-actionAn issue or pull request that requires more info or actions from the author.An issue or pull request that requires more info or actions from the author.and removedneeds-further-triageIssue has been initially triaged, but needs deeper consideration or reconsiderationIssue has been initially triaged, but needs deeper consideration or reconsideration
on Aug 21, 2026 dotnet-policy-service commented
on Aug 21, 2026 ContributorMore actionsThis issue has been marked
needs-author-actionand may be missing some important information.- changed the title
[-]Blazor WASM AOT Compilation Failture[/-][+]Blazor WASM AOT Compilation Failure[/+]on Sep 14, 2026 @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,
Reacted by Pavel Savara@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.jsonrequests SDK10.0.100with feature-band roll
forward; the validating machine resolves this to SDK10.0.400. With WASM
SDK10.0.12, it fails during AOT precompilation with:DotnetRuntime132071Repro.dll -1073741571 aot-instances.dll -1073741571 0xC00000FD STATUS_STACK_OVERFLOWValidation 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.6The failure is deterministic in my testing. It also reproduces with
DisableParallelAot=trueandWasmDedup=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
closedSpecifiedParametersproperty 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.2The 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 isSTATUS_STACK_OVERFLOW, rather than an out-of-memory
or out-of-disk error.Reacted by Pavel SavaraComplex generics with constraints.
Let me know if you were able to reproduce or if you need more information from my side. :)
- added and removedneeds-author-actionAn issue or pull request that requires more info or actions from the author.An issue or pull request that requires more info or actions from the author.
on Oct 1, 2026 @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
SpecifiedParametersthrough a non-generic placeholder, or makeQueryParameterSeta class instead of a struct.Note
This comment was drafted with GitHub Copilot.
Is there an existing issue for this?
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.execommand that failed. When I run that command directly, I end up with: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