/sys$common/syshlp/DBG$HELP.HLB  —  DEBUG  ANALYZE

1    /CRASH_DUMP 

    Opens a system dump for analysis by the System Dump Debugger
    (kept debugger only).

    Format

      ANALYZE/CRASH_DUMP

1.1  –  Description 

    For OpenVMS Integrity servers and Alpha systems, invokes the
    System Dump Debugger (SDD) to analyze a system dump.

    SDD is similar in concept to the System Code Debugger (SCD).
    While SCD allows connection to a running system, with control of
    the system's execution and the examination and modification of
    variables, SDD allows analysis of memory as recorded in a system
    dump.

    Use of SDD usually involves two systems, although all of the
    required environment can be set up on a single system. The
    description that follows assumes that two systems are being used:

    o  The build system, where the image that causes the system crash
       has been built

    o  The test system, where the image is executed and the system
       crash occurs

    In common with SCD, the OpenVMS debugger user interface allows
    you to specify variable names, routine names, and so on,
    precisely as they appear in your source code. Also, SDD can
    display the source code where the software was executing at the
    time of the system crash.

    SDD recognizes the syntax, data typing, operators, expressions,
    scoping rules, and other constructs of a given language. If your
    code or driver is written in more than one language, you can
    change the debugging context from one language to another during
    a debugging session.

    To use SDD you must do the following:

    o  Build the system image or device driver that is causing the
       system crash.

    o  Boot a system, including the system image or device driver,
       and perform the necessary steps to cause the system crash.

    o  Reboot the system and save the dump file.

    o  Invoke SDD, which is integrated with the OpenVMS debugger.

    For more information about using the SDD, including a sample SDD
    session, see the VSI OpenVMS System Analysis Tools Manual.

    Related commands:

       ANALYZE/PROCESS_DUMP
       CONNECT %NODE
       SDA

1.2  –  Example 

  DBG> ANALYZE/CRASH_DUMP

  DBG>

      Invokes SDD from within the kept debugger.

2    /PROCESS_DUMP 

    Opens a process dump for analysis with the System Code Debugger
    (kept debugger only)

    Format

      ANALYZE/PROCESS_DUMP  dumpfile

2.1  –  Parameters 

 dumpfile

    The name of the process dump file to be analyzed. The file type
    must be .DMP.

2.2  –  Qualifiers

2.2.1    /IMAGE_PATH 

       /IMAGE_PATH=directory-spec

    Specifies the search path for the debugger to find the files that
    contains the debugger symbol tables (DSTs). The files must be of
    type .DSF or .EXE, with the same name as the image names in the
    dumpfile. For example, if image name foo.exe is in the dump file,
    then the debugger searches for foo.dsf or foo.exe.

2.3  –  Description 

    (Kept debugger only.) Opens a process dump for analysis with
    the System Code Debugger (SCD). The qualifier /PROCESS_DUMP is
    required and distinguishes this command from the one that invokes
    the System Dump Debugger (SDD), ANALYZE/CRASH_DUMP.

    The qualifier /IMAGE_PATH=directory-spec is optional, and
    specifies the search path the debugger is to use to find the
    debugger symbol table (DST) files. 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 DSTs.

    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 name.

    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 next
    searches directory SYS$SHARE and then directory SYS$MESSAGE. If
    the debugger fails to find a DST file for the image, symbolic
    information available to the debugger is limited to global and
    universal symbol names.

    The debugger checks for link date-time mismatches between the
    dump file image and the DST file and issues a warning if one is
    discovered.

    The parameter dumpfile is the name of the process dump file to be
    analyzed. Note that the process dump file type must be .DMP and
    the DST file type must be either .DSF or .EXE.

    For more information about using SCD, see the VSI OpenVMS System
    Analysis Tools Manual.

    Related commands:

       ANALYZE/CRASH_DUMP
       CONNECT %NODE
       SDA

2.4  –  Example 

  DBG> ANALYZE/PROCESS/IMAGE_DUMP=my_disk$:[my_dir]
  my_disk$:[my_dir]wecrash.dmp
  %SYSTEM-F-IMGDMP, dynamic image dump signal at PC=001C0FA0B280099C,
   PS=001C003C
  break on unhandled exception preceding WECRASH\
  th_run
  \%LINE 26412 in THREAD 8
   26412:         if (verify) {
  DBG> SET RADIX HEXADECIMAL; EXAMINE PC
  WECRASH\th_run\%PC:     0000000000030244
  DBG>
Close Help