aapt2.exe crashes with access violation (BEX64) in daemon mode when spawned by Aapt2Compile — hangs build indefinitely

[jflietstra]

Android framework version

net10.0-android

Affected platform version

Visual Studio 2026 18.9.2, .NET SDK 10.0.400, Microsoft.Android.Sdk.Windows 36.1.69 (aapt2 2.20-13193326), Windows 11 Pro 10.0.26200.2 (not Insider), Dell XPS 16 / Intel Core i9

Description

aapt2.exe crashes with STATUS_ACCESS_VIOLATION (0xc0000005) every single time it is invoked in daemon mode by the Aapt2Compile/_CompileResources MSBuild target, on one specific (otherwise healthy) machine. The build appears to "hang" forever because the MSBuild task never notices the child process died, and just waits for a response that never comes — no error is ever surfaced anywhere in the MSBuild output.

Running the exact same aapt2.exe daemon command manually, interactively, in a normal console window (i.e. NOT spawned by MSBuild/System.Diagnostics.Process with redirected stdio and CreateNoWindow=true) works perfectly — it prints Ready and sits waiting for input, no crash. aapt2.exe version also works fine either way, which rules out a missing dependency (e.g. VC++ runtime) since all statically-declared DLL imports resolve correctly.

Crash details (Event Viewer / WER):

Faulting application name: aapt2.exe, version: 0.0.0.0, time stamp: 0x1f2830d0
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Faulting application path: C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\36.1.69\tools\aapt2.exe

Event Name: BEX64
P7: PCH_xx_FROM_ntdll+0x0000000000161914   (consistent offset across 3 independent runs, only the PCH_xx prefix varies)
P8: c0000005

Report.wer's LoadedModule list at crash time contains ONLY aapt2.exe plus stock Windows system DLLs (ntdll, KERNEL32, KERNELBASE, ucrtbase, SHELL32, msvcp_win, USER32, win32u, GDI32, gdi32full, IMM32, shcore, advapi32, msvcrt, sechost, RPCRT4, CRYPTBASE, bcryptPrimitives) — nothing from any antivirus/EDR/overlay software is loaded, which rules out third-party hooking as the cause.

What was ruled out (none of these changed the outcome):

• Windows Defender exclusions for the project folder, Android SDK folder, .nuget, .gradle, .android
• Malwarebytes real-time protection fully disabled
• NVIDIA app/GeForce Experience overlay disabled
• Full Clean Boot (msconfig: all non-Microsoft services/startup items disabled, machine rebooted) — crash still 100% reproducible at the identical ntdll offset
• Windows Security → Exploit Protection → Program settings inspected — only stock Microsoft default entries present, nothing custom targets dotnet.exe/MSBuild.exe/devenv.exe/aapt2.exe
• dotnet workload repair (full repair of android, ios, maccatalyst, maui-windows) — completed successfully, crash persists identically
• Removing a newly-added MauiImage resource from the project — crash still occurs on the remaining stock app-icon/splash resources
• Not enrolled in the Windows Insider Program
• Killed orphaned aapt2.exe processes from a previously-cancelled build + rebooted before retrying — no change
• Reproduces identically via plain dotnet build -f net10.0-android from the command line AND via the Visual Studio 2026 IDE — not VS-IDE-specific

Further narrowing:

• Setting <Aapt2DaemonMaxInstanceCount>1</Aapt2DaemonMaxInstanceCount> in the .csproj (default allows up to 6 parallel daemon instances) delayed the crash — the build appeared to progress actively for ~70 to ~330 seconds before hitting the identical crash — but did not prevent it.
• Manual interactive aapt2.exe daemon (own console, not spawned by MSBuild) never crashes, which points at something specific to how Aapt2Daemon launches the process (CreateNoWindow=true, RedirectStandardInput/Output/Error=true, UseShellExecute=false) rather than a bug that triggers in daemon mode unconditionally.

Happy to attach the full .dmp file (available locally under C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_aapt2.exe_...) or run further diagnostics on request.

As a secondary ask: even a fix that makes a crashed daemon child surface as a build error instead of hanging forever would make this whole class of problem far easier to diagnose.

Steps to Reproduce

