android-tombstone-symbolication

Resolve .NET runtime native frames in Android tombstones using BuildIds and llvm-symbolizer.

1|Updated May 21, 2026
One-click install
npx skills add https://github.com/1k-off/umbraco-observability-playground --skill android-tombstone-symbolication-1k-off
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: android-tombstone-symbolication
Source: https://github.com/1k-off/umbraco-observability-playground/tree/main/.agents/skills/android-tombstone-symbolication
Command: npx skills add https://github.com/1k-off/umbraco-observability-playground --skill android-tombstone-symbolication-1k-off

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

It helps you turn low-level Android crash tombstones into readable .NET runtime backtraces with function names, source files, and line numbers, so you can triage MAUI/Xamarin/Mono crashes much faster.

Core Features & Use Cases

  • .NET-native frame identification: Detects frames belonging to .NET runtime libraries such as libmonosgen-2.0.so and libcoreclr.so (and common .NET native BCL libraries).
  • BuildId-based symbol resolution: Extracts ELF BuildIds and uses the Microsoft symbol server to download matching debug symbols, then runs llvm-symbolizer to resolve PC offsets.
  • CI-friendly automation for debugging: Automates the full parse → download → symbolication workflow via a single PowerShell script, including a ParseOnly mode for planning/triage.
  • Use Case: When a .NET MAUI app crashes on Android with SIGABRT/SIGSEGV and your log shows a native tombstone, run this skill to map the native frames back to .NET runtime code locations (e.g., mono/metadata/icall.c with a specific line), instead of manually guessing.

Quick Start

Run Symbolicate-Tombstone.ps1 on your tombstone file and produce a symbolicated backtrace: pwsh scripts/Symbolicate-Tombstone.ps1 -TombstoneFile tombstone_01.txt -LlvmSymbolizer llvm-symbolizer -OutputFile symbolicated.txt

Frequently Asked Questions about android-tombstone-symbolication

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I symbolicate an Android tombstone for a .NET MAUI crash?

To symbolicate an Android tombstone for a .NET MAUI crash, you can run a script that extracts ELF BuildIds, downloads matching debug symbols from the Microsoft symbol server, and uses llvm-symbolizer to resolve native PC offsets into readable function names and source locations.

What is the best way to resolve native PC offsets in a Xamarin Android tombstone?

Resolving native PC offsets in a Xamarin Android tombstone requires matching debug symbols. By using the ELF BuildIds from the tombstone, you can download the correct symbols from the Microsoft symbol server and run llvm-symbolizer to map frames back to Mono runtime source files.

Can I use this to symbolicate native crashes from a .NET MAUI app?

Yes, Android tombstone symbolication works with .NET MAUI, Xamarin, and Mono crashes on Android. It detects frames belonging to .NET runtime libraries like libmonosgen-2.0.so and libcoreclr.so, resolving them using the Microsoft symbol server.

Do I need llvm-symbolizer to resolve .NET runtime native frames in an Android tombstone?

Yes, you need llvm-symbolizer to resolve .NET runtime native frames in an Android tombstone. The symbolication process uses it alongside the correct object files and downloaded debug symbols to produce a readable, triage-ready stack trace.

How does BuildId-based symbol resolution work for Mono Android crashes?

BuildId-based symbol resolution for Mono Android crashes extracts ELF BuildIds from the tombstone, queries the Microsoft symbol server to download matching debug symbols, and applies llvm-symbolizer to translate native PC offsets into source files and line numbers.

What are the limitations of automating crash triage with a ParseOnly mode?

A limitation of using ParseOnly mode for crash triage is that it only parses the tombstone without downloading debug symbols or running llvm-symbolizer, meaning you get a planning overview rather than a fully symbolicated backtrace with source locations.