Kernel Ramdump Analysis
Read the crash a device left in its own memory.
When a phone hard-crashes it dumps its RAM: gigabytes of frozen memory with no log files. Drop the ramdump and logcat.ai reconstructs the device's state, its reset reason, and even its own logs and screen, then names the root cause.
Watch it work on a crash
One dump, one question, from a device that wrote nothing to disk. The investigation rebuilds the whole live state from frozen memory: what was on screen, which apps were running, the last log lines, and the subsystem crash that stalled recovery and tripped the watchdog.
“Reconstruct the device's live state from this ramdump: what was on the screen, which apps and services were running, and what the last userspace logcat and kernel dmesg lines show.”
A modem-subsystem crash stalled recovery and tripped the watchdog, mid-unlock
Nothing survived on disk, so the whole live state was rebuilt from the RAM image. At the moment of the dump the Kestrel K9 was showing the lockscreen PIN bouncer at about 87 nits, and the user had just verified their PIN. The crash did not start on screen. The modem subsystem (MSS/q6v5) took a fatal firmware error: the last kernel dmesg line is remoteproc remoteproc1: fatal error received: modem, and the last userspace logcat line is the telephony stack seeing RADIO_UNAVAILABLE. The kernel entered subsystem-restart recovery, but it stalled. The crashed modem never acknowledged channel teardown, so the SSR worker blocked in glink holding subsys_list_lock, and 60+ threads that needed the modem piled up behind it until the watchdog bit. The recovered SSR-worker kernel stack pins the block precisely in the teardown wait. Every line of this came out of memory: the screen, the process list, the logcat and dmesg, the per-CPU state, and the stuck worker's stack were all reconstructed, not read from a log file.
The full reconstruction, on video
A real Deep Research run over a kernel ramdump. Device names neutralized.
Before it answers, it reads the frozen memory
Every dump is first reduced to a recovered identity and a set of forensic findings (reset reason, interconnect faults, per-CPU state), the deterministic floor that stands even with no kernel image.
Hardware watchdog reset — the kernel stopped petting the watchdog, read from the abort log in IMEM.
A kernel worker (kworker) blocked on a mutex — a soft-lockup, read from the per-CPU runqueues and task list.
The mutex is held by a driver stuck in its runtime-resume path — resolved from the loaded-module map.
The recovered framebuffer shows the UI frozen mid-refresh — a hang, not a kernel panic.
The reconstructed userspace log shows the foreground app blocked on a call that never returned.
Full memory was captured after the watchdog fired, so the evidence is complete and self-consistent.
Charts from a dump
Auto-generated from the recovered evidence: the reset signatures (a watchdog bite dominates) and the finding mix, every value traced back to the memory it came from.
Illustrative recovered output · synthetic dump
Why Ramdumps Are Hard to Read
A ramdump is frozen physical memory, not a log. The answer is in kernel structs, hardware register banks, and the reset syndrome, none of it readable without the exact kernel debug image.
No logs
The device crashed before it could write anything to disk. The evidence is only in the RAM it dumped.
Raw memory
Gigabytes of DDR and IMEM blobs. The process list, the reset reason, and the fault address are buried in kernel structures, not text.
Symbol dependence
Reading the object model needs the matching vmlinux; hand-tooling gdb against a multi-gigabyte dump takes hours and expert knowledge.
No faulting backtrace
Bus and TrustZone faults are caught after the access retired. There is often no stack pointing at the culprit.
The Real Cost of Reading a Ramdump by Hand
- 01Standing up gdb against a multi-gigabyte dump and the right kernel image.
- 02Hand-walking kernel structs to recover the process list and reset reason.
- 03Decoding the reset syndrome and the hardware error logs by hand.
- 04Reconstructing what the device was doing with no logs and no backtrace.
- 05Cross-referencing the crash class against upstream kernel fixes yourself.
What logcat.ai Does Differently
It reads the object model straight out of frozen memory: no hardcoded offsets, everything resolved from your kernel image.
Recovers the device's own logs & screen
Reconstructs the kernel dmesg and the full Android logcat from memory (decompressing logd's zstd chunks along the way) and carves the framebuffer to recover the screenshot that was on-screen when it crashed.
A forensic floor with no kernel image
Device identity, reset reason, bus faults, and the SoC's own hardware register capture come out of every dump with no vmlinux at all. Upload a matching kernel image and the deep object-model tables activate.
Zero hardcoded offsets
Every struct field, enum, and type size is resolved from your exact vmlinux's debug info, so extraction stays correct across kernel builds and Android versions: process list, per-CPU runqueue, kernel stacks, drivers, binder graph, per-process memory.
Ask the dump in plain language
A research agent drills the dump through a live kernel session (read the log, resolve an address to a driver, dump bytes) grounded in the deterministic evidence, and correlates the crash class against upstream fixes.
A dump is the whole machine, frozen
A ramdump isn't a log — it's the device's entire memory at the instant it died. If it was in RAM, it's recoverable: kernel and driver state, the logs the device never got to write, even the screen it was showing. The examples below are a sample of the breadth, not a limit.
Model, build, security patch, and kernel, from the property area and the kernel banner.
The abort / reset syndrome and watchdog state: why the device actually went down.
The full dmesg, decoded from the kernel's printk ring buffer in memory.
The complete userspace log, carved from logd's heap and zstd-decompressed.
The framebuffer that was on-screen at the crash, scanned out of raw memory.
What every core was running at the freeze, from each CPU's runqueue.
The backtrace of every task, walked from the frames saved in memory.
The module map, so a raw address resolves to the driver behind it.
The in-flight cross-process calls: who was waiting on whom when it hung.
Each process's memory map and footprint, from the kernel's own tables.
The SoC's own register capture: the values it latched at the crash.
Network sockets, thermal state, keystore, timers — if it was in memory, it's on the table.
You showed up with one of these
Three ways a ramdump lands on you, and what comes back.
A device that crashed with no logs
It froze or rebooted and there's nothing in logcat: just the RAM it dumped. The investigation above reconstructed the whole crash (reset reason, the stuck driver, the frozen screen, the blocked app) out of that frozen memory.
A reboot or hang with no backtrace
A silent reboot, a watchdog bite, a freeze with no panic and no stack. The analysis decodes the reset syndrome and the per-CPU state, and ties the crash to the driver and the code behind it.
A dump you need to see, not gdb
You don't want to hand-walk a multi-gigabyte dump in gdb. The dashboard reads the dump's structure and draws what matters: identity, reset signatures, per-CPU state, top memory, and the recovered screenshot.
Common questions
Frequently Asked Questions
Kernel ramdump analysis, answered.
Qualcomm kernel ramdumps: the directory of DDR / IMEM region blobs plus the collector manifests (load.cmm, dump_info.txt), typically shipped as a .7z. A ramdump is recognized by its contents, not its extension, so the archive format is flexible.
No. A forensic floor (identity, reset reason, bus faults, hardware register capture, screenshot) comes out of any dump with no kernel image. Uploading a matching vmlinux once activates the deep object-model tables (process list, stacks, drivers, logs) and symbolizes every future dump of that same build automatically.
Yes. The kernel dmesg is decoded from the printk ring buffer, the Android logcat is carved from logd's heap (decompressing its zstd chunks), and the on-screen framebuffer is scanned out of physical memory, all from a device that wrote nothing to disk. The recovered logs become first-class and searchable, each with its own dashboard.
Nothing is hardcoded per build. Every struct offset, enum, and type size is resolved from your exact vmlinux's debug information, so the same extraction works across kernel builds and Android versions.
Yes. A research agent drives a live kernel session over the dump (reading the log, resolving addresses to drivers, dumping memory) grounded in the deterministic evidence, and correlates the crash class against known upstream fixes.
Dumps are processed in your own tenant and never used to train shared models. Kernel images you upload are stored per-tenant and reused only for your dumps.
Bring us a dump nothing else can read.
Upload a Qualcomm kernel ramdump (the memory a crashed device left behind) and get its identity, reset reason, recovered logs and screen, and a cited root cause, without ever opening gdb.