Skip to content

Blazor WASM AOT Compilation Failure #132071

Description

@ChristopherHaas

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

Activity

  1. transferred this issue fromdotnet/aspnetcoreon Aug 10, 2026
  2. added this to the 10.0.x milestone on Aug 10, 2026
  3. added
    needs-author-actionAn issue or pull request that requires more info or actions from the author.
    and removed
    untriagedNew issue has not been triaged by the area owner
    on Aug 10, 2026
  4. pavelsavara commented on Aug 10, 2026

    @pavelsavara
    Member

    @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 ?

  5. self-assigned this
    on Aug 10, 2026
  6. ChristopherHaas commented on Aug 20, 2026

    @ChristopherHaas
    Author

    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?

  7. added
    needs-further-triageIssue has been initially triaged, but needs deeper consideration or reconsideration
    and removed
    needs-author-actionAn issue or pull request that requires more info or actions from the author.
    on Aug 20, 2026
  8. ChristopherHaas commented on Aug 21, 2026

    @ChristopherHaas
    Author

    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.

  9. pavelsavara commented on Aug 21, 2026

    @pavelsavara
    Member

    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.

  10. added
    needs-author-actionAn issue or pull request that requires more info or actions from the author.
    and removed
    needs-further-triageIssue has been initially triaged, but needs deeper consideration or reconsideration
    on Aug 21, 2026
  11. dotnet-policy-service commented on Aug 21, 2026

    @dotnet-policy-service
    Contributor

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

  12. changed the title [-]Blazor WASM AOT Compilation Failture[/-] [+]Blazor WASM AOT Compilation Failure[/+] on Sep 14, 2026
  13. mafiheron commented on Sep 14, 2026

    @mafiheron

    @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,

  14. mafiheron commented on Sep 15, 2026

    @mafiheron

    @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.

  15. pavelsavara commented on Sep 15, 2026

    @pavelsavara
    Member

    Complex generics with constraints.

  16. mafiheron commented on Sep 16, 2026

    @mafiheron

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

  17. added and removed
    needs-author-actionAn issue or pull request that requires more info or actions from the author.
    on Oct 1, 2026
  18. pavelsavara commented on Oct 1, 2026

    @pavelsavara
    Member

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions