崩溃后，故障转储存储在 dumpadm 输出中定义为“Savecore 目录”的目录下。
默认为 /var/crash/uname -n。
从 Solaris 10 Update 9 开始，故障转储存储在名为 vmdump.X 的单个文件中，其中 X 是 /var/crash/uname -n/bounds 文件中定义的连续数字。
在 Solaris 10 update 9 之前，会创建两个文件， unix.X 和 vmcore.X 。

注意：在系统崩溃导致重新启动后，会自动执行 savecore 命令从转储设备中提取故障转储并将其保存为文件。
在尝试对故障转储执行任何操作之前，请确保文件不再增长或者没有 savecore 进程正在运行。
如果系统至少运行 Solaris 10 update 9，则需要提取实际的故障转储（以获取 unix.X 和 vmcore.X 文件）以与其交互。
这可以通过以下命令完成：

# savecore -vf vmdump.0
savecore: System dump time: Sat Nov 27 01:43:17 2016
savecore: saving system crash dump in /var/crash/{unix,vmcore}.0
Constructing namelist /var/crash/unix.0
Constructing corefile /var/crash/vmcore.0
 0:08 100% done: 67870 of 67870 pages saved
18796 (27%) zero pages were not written
0:08 dump decompress is done

为了创建服务请求以诊断系统崩溃或者系统挂起的原因，如果系统运行的是 Solaris 10 Update 9 或者更高版本，请仅上传 vmdump.X 文件，对于以前版本的 Solaris，请上传 unix。
X 和 vmcore.X 文件。

我们可以使用 mdb 对故障转储执行快速验证。
下面显示的命令是打印崩溃转储的标题和导致恐慌的堆栈跟踪。
如果这些命令提供输出并且 /var/adm/messages 文件和/或者控制台日志上没有报告错误，则很有可能成功创建故障转储。

# echo "::status" | mdb -k unix.0 vmcore.0
debugging crash dump vmcore.0 (64-bit) from hostA.oracle.com
operating system: 5.11 11.0 (sun4v)
image uuid: 6d5e1bb1-16f1-4de9-a12f-ac96c3826144
panic message: forced crash dump initiated at user request
dump content: kernel pages only

# echo "*panic_thread::findstack" | mdb -k unix.0 vmcore.0
stack pointer for thread 30014cb98a0: 2a1020e3081
  000002a1020e3131 kadmin+0x5a0()
  000002a1020e3201 uadmin+0x1c0()
  000002a1020e32d1 syscall_trap32+0xcc()

Oracle Solaris 故障分析工具 (SCAT) 也可用于验证和分析故障转储，打开故障转储并使用“analyze”命令应该足以确认故障转储已正确创建。