1. .NET MAUI app project, <TargetFrameworks>net10.0-android</TargetFrameworks>, Microsoft.Maui.Controls 10.0.90.
2. Run dotnet build -f net10.0-android -v detailed (reproduces identically via Visual Studio 2026 Build/Rebuild).
3. Build proceeds normally through NuGet restore, Clean, and dozens of MSBuild targets.
4. Build reaches _CompileResources (invokes the Aapt2Compile task).
5. aapt2.exe is spawned in daemon mode and crashes near-instantly with an access violation (see Event Viewer output above).
6. The MSBuild task never detects the child process death and blocks forever — build must be cancelled manually, no error is ever printed.

Did you find any workaround?

No true fix found. Setting <Aapt2DaemonMaxInstanceCount>1</Aapt2DaemonMaxInstanceCount> in the .csproj delays the crash (build runs for ~1-5 minutes before hitting it) but does not prevent it.

Relevant log output

[jflietstra]

Update: got a persistent crash dump (via WER LocalDumps registry key) and opened it in Visual Studio's native debugger. This changes the diagnosis significantly — the crash is entirely inside aapt2.exe's own code, not in ntdll.dll as the Event Viewer summary's stack-hash bucketing (PCH_xx_FROM_ntdll+0x161914) seemed to suggest. That field appears to just be a heuristic used for WER bucketing, not the actual crash frame.

Call stack from VS (native-only debugging of the .dmp; no PDB available for aapt2.exe so frames are unsymbolicated, but the structure is clear):

>	0000000000000065()	Unknown
 	aapt2.exe!00007ff7f01fa78d()	Unknown
 	aapt2.exe!00007ff7f03503b5()	Unknown
 	aapt2.exe!00007ff7f034bd31()	Unknown
 	aapt2.exe!00007ff7f034beef()	Unknown
 	aapt2.exe!00007ff7f01fa6b0()	Unknown
 	aapt2.exe!00007ff7f003525a()	Unknown
 	aapt2.exe!00007ff7f00312a0()	Unknown
 	aapt2.exe!00007ff7f00372e8()	Unknown
 	aapt2.exe!00007ff7f002cb38()	Unknown
 	aapt2.exe!00007ff7f002cbf5()	Unknown
 	aapt2.exe!00007ff7f0029c83()	Unknown
 	aapt2.exe!00007ff7f002cb38()	Unknown
 	aapt2.exe!00007ff7f002cbf5()	Unknown
 	aapt2.exe!00007ff7f0021757()	Unknown
 	aapt2.exe!00007ff7f0021d8d()	Unknown
 	aapt2.exe!00007ff7f0021395()	Unknown
 	aapt2.exe!00007ff7f00214c8()	Unknown
 	kernel32.dll!00007ff9a73cccb7()	Unknown
 	ntdll.dll!00007ff9a920caec()	Unknown

The top frame executes at 0x0000000000000065 — a near-null address — meaning aapt2.exe's own code (18 frames deep in what looks like its resource-compile logic, given the recursive-looking pattern at 002cb38/002cbf5) makes an indirect call through a function pointer / vtable slot that holds 0x65 instead of a valid address. The bottom two frames (kernel32!BaseThreadInitThunk, ntdll!RtlUserThreadStart) are just the standard thread-start boilerplate for any Windows thread.

This is consistent with everything else observed: every environment-level mitigation we tried (AV exclusions, disabling Malwarebytes/NVIDIA overlay, a full Clean Boot, elevated vs. non-elevated, Exploit Protection settings) made zero difference, because this looks like a genuine bug in this specific aapt2.exe Windows build (2.20-13193326) itself, only reached once it actually processes a real compile command (manually starting aapt2.exe daemon interactively and leaving it idle at the Ready prompt never crashes, since that never exercises this code path).

Also worth noting: the same project builds fine via dotnet build on a ubuntu-latest GitHub Actions runner (different, separately-compiled Linux aapt2 binary from Microsoft.Android.Sdk.Linux), which is additional evidence this is specific to the Windows aapt2.exe build rather than the project or a general aapt2 daemon-mode issue.

Happy to attach the actual .dmp file if useful (now persisted via LocalDumps) — let me know where/how to best share it.

[jonathanpeppers]

@jflietstra we don't build aapt2, we just redistribute it.

Did you mean to file this with Google? Thanks!

https://issuetracker.google.com/

[dotnet-policy-service]

Hi @jflietstra. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.