Kernel ramdumps & References

Kernel ramdumps & References

logcat.ai performs forensic analysis on Qualcomm kernel ramdumps: the multi-gigabyte memory snapshots a device produces when the kernel crashes hard. Upload the dump archive and logcat.ai recovers what the device was doing at the moment it died: the reset reason, hardware fault registers, running tasks, loaded drivers, and, if you’ve uploaded a matching vmlinux, the kernel and userspace logs recovered from memory.

There are two levels of analysis. The second turns on when you upload a matching vmlinux to the References library (below).

A ramdump dashboard: kernel-memory forensics pulled straight from the dump: NoC register faults, UFS clock-gating state, and mass blocked-thread analysis.
A ramdump dashboard: kernel-memory forensics pulled straight from the dump: NoC register faults, UFS clock-gating state, and mass blocked-thread analysis.

What gets accepted

  • Qualcomm ramdump archives are the collector output: a directory of DDR/IMEM region blobs plus manifests (load.cmm, dump_info.txt). The collector usually ships them as a .7z, but any supported archive works (.tar.gz, .zip, and so on). Upload the archive as-is. The region set is recognized from its contents and analyzed as one dump.

A ramdump archive is treated as a bundle: the recovered logs inside it become their own sibling files (see below).

The two analysis tiers

Without symbols (always available)

Even with no symbols, logcat.ai recovers the hardware-level forensic signal that doesn’t need a symbol table:

  • Reset reason: why the device went down.
  • NoC (Network-on-Chip) faults: bus-level hardware fault captures.
  • DCC registers: the hardware register snapshot captured at crash time.
  • Secure-world event log: the trusted execution environment’s own event stream leading up to the reset. On a device where the kernel never panicked, this is often the only running account of what happened.
  • Co-processor failure records: when a co-processor such as the modem stops, its firmware records why. That record is recovered verbatim, with its registers and the task that was running. Read it as the co-processor’s account of what it was told, not as the cause: a co-processor often stops because something else already failed.

With symbols (upload a matching vmlinux)

Upload the vmlinux for the exact kernel build to the References library, and the analysis reads struct layouts from its DWARF debug info and walks the dump’s memory to recover:

  • Tasks and runqueues: what every process and CPU was doing.
  • Loaded modules: the driver list, named from kernel memory.
  • Per-process memory: the memory map of each process.
  • Mounted filesystems: every mounted volume, its type, and whether it was read-only at the time of capture. Android mounts its system volumes read-only by design, so this matters when a volume that should be writable isn’t.
  • Recovered logs: the kernel log (dmesg) and userspace logcat are reconstructed from memory and appear as their own files, each with a dashboard and full search, from the dump’s Logs tab.
  • Screenshot recovery: the on-screen framebuffer at crash time, when present.

Until a matching vmlinux is in the library, a dump is analyzed without symbols.

The References library (vmlinux & DBC)

References holds the symbols and definitions that turn opaque captures into named data. It’s scoped to your organization, under References in the console.

  • Kernel symbols (vmlinux): matched to dumps by kernel build, so a vmlinux uploaded once covers every later dump of that build. Because a vmlinux exceeds the normal upload cap, upload it through the References tab. It’s also picked up automatically if it ships inside a dump archive.
  • DBC files: the CAN signal database used to decode automotive candump traces. Register a DBC once and matching CAN traces are decoded against it automatically. See Preparing automotive logs.

Example questions to ask

Ask from the Research tab once the dump is analyzed. Reach for Quick Search when you already know what you’re after, Deep Research when you need the root cause.

Quick Search for fast, cited lookups:

  • “What was the reset reason?”
  • “What were the CPUs running when it crashed?”
  • “Were there any NoC or bus faults?”
  • “Which drivers were loaded?”
  • “Show me the last kernel log lines before the crash.”

Deep Research for multi-step root-cause investigations:

  • “Why did the kernel reset?”
  • “Trace the fault that triggered the watchdog.”
  • “What stalled the storage path in the seconds before the crash?”

See Quick Search and Deep Research for how the two modes differ.

Next