Solaris system crash dumps

Enabling in Solaris 2.6 (disabled by default):
Uncomment last 6 lines in /etc/init.d/sysetup

Enabling in Solaris 7 and Solaris 8 (enabled by default):
/usr/sbin/dumpadm -y

With dumpadm, the dump device should be your system swap partition so that no file system information is overwritten by the dump. Crash dumps are usually about 35% of physical RAM, although they may be 80% to 90% of physical RAM in certain cases. The savecore directory should be large enough to accommodate these large crash dumps.

If you receive "initial dump header corrupt" messages in /var/adm/messages, check dumpadm's dump device and make sure it is a valid filesystem. In one instance, dumpadm was configured for the old swap partition, not the new swap partition under volume management.

To report a crash dump, you need a symbolic traceback for it to be useful to the person looking at it. Type the following:
cd /var/crash/`hostname`
echo '$c' | adb -k vmunix.0 vmcore.0

Sun's Solaris Crash Analysis Tool (Solaris CAT) is the best tool to analyze crash dumps. Sun's Initial System Crash Dump Analysis (iscda.sh) tool may also be used to examine crash dumps. Example iscda.sh usage:
./iscda.sh unix.0 vmcore.0 > iscda.out

You may also force system crashes in Solaris to test your crash dump configuration.

32-bit systems:
adb -wk
rootdir/W0
cd /

64-bit systems:
adb -wk
rootdir/Z0
cd /

Another method using adb:
adb -kw /dev/ksyms /dev/mem
rootdir/X

rootdir/W 0
$q
cd /

Another method using uadmin (performs a sync and returns to the "ok" prompt):
uadmin 2 0

Back to brandonhutchinson.com.
Last modified: 10/13/2003