Invokes the OpenVMS Debugger to analyze a process dump file that
was created when an image failed during execution. (Use the /DUMP
qualifier with the RUN or the SET PROCESS command to generate a
dump file.)
Note that on Alpha systems, you can also force a process to dump by
using the DUMP/PROCESS command.
The ANALYZE/PROCESS_DUMP command can display a process dump file
for either an Alpha or a VAX image. For a complete description
of the debugger, including information about the DEBUG command,
refer to the OpenVMS Debugger Manual.
Requires read (R) access to the dump file.
Format
ANALYZE/PROCESS_DUMP dump-file
dump-file
Specifies the dump file to be analyzed with the debugger.
1 – Qualifiers
1.1 /FULL
On VAX and Alpha systems, displays all known information about the
failing process.
1.2 /IMAGE
/IMAGE=image-name
/NOIMAGE
On VAX systems, specifies the image to be activated to set up the
process context for the analysis. If you use the /NOIMAGE qualifier,
the DELTA debugger will be used for the analysis.
By default, symbols are taken from the image with the same name as
the image that was running at the time of the dump.
1.3 /IMAGE_PATH
/IMAGE_PATH[=directory-spec] dump-file
/NOIMAGE_PATH
On Alpha systems, specifies the search path the debugger is to use
to find the debugger symbol table (DST) file. As in prior debuggers,
the debugger builds an image list from the saved process image list.
When you set an image (the main image is automatically set), the
debugger attempts to open that image in order to find the DST file.
If you include the /IMAGE_PATH=directory-spec qualifier, the
debugger searches for the DST file in the specified directory.
The debugger first tries to translate directory-spec as the logical
name of a directory search list. If that fails, the debugger
interprets directory-spec as a directory specification, and searches
that directory for matching .DSF or .EXE files. A .DSF file takes
precedence over an .EXE file. The name of the .DSF or .EXE file
must match the image.
If you do not include the /IMAGE_PATH=directory-spec qualifier,
the debugger looks for the DST file first in the directory that
contains the dump file. If that fails, the debugger searches
directory SYS$SHARE and then directory SYS$MESSAGE. If the debugger
fails to find a DST file for an image, the symbolic information
available to the debugger is limited to global and universal symbol
names.
Version 7.3 and later debuggers check for dumpfile image specification
and DST file link date-time mismatches and issue a warning if one is
discovered.
The dump-file parameter is the name of the process dump file to
be analyzed. Note that the process dump file file type must be .DMP
and the DST file type must be either .DSF or .EXE.
Restrictions
You cannot use a logical to redirect the search for an image
and use the /IMAGE_PATH qualifier at the same time. If you
use the /IMAGE_PATH qualifier, then all images that are not
in their original locations must be found through that path.
Individual image logicals (for example, the "SH" in "DEFINE
SH SYS$LOGIN:SH.EXE") are not processed.
Additionally, you cannot input a directory search path
directly to the /IMAGE_PATH qualifier, as it does not
process a directory list separated by commas; however, you
can specify a logical that translates into a directory
search path.
1.4 /INTERACTIVE
/INTERACTIVE
/NOINTERACTIVE (default)
On VAX systems, causes the display of information to pause when your
terminal screen is filled. Press Return to display additional
information. By default, the display is continuous.
1.5 /MISCELLANEOUS
On VAX systems, displays process information and registers at the
time of the dump. Refer to the $GETJPI system service for further
explanation of the process information displayed.
1.6 /RELOCATION
On VAX systems, displays the addresses to which data structures saved
in the dump are mapped in P0 space. (Examples of such data structures
are the stacks.) The data structures in the dump must be mapped into P0
space so that the debugger can use those data structures in P1 space.
2 – Examples
1.$ ANALYZE/PROCESS/FULL ZIPLIST
R0 = 00018292 R1 = 8013DE20 R2 = 7FFE6A40 R3 = 7FFE6A98
R4 = 8013DE20 R5 = 00000000 R6 = 7FFE7B9A R7 = 0000F000
R8 = 00000000 R9 = 00000000 R10 = 00000000 R11 = 00000000
SP = 7FFAEF44 AP = 7FFAEF48 FP = 7FFAEF84
FREE_P0_VA 00001600 FREE_P1_VA 7FFAC600
Active ASTs 00 Enabled ASTs 0F
Current Privileges FFFFFF80 1010C100
Event Flags 00000000 E0000000
Buffered I/O count/limit 6/6
Direct I/O count/limit 6/6
File count/limit 27/30
Process count/limit 0/0
Timer queue count/limit 10/10
AST count/limit 6/6
Enqueue count/limit 30/30
Buffered I/O total 7 Direct I/O total 18
Link Date 27-DEC-2000 15:02:00.48 Patch Date 17-NOV-2000 00:01:53
ECO Level 0030008C 00540040 00000000 34303230
Kernel stack 00000000 pages at 00000000 moved to 00000000
Exec stack 00000000 pages at 00000000 moved to 00000000
Vector page 00000001 page at 7FFEFE00 moved to 00001600
PIO (RMS) area 00000005 pages at 7FFE1200 moved to 00001800
Image activator context 00000001 page at 7FFE3400 moved to 00002200
User writable context 0000000A pages at 7FFE1C00 moved to 00002400
Creating a subprocess
VAX DEBUG Version 5.4
DBG>
This example shows the output of the ANALYZE/PROCESS command when used
with the /FULL qualifier on a VAX system. The file specified, ZIPLIST,
contains the dump of a process that encountered a fatal error. The
DBG> prompt indicates that the debugger is ready to accept commands.