how_to_capture_a_vms_crash_dump
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
how_to_capture_a_vms_crash_dump [2018/09/07 19:47] – lricker | how_to_capture_a_vms_crash_dump [2018/09/10 21:40] (current) – lricker | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | (__Under Construction!__) | + | ===== How to Capture a VMS Crash Dump ===== |
- | + | ==== or: What should be done to preserve the System Dump File after VMS reboots? | |
- | ===== HOW TO CAPTURE A CRASH DUMP ===== | + | |
Sometimes a VMS problem manifests itself as a system crash. | Sometimes a VMS problem manifests itself as a system crash. | ||
Line 13: | Line 12: | ||
As a VMS sys-admin, you should know precisely how your VMS system(s) are configured to handle your SYSDUMP.DMP file upon reboot after a crash. | As a VMS sys-admin, you should know precisely how your VMS system(s) are configured to handle your SYSDUMP.DMP file upon reboot after a crash. | ||
+ | ==== Your Action Items ==== | ||
+ | |||
+ | Whether you configure VMS for “normal” on-system-disk dumps, dumps into the Page File, DOSD, or other more exotic configurations (don’t!), there’s one last configuration step that you must do to ensure that, after every VMS crash, you preserve this hard-won, valuable crash dump information for subsequent analysis. | ||
+ | |||
+ | Remember that each system crash overwrites the previous contents of the System Dump File, so ― especially if your system is crashing repetitively for some hard-ware-related reason ― it’s essential that, upon reboot, your system' | ||
+ | |||
+ | For example, let’s assume that CLASS8’s DSA2: (shadow-set) disk has “plenty of free space”, and that we can copy several versions of our System Dump File to it before we have to worry about clean-ups or purges. | ||
+ | |||
+ | $ CREATE /DIRECTORY / | ||
+ | |||
+ | Now this directory can become the catch-point for any subsequent crash-dump copy: | ||
+ | |||
+ | '' | ||
+ | '' | ||
+ | Copying: Headers... | ||
+ | Copying: PT space - 47 blocks... | ||
+ | Copying: S0/S1 space - 53922 blocks... | ||
+ | Copying: S2 space - 37568 blocks... | ||
+ | Copying: Page tables of key process " | ||
+ | Copying: Memory of key process " | ||
+ | Copying: Page tables of process " | ||
+ | Copying: Memory of process " | ||
+ | Copying: Page tables of process " | ||
+ | Copying: Memory of process " | ||
+ | %SDA-I-COLLECTING, | ||
+ | Scanning: Process " | ||
+ | Scanning: Process " | ||
+ | Scanning: Process " | ||
+ | Scanning: Page and swap files... | ||
+ | %SDA-W-NOCOLLECT, | ||
+ | Rewriting: Headers... | ||
+ | '' | ||
+ | |||
+ | With this in mind, there are several points to consider regarding VMS system startup crash-dump/ | ||
+ | |||
+ | **On Alpha and I64 systems**: SDA is invoked by default during startup, and a CLUE list file is created as generated by a set sequence of commands; this CLUE list file contains only an overview of the crash and might not provide enough information to determine the cause of the crash. | ||
+ | |||
+ | Always copy the system dump file to its alternative destination directory/ | ||
+ | |||
+ | * Although you could use the DCL command COPY to copy the dump file, don’t. SDA’s internal COPY command is preferable because it copies only the blocks occupied by the dump and then marks the Dump File as copied. | ||
+ | * The SDA COPY command is also preferable when the dump was written into the primary Page File, SYS$SYSTEM: | ||
+ | * Because a System Dump File can contain privileged and/or private information, | ||
+ | * System Dump Files have the NOBACKUP attribute, so the BACKUP utility does not copy them unless you use the qualifier / | ||
+ | |||
+ | The recommended method for SDA startup-the-system processing on Integrity and AlphaServer systems is: | ||
+ | |||
+ | * Create a /SYSTEM / | ||
+ | |||
+ | $ DEFINE /SYSTEM /EXEC CLUE$SITE_PROC SYS$STARTUP: | ||
+ | |||
+ | * Here’s an example of the contents of this site-specific command file SYS$STARTUP: | ||
+ | |||
+ | ! SAVEDUMP.SDA -- | ||
+ | ! SDA command file, executed as part of the system reboot. | ||
+ | ! Used to save the dump file after a system bugcheck, and | ||
+ | ! to execute any additional SDA commands. | ||
+ | ! | ||
+ | READ /EXEC ! Read in the executive images' | ||
+ | SHOW STACK ! Display the stack | ||
+ | COPY /COLLECT DSA2: | ||
+ | ! | ||
+ | |||
+ | * Of course, you must replace DSA2: | ||
+ | |||
+ | * You should also include commands, perhaps in SYLOGICALS.COM, | ||
+ | |||
+ | $ SET FILE /NOBACKUP DSA2: | ||
+ | $ PURGE /KEEP=3 DSA2: | ||
+ | |||
+ | * These commands will be executed well after VMS executes the SDA commands in SAVEDUMP.SDA (above) following any actual system crash, and it won’t matter much if these are re-executed on normal reboots as well. | ||
+ | |||
+ | **On VAX/VMS systems**: SDA crash-dump copy processing is (was) likely embedded in the SYS$STARTUP: | ||
+ | |||
+ | $ ANALYZE/ | ||
+ | COPY DSA2: | ||
+ | EXIT | ||
+ | $ SET FILE /NOBACKUP DSA2: | ||
+ | $ PURGE /KEEP=2 DSA2: | ||
+ | |||
+ | Of course, you’re system will have a different disk device, directory and filename for what’s shown as DSA2: | ||
+ | |||
+ | Note that, on VAX/VMS, these commands simply appear (are edited) in-line in the SYSSTARTUP_VMS.COM command procedure, and are executed when encountered. |
how_to_capture_a_vms_crash_dump.1536349651.txt.gz · Last modified: 2018/09/07 19:47 by lricker