While mdb can be used to interact with the live kernel or probe into core dumps in complex and intimidating ways, it's also not very hard to get some basic and very useful information from a core dump that will help you determine why the system crashed.
You can start mdb with the command "mdb -k" if you want to look into the live kernel. Use control-D to exit. For peering into core dumps, you would use a command like "mdb unix.0 vmcore.0" (adjust the dump numbers to match your core files).
The command for extracting the panic message from a core dump (you should also be able to find this in your messages files) is ::status as shown in the example shown here:
> ::status debugging crash dump vmcore.0 (64-bit) from boson operating system: 5.10 Generic_125100-05 (sun4u) panic message: forced crash dump initiated at user request dump content: kernel pages only
In this case, we have a core dump that might appear to have been initiated by a normal user typing "panic" on the command line. Unix systems, as we know, don't lend themselves to going down the tubes so easily. Instead, this crash was caused by some user level process that transgressed is some way the proper operating system etiquette. There are numerous reasons why systems panic, but they generally indicate that no safe alternative to crashing was available due to some very serious fault.
The command for displaying a traceback (::stack), displaying the process causing the crash and its predecessors, will often help to answer the key question, "Where did this crash come from?". Here's an example:
> ::stack vpanic(11f2d48, 1, 182c800, 182c800, 0, 182a000) kadmin+0x4a4(b4, 1, 0, 11f2c00, 5, 1) ntwdt_enforce_timeout+0x3c(60002d90ac0, 2a10058dcc0, 7bbabc00, 7bbabc00, 1910c00, 0) ntwdt_cyclic_softint+0xd0(60002dc72e8, 7bbabc00, 60002d90ac0, 0, 704f5c00, 7bbab4e4) intr_thread+0x170(0, b, 0, ffffffffffffffff, 300001ccaf8, 18)