vmcore是内核崩溃瞬间的内存快照，必须用crash工具配合匹配的vmlinux调试符号分析；先验证kdump服务状态、crashkernel预留及vmcore存在性，再执行log、bt-a、ps定位根因。
内核崩溃转储文件（vmcore）是系统“死亡快照”，不是日志，不能靠 grep 或 journalctl 查。真正有效的分析必须依赖 crash 工具 + 匹配的 vmlinux 调试符号，缺一不可。
确认kdump是否已启用并成功捕获
先别急着分析，先验证数据是否可靠：
- 检查 kdump 服务状态：
systemctl status kdump，确保显示 active (running) - 查看最近一次崩溃是否生成了 vmcore：
ls -l /var/crash/，目录下应有时间戳子目录，内含vmcore和vmcore-dmesg.txt - 核对 crashkernel 内存预留是否生效：
dmesg | grep -i crashkernel，输出应类似Reserving 256MB of memory at 16MB for crashkernel
准备正确的调试符号（vmlinux）
vmlinux 是带完整调试信息的内核映像，不是 /boot/vmlinuz-xxx。没有它，crash 只能显示地址，无法还原函数名和堆栈。
- RHEL/CentOS：安装对应内核版本的
kernel-debuginfo和kernel-debuginfo-common包，例如：yum install kernel-debuginfo-$(uname -r) kernel-debuginfo-common-$(uname -r) - Debian/Ubuntu：安装
linux-image-$(uname -r)-dbg，调试符号通常位于/usr/lib/debug/boot/vmlinux-$(uname -r) - 验证路径是否存在：
ls -l /usr/lib/debug/lib/modules/$(uname -r)/vmlinux或/usr/lib/debug/boot/vmlinux-$(uname -r)
用 crash 加载并快速定位根因
启动分析后，不建议直接翻页看长堆栈。按顺序执行三个关键命令：
-
log—— 查看崩溃前最后几秒的内核日志，常含 OOM、硬件报错、驱动加载失败等线索 -
bt -a—— 显示所有 CPU 的回溯堆栈，重点看标记为 PANIC 或 BUG 的线程，第一帧函数名就是崩溃入口点 -
ps | grep -E "(D|UN)|state"—— 找出处于不可中断睡眠（D 状态）或异常状态的进程，结合bt <pid></pid>查其卡在哪
结合常见场景做判断
不同崩溃现象对应不同排查方向：
- 如果
bt显示do_page_fault或bad_area_nosemaphore→ 多为内存损坏、坏 RAM 或驱动越界访问 - 如果堆栈中反复出现
mutex_lock、rwsem_down_read且多个 CPU 卡在相同锁 → 典型死锁，用lock命令进一步查 - 如果
log里有Out of memory: Kill process后跟Kernel panic→ OOM killer 触发后内核无法恢复，需查内存泄漏或配置 - 如果
mod列出第三方模块（如 nvidia、zfs、自研驱动）且崩溃点在其函数内 → 优先怀疑该模块兼容性或 bug
