Kernel dumps & References

logcat.ai performs forensic analysis on kernel crash dumps: the memory image a machine writes when its kernel goes down hard. Two shapes are accepted and both land on the same analysis:

  • Linux kernel core dumps (vmcore), x86-64 or ARM64. The core a crashed Linux machine writes: a server, a VM, or an embedded board running a mainline or distribution kernel.
  • Qualcomm device ramdumps: the multi-gigabyte collector output from a phone, tablet, or automotive head unit.

Upload the dump and logcat.ai recovers what the machine was doing at the moment it died. There are two levels of analysis. The second turns on when you upload a matching kernel debug image to the References library (below).

A device ramdump dashboard: kernel-memory forensics pulled straight from the dump: NoC register faults, UFS clock-gating state, and mass blocked-thread analysis.
A device 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

  • Linux core dumps (vmcore). Upload the file exactly as your collector saved it, plain or zlib-compressed. A dump compressed with LZO, Snappy or Zstandard is refused with a message saying so; recapture with zlib compression (makedumpfile -c). The first tier of analysis needs no debug image, because the dump describes its own layout.
  • Qualcomm ramdump archives, the collector output: a directory of DDR/IMEM region blobs plus manifests (load.cmm, dump_info.txt), usually shipped as a .7z. Any supported archive works. The region set is recognized from its contents and analyzed as one dump.

A crash capture is treated as a container. The dump and anything recovered from it become files inside it, each analyzed on its own.

Either shape needs the kernel crash dump analysis capability on your account. See Why was I limited?.

Capturing from outside the machine

A dump taken from outside the machine (a hypervisor or cloud “dump this VM” action) carries less to work from than one the machine’s own crash kernel wrote. On x86-64 we still recover the kernel log from it; on ARM64 that shape needs the matching debug image. If you can choose, capture in-guest.

The two analysis tiers

Without symbols (always available)

Even with no debug image on file, logcat.ai recovers the forensic signal the dump carries about itself.

From a Linux core dump:

  • The recovered kernel log: the ring buffer as it stood at the crash. It also becomes a log of its own inside the capture, so you can read, search, and analyze it like any other log.
  • Machine identity: the kernel release and the boot command line the machine was running.
  • The fault the kernel reported: the panic, oops, or watchdog signature it printed on its way down, classified.
  • Per-CPU state: where each processor was when it went down, from the registers saved in the dump. A zeroed register set means that CPU never answered the crash, often the one that caused it, and is reported as such.

From a Qualcomm ramdump, the hardware-level signal a device dump carries instead:

  • 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 running task. It is the co-processor’s account of what it was told, not necessarily the cause.

Whichever you upload, the analysis says what it could and couldn’t read: “the kernel had nothing there” and “we couldn’t reach it” are reported as different answers.

With symbols (upload a matching debug image)

Upload the debug image 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:

  • The crashing task’s backtrace: what each processor was running at the moment of capture, innermost frame first, with a line saying whether it was walked (a call sequence) or scanned (addresses found on the stack, unordered). Core dumps carry the saved registers this needs; a device ramdump does not, and says so.
  • Tasks waiting in uninterruptible sleep: tasks blocked on something they couldn’t be woken out of, each with the call chain showing what it was waiting in. Kernel threads parked that way by design are left out.
  • 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.
  • Stalled waiting: how much of the preceding ten seconds, minute and five minutes tasks spent stalled on CPU, memory or storage. These are the only figures that describe the period before the capture, so a rising trend means the machine was getting worse.
  • Memory at capture: process memory, page cache, shared, and free, as shares of the total.
  • Mounted filesystems: every mounted volume, its type, and whether it was read-only. 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 reconstructed from memory, and on an Android device the userspace logcat with it. Each appears as its own file inside the capture, with a dashboard and full search.
  • Screenshot recovery: on a device dump, the on-screen framebuffer at crash time, when present.

A production core is often stripped of the memory some of these need; the analysis says so rather than reporting an empty result. Until a matching debug image is in the library, a dump is analyzed on the first tier. Upload one later and re-run the analysis to pick up the second.

The References library (kernel symbols, modules, DBC, message databases & firmware images)

References holds the symbols and definitions that turn opaque captures into named data. It’s scoped to your organization, under References in the console. Add any of the kinds below with Add reference file; every file on record is listed in one table with how many times an analysis has used it.

  • Kernel debug images: matched to dumps and to crashes in kernel logs by build ID, so one upload covers every later dump of that exact build, Qualcomm ramdump or Linux core dump alike. A distribution ships many builds under one version, so a different build of the same version is not used, and the analysis says so. Either form works: a full vmlinux, or the separate debug file your distribution ships (often vmlinux-<version> or .debug, from a -dbg or -debuginfo package). These exceed the normal upload cap, so upload them through the References tab, which needs the kernel crash dump analysis capability on your account. One shipped inside a dump archive is picked up automatically. Both paths take an image up to the per-image limit.
  • Kernel modules: the .ko debug object for a loadable driver, matched to a crash by build ID, or by module name and kernel version. Upload one when a crash names a driver that is not built into the kernel, so the crash’s frames in that driver resolve to a function and a source line too. For a kernel log, the resolved chain is drawn on the capture’s dashboard and used by its investigations; a capture analyzed before the upload can be re-run deeper from References, in place, with nothing to re-upload. Upload through the References tab, one file per module.
  • DBC files: the CAN signal database for automotive CAN traces. See Preparing automotive logs.
  • Baseband message databases: the .qsr4 file built with a modem’s firmware, which restores compressed modem narration to text. See Preparing telecom logs.
  • Modem firmware images: the modem’s .elf from the same build, which names the firmware function behind trace messages whose text the vendor did not ship. See Preparing telecom 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 fault did the kernel report?”
  • “What were the CPUs running when it crashed?”
  • “Show me the last kernel log lines before the crash.”
  • “Which modules were loaded?”
  • “What was the reset reason?” (device ramdumps)
  • “Were there any NoC or bus faults?” (device ramdumps)

Deep Research for multi-step root-cause investigations:

  • “Why did the kernel go down?”
  • “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

  • Multi-file bundles: how a dump archive composes with the logs inside it.
  • Analysis output & dashboards: the dump dashboard, which opens with the kernel’s own last words and then shows identity, where the machine was at capture, each processor’s state, blocked tasks, stall pressure, memory, recovered logs, and on a device dump the reset reason, hardware faults, and recovered screenshot.
  • Supported file types: the full accepted/rejected list.
  • Source-grounded findings: how kernel log findings get cited back to kernel source, and how to check a citation belongs to your machine.