| Previous | Contents | Index |
This chapter describes the functions and the system management of SDA.
It describes initialization, operation, and procedures in analyzing a
system dump and analyzing a running system. This chapter also describes
the SDA context, the command format, and the way both to investigate
system failures and induce system failures.
2.1 Capabilities of SDA
When a system failure occurs, the operating system copies the contents of memory to a system dump file or the primary page file, recording the hardware context of each processor in the system as well. The System Dump Analyzer (SDA) is a utility that allows you to interpret the contents of this file, examine the status of each processor at the time of the system failure, and investigate the probable causes of the failure.
You can invoke SDA to analyze a system dump, using the DCL command ANALYZE/CRASH_DUMP. You can then use SDA commands to perform the following operations:
Although SDA provides a great deal of information, it does not automatically analyze all the control blocks and data contained in memory. For this reason, in the event of system failure, it is extremely important that you save not only the output provided by SDA commands, but also a copy of the system dump file written at the time of the failure.
You can also invoke SDA to analyze a running system, using the DCL command ANALYZE/SYSTEM. Most SDA commands generate useful output when entered on a running system.
Although analyzing a running system may be instructive, you should undertake such an operation with caution. System context, process context, and a processor's hardware context can change during any given display. In a multiprocessing environment, it is very possible that, during analysis, a process running SDA could be rescheduled to a different processor frequently. Therefore, avoid examining the hardware context of processors in a running system. |
The system manager must ensure that the system writes a dump file
whenever the system fails. The manager must also see that the dump file
is large enough to contain all the information to be saved, and that
the dump file is saved for analysis. The following sections describe
these tasks.
2.2.1 Writing System Dumps
The operating system attempts to write information into the system dump file only if the system parameter DUMPBUG is set. (The DUMPBUG parameter is set by default. To examine and change its value, consult the HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.) If DUMPBUG is set and the operating system fails, the system manager has the following choices for writing system dumps:
There are two types of dump files---a full memory dump (also known as a physical dump), and a dump of selected virtual addresses (also known as a selective dump). Both full and selective dumps may be produced in either compressed or uncompressed form. Compressed dumps save disk space and time taken to write the dump at the expense of a slight increase in time to access the dump with SDA. The SDA commands COPY/COMPRESS and COPY/DECOMPRESS can be used to convert an existing dump.
A dump can be written to the system disk, or to another disk set aside for dumps. When using a disk other than a system disk, the disk name is set in the console environment variable DUMP_DEV. This disk is also known as the "dump off system disk" (DOSD) disk.
When writing a system dump, information about the crash is displayed at the system console. This can be either minimal output (for example, bug check code, process name, and image name), or verbose output (for example, executive layout, stack and register contents).
In an OpenVMS Galaxy system, shared memory is dumped by default. It is sometimes necessary to disable the dumping of shared memory. For more information about shared memory, see HP OpenVMS Alpha Partitioning and Galaxy Guide.
DUMPSTYLE, which specifies the method of writing system dumps, is a 32-bit mask. Table 2-1 shows how the bits are defined. Each bit can be set independently. The value of the SYSGEN parameter is the sum of the values of the bits that have been set. Remaining or undefined values are reserved to HP.
| Bit | Value | Description |
|---|---|---|
| 0 | 1 |
0= Full dump. The entire contents of physical memory will be written to
the dump file.
1= Selective dump. The contents of memory will be written to the dump file selectively to maximize the usefulness of the dump file while conserving disk space. (Only pages that are in use are written). |
| 1 | 2 |
0= Minimal console output. This consists of the bugcheck code; the
identity of the CPU, process, and image where the crash occurred; the
system date and time; plus a series of dots indicating progress writing
the dump.
1= Full console output. This includes the minimal output previously described plus stack and register contents, system layout, and additional progress information such as the names of processes as they are dumped. |
| 2 | 4 |
0= Dump to system disk. The dump will be written to
SYS$SYSDEVICE:[SYSn.SYSEXE]SYSDUMP.DMP, or in its absence,
SYS$SYSDEVICE:[SYSn.SYSEXE]PAGEFILE.SYS.
1= Dump to alternate disk. The dump will be written to dump_dev:[SYSn.SYSEXE]SYSDUMP.DMP, where dump_dev is the value of the console environment variable DUMP_DEV. |
| 3 | 8 |
0= Uncompressed dump. Pages are written directly to the dump file.
1= Compressed dump. Each page is compressed before it is written, providing a saving in space and in the time taken to write the dump, at the expense of a slight increase in time taken to access the dump. |
| 4 | 16 |
0= Dump shared memory.
1= Do not dump shared memory. |
| 5 | 32 |
0= Write all processes and global pages in a selective dump.
1= Write only key processes and global pages in a selective dump. This bit is ignored when writing a full dump (bit 0 = 0). This bit should be set only if the priority processes have been correctly set up, as described in HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems. |
| 6--31 | Reserved to HP. |
The default setting for DUMPSTYLE is 9 (a compressed selective dump,
including shared memory, written to the system disk). Unless a value
for DUMPSTYLE is specified in MODPARAMS.DAT, AUTOGEN.COM will set
DUMPSTYLE either to 1 (an uncompressed selective dump, including shared
memory, written to the system disk) if there is less than 128 megabytes
of memory on the system, or to 9 (a compressed selective dump,
including shared memory, written to the system disk).
2.2.1.2 Comparison of Full and Selective Dumps
A full dump requires that all physical memory be written to the dump file. This ensures the presence of all the page table pages required for SDA to emulate translation of system virtual addresses. Any even-numbered value in the DUMPSTYLE system parameter generates a full dump.
In certain system configurations, it may be impossible to preserve the entire contents of memory in a disk file. For instance, a large memory system or a system with small disk capacity may not be able to supply enough disk space for a full memory dump. If the system dump file cannot accommodate all of memory, information essential to determining the cause of the system failure may be lost.
To preserve those portions of memory that contain information most useful in determining the causes of system failures, a system manager sets the value of the DUMPSTYLE system parameter to specify a dump of selected virtual address spaces. In a selective dump, related pages of virtual address space are written to the dump file as units called logical memory blocks (LMBs). For example, one LMB consists of the page tables for system space; another is the address space of a particular process. Those LMBs most likely to be useful in crash dump analysis are written first. Any odd-numbered value in the DUMPSTYLE system parameter generates a selective dump.
Table 2-2 compares full and selective style dumps.
| Item | Full | Selective |
|---|---|---|
| Available Information | Complete contents of physical memory in use, stored in order of increasing physical address. | System page table, global page table, system space memory, and process and control regions (plus global pages) for all saved processes. |
| Unavailable Information | Contents of paged-out memory at the time of the system failure. | Contents of paged-out memory at the time of the system failure, process and control regions of unsaved processes, and memory not mapped by a page table. |
| SDA Command Limitations | None. | The following commands are not useful for unsaved processes: SHOW PROCESS/CHANNELS, SHOW PROCESS/IMAGE, SHOW PROCESS/RMS, SHOW STACK, and SHOW SUMMARY/IMAGE. |
You can adjust the size of the system page file and dump file using AUTOGEN (the recommended method) or by using SYSGEN.
AUTOGEN automatically calculates the appropriate sizes for page and dump files. AUTOGEN invokes the System Generation utility (SYSGEN) to create or change the files. However, you can control sizes calculated by AUTOGEN by defining symbols in the MODPARAMS.DAT file. The file sizes specified in MODPARAMS.DAT are copied into the PARAMS.DAT file during AUTOGEN's GETDATA phase. AUTOGEN then makes appropriate adjustments in its calculations.
Although HP recommends using AUTOGEN to create and modify page and dump file sizes, you can use SYSGEN to directly create and change the sizes of those files.
The sections that follow discuss how you can calculate the size of a dump file.
See the HP OpenVMS System Manager's Manual for detailed information about using AUTOGEN and
SYSGEN to create and modify page and dump file sizes.
2.2.1.4 Writing to the System Dump File
OpenVMS writes the contents of the error-log buffers, processor registers, and memory into the system dump file, overwriting its previous contents. If the system dump file is too small, OpenVMS cannot copy all memory to the file when a system failure occurs.
SYS$SYSTEM:SYSDUMP.DMP (SYS$SPECIFIC:[SYSEXE]SYSDUMP.DMP) is created during installation. To successfully store a crash dump, SYS$SYSTEM:SYSDUMP.DMP must be enlarged to hold all of memory (full dump) or all of system space and the key processes (selective dump).
To calculate the correct size for an uncompressed full dump to SYS$SYSTEM:SYSDUMP.DMP, use the following formula:
size-in-blocks(SYS$SYSTEM:SYSDUMP.DMP)
= size-in-pages(physical-memory) * blocks-per-page
+ number-of-error-log-buffers * blocks-per-buffer
+ 10
|
Use the DCL command SHOW MEMORY to determine the total size of physical
memory on your system. There is a variable number of error log buffers
in any given system, depending on the setting of the ERRORLOGBUFF_S2
system parameter. The size of each buffer depends on the setting of the
ERLBUFFERPAG_S2 parameter. (See the HP OpenVMS System Manager's Manual for additional
information about these parameters.)
2.2.1.5 Writing to a Dump File off the System Disk
OpenVMS allows you to write the system dump file to a device other than the system disk. This is useful in large memory systems and in clusters with common system disks where sufficient disk space, on one disk, is not always available to support customer dump file requirements. To perform this activity, the DUMPSTYLE system parameter must be correctly enabled to allow the bugcheck code to write the system dump file to an alternative device.
The requirements for writing the system dump file off the system disk are the following:
DUMPFILE_DEVICE = $nnn$ddcuuuu |
For information on how to write the system dump file to an alternative
device to the system disk, see the HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.
2.2.1.6 Writing to the System Page File
If SYS$SYSTEM:SYSDUMP.DMP does not exist, and there is no DOSD device or dump file, the operating system writes the dump of physical memory into SYS$SYSTEM:PAGEFILE.SYS, the primary system page file, overwriting the contents of that file.
If the SAVEDUMP system parameter is set, the dump file is retained in PAGEFILE.SYS when the system is booted after a system failure. If the SAVEDUMP parameter is not set, which is the default, OpenVMS uses the entire page file for paging and any dump written to the page file is lost. (To examine or change the value of the SAVEDUMP parameter, consult the HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.)
To calculate the minimum size for a full memory dump to SYS$SYSTEM:PAGEFILE.SYS, use the following formula:
size-in-blocks(SYS$SYSTEM:PAGEFILE.SYS)
= size-in-pages(physical-memory) * blocks-per-page
+ number-of-error-log-buffers * blocks-per-buffer
+ 10
+ value of the system parameter RSRVPAGCNT * blocks-per-page
|
Note that this formula calculates the minimum size requirement for saving a physical dump in the system's page file. HP recommends that the page file be a bit larger than this minimum to avoid hanging the system. Also note that you can only write the system dump into the primary page file (SYS$SYSTEM:PAGEFILE.SYS). Secondary page files cannot be used to save dump file information.
Note also that OpenVMS will not fill the page file completely when writing a system dump, since the system might hang when rebooting after a system crash. RSRVPAGCNT pages are kept unavailable for dumps. This applies to both full dumps and selective dumps.
Writing crash dumps to SYS$SYSTEM:PAGEFILE.SYS presumes that you will later free the space occupied by the dump for use by the pager. Otherwise, your system may hang during the startup procedure. To free this space, you can do one of the following:
Every time the operating system writes information to the system dump file, it writes over whatever was previously stored in the file. The system writes information to the dump file whenever the system fails. For this reason, the system manager must save the contents of the file after a system failure has occurred.
The system manager can use the SDA COPY command or the DCL COPY command. Either command can be used in a site-specific startup procedure, but the SDA COPY command is preferred because it marks the dump file as copied. As mentioned earlier, this is particularly important if the dump was written into the page file, SYS$SYSTEM:PAGEFILE.SYS, because it releases those pages occupied by the dump to the pager. Another advantage of using the SDA COPY command is that this command copies only the saved number of blocks and not necessarily the whole allotted dump file. For instance, if the size of the SYSDUMP.DMP file is 100,000 blocks and the bugcheck wrote only 60,000 blocks to the dump file, then DCL COPY would create a file of 100,000 blocks. However, SDA COPY would generate a file of only 60,000 blocks.
Because system dump files are set to NOBACKUP, the Backup utility (BACKUP) does not copy them to tape unless you use the qualifier /IGNORE=NOBACKUP when invoking BACKUP. When you use the SDA COPY command to copy the system dump file to another file, OpenVMS does not set the new file to NOBACKUP.
As created during installation, the file SYS$SYSTEM:SYSDUMP.DMP is protected against world access. Because a dump file can contain privileged information, HP recommends that the system manager does not change this default protection.
When a dump is being analyzed, it is useful to have data available that cannot be written to the dump file at the time of the system crash. This data includes the full file specification associated with a file identification, and, on OpenVMS Integrity servers, the unwind data for images activated in processes.
If the dump is being analyzed on the system where it was originally written, this data can be collected for use in the current SDA session by using the COLLECT command. If the dump is being copied for analysis elsewhere, the COPY/COLLECT command can be used to collect the data and append it to the copy being written. If the COPY/COLLECT command is used after a COLLECT command, the data already collected is appended to the dump copy.
By default, a copy of the original dump, as written at the time of the system crash, will include collection. You can use the COPY/NOCOLLECT command to override this. Conversely, a copy of a dump previously copied by SDA without collection (COPY/NOCOLLECT) will not include collection. You can use COPY/COLLECT to override this.
Copying a dump that already contains an appended collection will always include that collection.
For all file and unwind data to be collected successfully, all disks that were mounted at the time of the system crash should be remounted and accessible to the process running SDA. If SDA is invoked early during the startup to save the contents of the dump (for example, using CLUE$SITE_PROC, as described in Section 2.2.4), but disks are not mounted until a batch job is run, the COPY/NOCOLLECT command should be used in the CLUE$SITE_PROC command procedure. Once all disks are mounted, you can use a COPY/COLLECT command to save file and unwind data.
If the COPY and COLLECT operations cannot be done as a single step, a
COLLECT/SAVE command will write the collection to a separate file that
can be used later in conjunction with the dump file. A later COPY will
combine the two files.
2.2.3 Partial Dump Copies
Because of the layout of a selective dump, it is often the case that only a small part of the dump is needed to investigate the cause of the system crash. The system manager must save the complete dump locally, as described in the previous section, but has to provide only the key sections of the dump to HP Services for analysis. This can significantly reduce the time taken to copy the dump over the network. Such a copy is referred to as a Partial Dump Copy. It can only be used when a selective system dump (compressed or uncompressed) has been written, and is not available for full system dumps or for process dumps.
If you require information from a section of the dump that was not copied, it can be extracted from the saved local copy and submitted separately. The ANALYZE /CRASH_DUMP command accepts multiple input files from the same crash and treats them as a single dump.
For an explanation of key processes and key global pages, and the
organization of a selective system dump, see the chapter Managing Page,
Swap, and Dump Files in the HP OpenVMS System Manager's Manual,
Volume 2: Tuning, Monitoring, and Complex Systems.
2.2.3.1 Example - Use of Partial Dump Copies
The following steps describe a typical use of Partial Dump Copies:
$ ANALYZE/CRASH SYS$SYSTEM:SYSDUMP.DMP OpenVMS system dump analyzer ...analyzing an I64 compressed selective memory dump... Dump taken on 22-SEP-2009 18:17:17.99 using version XC4I-J2I SSRVEXCEPT, Unexpected system service exception SDA> COPY SSRVEXCEPT.DMP SDA> EXIT |
$ ANALYZE/CRASH SSRVEXCEPT OpenVMS system dump analyzer ...analyzing an I64 compressed selective memory dump... Dump taken on 22-SEP-2009 18:17:17.99 using version XC4I-J2I SSRVEXCEPT, Unexpected system service exception SDA> COPY SSRVKEY /PARTIAL=KEY SDA> EXIT |
$ ANALYZE/CRASH SSRVKEY OpenVMS system dump analyzer ...analyzing an I64 compressed selective memory dump... Dump taken on 22-SEP-2009 18:17:17.99 using version XC4I-J2I SSRVEXCEPT, Unexpected system service exception SDA> SHOW CRASH SDA> ! |
$ ANALYZE/CRASH SSRVEXCEPT OpenVMS system dump analyzer ...analyzing an I64 compressed selective memory dump... Dump taken on 22-SEP-2009 18:17:17.99 using version XC4I-J2I SSRVEXCEPT, Unexpected system service exception SDA> COPY SSRVCSP /PARTIAL=PROCESS=NAME=CLUSTER_SERVER SDA> EXIT |
$ ANALYZE/CRASH SSRVKEY,SSRVCSP OpenVMS system dump analyzer ...analyzing an I64 compressed selective memory dump... Dump taken on 22-SEP-2009 18:17:17.99 using version XC4I-J2I SSRVEXCEPT, Unexpected system service exception SDA> SHOW PROCESS CLUSTER_SERVER SDA> ! etc. |
This section provides additional notes on Partial Dump Copies.
SDA> COPY /PARTIAL=PROCESS=NAME=CLUSTER_SERVER SSRVCSP |
SDA> COPY /PARTIAL=PROCESS=NAME=CLUSTER_SERVER SSRVCSP SDA> COPY /PARTIAL=PROCESS=NAME=(CLUSTER_SERVER) SSRVCSP SDA> COPY /PARTIAL=(PROCESS=NAME=CLUSTER_SERVER) SSRVCSP |
When the system reboots after a system failure, SDA is automatically invoked by default. SDA archives information from the dump in a history file. In addition, a listing file with more detailed information about the system failure is created in the directory pointed to by the logical name CLUE$COLLECT. (Note that the default directory is SYS$ERRORLOG unless you redefine the logical name CLUE$COLLECT in the procedure SYS$MANAGER:SYLOGICALS.COM.) The file name is in the form CLUE$node_ddmmyy_hhmm.LIS where the timestamp (hhmm) corresponds to the system failure time and not the time when the file was created.
Directed by commands in a site-specific file, SDA can take additional steps to record information about the system failure. They include the following:
If the logical name CLUE$SITE_PROC points to a valid and existing command file, it will be executed as part of the CLUE HISTORY command when you reboot. If used, this file should contain only valid SDA commands.
Generated by a set sequence of commands, the CLUE list file contains only an overview of the failure and is unlikely to provide enough information to determine the cause of the failure. HP, therefore, recommends that you always copy the dump file.
The following example shows SDA commands that can make up your site-specific command file to produce a more complete SDA listing after each system failure, and to save a copy of the dump file:
! ! SDA command file, to be executed as part of the system ! bootstrap from within CLUE. Commands in this file can ! be used to save the dump file after a system bugcheck, and ! to execute any additional SDA commands. ! ! Note that the logical name DMP$ must have been defined ! within SYS$MANAGER:SYLOGICALS.COM ! READ/EXEC ! read in the executive images' symbol tables SHOW STACK ! display the stack COPY DMP$:SAVEDUMP.DMP ! copy and save dump file ! |
The CLUE HISTORY command is executed first, followed by the SDA commands in this site-specific command file. See the reference section on CLUE HISTORY for details on the summary information that is generated and stored in the CLUE list file by the CLUE HISTORY command. Note that the SDA COPY command must be the last command in the command file. If the dump has been written to PAGEFILE.SYS, then the space used by the dump will be automatically returned for use for paging as soon as the COPY is complete and no more analysis is possible. You might need to include the /NOCOLLECT qualifier on the COPY command. See Section 2.2.2 for details.
To point to your site-specific file, add a line such as the following to the file SYS$MANAGER:SYLOGICALS.COM:
$ DEFINE/SYSTEM CLUE$SITE_PROC SYS$MANAGER:SAVEDUMP.COM |
In this example, the site-specific file is named SAVEDUMP.COM.
The CLUE list file can be printed immediately or saved for later examination.
SDA is invoked and executes the specified commands only when the system boots for the first time after a system failure. If the system is booting for any other reason (such as a normal system shutdown and reboot), SDA exits.
If CLUE files occupy more space than the threshold allows (the default is 5000 blocks), the oldest files will be deleted until the threshold limit is reached. The threshold limit can be customized with the CLUE$MAX_BLOCK logical name.
To prevent the running of CLUE at system startup, define the logical
CLUE$INHIBIT in the SYLOGICALS.COM file as TRUE in the system logical
name table.
2.3 Analyzing a System Dump
SDA performs certain tasks before bringing a dump into memory, presenting its initial displays, and accepting command input. These tasks include the following:
For detailed information on investigating system failures, see
Section 2.7.
2.3.1 Requirements
To analyze a dump file, your process must have read access both to the
file that contains the dump and to copies of
SDA$READ_DIR:SYS$BASE_IMAGE.EXE and SDA$READ_DIR:REQSYSDEF.STB (the
required subset of the symbols in the file SYSDEF.STB). SDA reads these
tables by default.
2.3.2 Invoking SDA
If your process can access the files listed in Section 2.3.1, you can issue the DCL command ANALYZE/CRASH_DUMP to invoke SDA. If you do not specify the name of a dump file in the command, and SYS$SYSTEM:SYSDUMP.DMP cannot be opened, SDA prompts you:
$ ANALYZE/CRASH_DUMP _Dump File: |
If any part of the file name is specified, the default file specification is as follows:
SYS$DISK:[default-dir]SYSDUMP.DMP
SYS$DISK and [default-dir] represent the disk and directory specified in your last SET DEFAULT command.
If you are rebooting after a system failure, SDA is automatically
invoked. See Section 2.2.4.
2.3.3 Mapping the Contents of the Dump File
SDA first attempts to map the contents of memory as stored in the specified dump file. To do this, it must first locate the page tables for system space among its contents. The system page tables contain one entry for each page of system virtual address space.
%SDA-E-SPTNOTFND, system page table not found in dump file |
%SDA-W-SHORTDUMP, dump file was n blocks too small when dump written;
analysis may not be possible
|
Under certain conditions, some memory locations might not be saved in the system dump file. Additionally, if a bugcheck occurs during system initialization, the contents of the register display may be unreliable. The symptom of such a bugcheck is a SHOW SUMMARY display that shows no processes or only the swapper process.
If you use an SDA command to access a virtual address that has no corresponding physical address, SDA generates the following error message:
%SDA-E-NOTINPHYS, 'location': virtual data not in physical memory |
When analyzing a selective dump file, if you use an SDA command to access a virtual address that has a corresponding physical address not saved in the dump file, SDA generates one of the following error messages:
%SDA-E-MEMNOTSVD, memory not saved in the dump file %SDA-E-NOREAD, unable to access location n |
After locating and reading the system dump file, SDA attempts to read the system symbol table file into the SDA symbol table. If SDA cannot find SDA$READ_DIR:SYS$BASE_IMAGE.EXE---or is given a file that is not a system symbol table in the /SYMBOL qualifier to the ANALYZE command---it displays a fatal error and exits. SDA also reads into its symbol table a subset of SDA$READ_DIR:SYSDEF.STB, called SDA$READ_DIR:REQSYSDEF.STB. This subset provides SDA with the information needed to access some of the data structures in the dump.
When SDA finishes building its symbol table, SDA displays a message identifying itself and the immediate cause of the system failure. In the following example, the cause of the system failure was the deallocation of a bad page file address.
OpenVMS Alpha System Dump Analyzer Dump taken on 27-MAR-1993 11:22:33.92 BADPAGFILD, Bad page file address deallocated |
After displaying the system failure summary, SDA executes the commands in the SDA initialization file, if you have established one. SDA refers to its initialization file by using the logical name SDA$INIT. If SDA cannot find the file defined as SDA$INIT, it searches for the file SYS$LOGIN:SDA.INIT.
This initialization file can contain SDA commands that read symbols into SDA's symbol table, define keys, establish a log of SDA commands and output, or perform other tasks. For instance, you may want to use an SDA initialization file to augment SDA's symbol table with definitions helpful in locating system code. If you issue the following command, SDA includes those symbols that define many of the system's data structures, including those in the I/O database:
READ SDA$READ_DIR:filename |
You may also find it helpful to define those symbols that identify the modules in the images that make up the executive by issuing the following command:
READ/EXECUTIVE SDA$READ_DIR: |
After SDA has executed the commands in the initialization file, it displays its prompt as follows:
SDA> |
This prompt indicates that you can use SDA interactively and enter SDA commands.
An SDA initialization file may invoke a command procedure with the @
command. However, such command procedures cannot invoke other command
procedures.
2.4 Analyzing a Running System
Occasionally, OpenVMS encounters an internal problem that hinders system performance without causing a system failure. By allowing you to examine the running system, SDA enables you to search for the solution without disturbing the operating system. For example, you may be able to use SDA to examine the stack and memory of a process that is stalled in a scheduler state, such as a miscellaneous wait (MWAIT) or a suspended (SUSP) state.
If your process has change-mode-to-kernel (CMKRNL) privilege, you can invoke SDA to examine the system. Use the following DCL command:
$ ANALYZE/SYSTEM |
SDA attempts to load SDA$READ_DIR:SYS$BASE_IMAGE.EXE and SDA$READ_DIR:REQSYSDEF.STB. It then executes the contents of any existing SDA initialization file, as it does when invoked to analyze a crash dump (see Sections 2.3.4 and 2.3.5, respectively). SDA subsequently displays its identification message and prompt, as follows:
OpenVMS Alpha System Analyzer SDA> |
This prompt indicates that you can use SDA interactively and enter SDA commands. When analyzing a running system, SDA sets its process context to that of the process running SDA.
If you are analyzing a running system, consider the following:
When using SDA to analyze a running system, carefully interpret its displays. Because system states change frequently, it is possible that the information SDA displays may be inconsistent with the current state of the system. |
%SDA-E-CMDNOTVLD, command not valid on the running system |
When you invoke SDA to analyze either a crash dump or a running system, SDA establishes a default context for itself from which it interprets certain commands.
When you are analyzing a uniprocessor system, SDA's context is solely process context, which means SDA can interpret its process-specific commands in the context of either the process current on the uniprocessor or some other process in another scheduling state. When SDA is initially invoked to analyze a crash dump, SDA's process context defaults to that of the process that was current at the time of the system failure. When you invoke SDA to analyze a running system, SDA's process context defaults to that of the current process, that is, the one executing SDA. To change SDA's process context, issue any of the following commands:
SET PROCESS process-name
SET PROCESS/ADDRESS=pcb-address
SET PROCESS/INDEX=nn
SET PROCESS/NEXT
SET PROCESS/SYSTEM
SHOW PROCESS process-name
SHOW PROCESS/ADDRESS=pcb-address
SHOW PROCESS/INDEX=nn
SHOW PROCESS/NEXT
SHOW PROCESS/SYSTEM
VALIDATE PROCESS/POOL process-name
VALIDATE PROCESS/POOL/ADDRESS=pcb-address
VALIDATE PROCESS/POOL/INDEX=nn
VALIDATE PROCESS/POOL/NEXT
VALIDATE PROCESS/POOL/SYSTEM
When you invoke SDA to analyze a crash dump from a multiprocessing system with more than one active CPU, SDA maintains a second dimension of context---its CPU context---that allows it to display certain processor-specific information. This information includes the reason for the bugcheck exception, the currently executing process, the current IPL, and the spinlocks owned by the processor. When you invoke SDA to analyze a multiprocessor's crash dump, its CPU context defaults to that of the processor that induced the system failure. When you are analyzing a running system, CPU context is not accessible to SDA. Therefore, the SET CPU command is not permitted.
You can change the SDA CPU context by using any of the following commands:
SET CPU cpu-id
SET CPU /FIRST
SET CPU /NEXT
SET CPU /PRIMARY
SHOW CPU cpu-id
SHOW CPU /FIRST
SHOW CPU /NEXT
SHOW CPU /PRIMARY
SHOW CRASH
SHOW MACHINE_CHECK cpu-id
Changing CPU context involves an implicit change in process context in either of the following ways:
Changing process context requires a switch of CPU context as well. For instance, when you issue a SET PROCESS command, SDA automatically changes its CPU context to that of the CPU on which that process was most recently current. The following commands can have this effect:
SET PROCESS process-name
SET PROCESS/ADDRESS=pcb-address
SET PROCESS/INDEX=nn
SET PROCESS/NEXT
SHOW PROCESS process-name
SHOW PROCESS/ADDRESS=pcb-address
SHOW PROCESS/INDEX=nn
SHOW PROCESS/NEXT
VALIDATE PROCESS/POOL process-name
VALIDATE PROCESS/POOL/ADDRESS=pcb-address
VALIDATE PROCESS/POOL/INDEX=nn
VALIDATE PROCESS/POOL/NEXT
| Previous | Next | Contents | Index |