Bugcheck Error

[Louann Duchemin]

I have had two tiste that have recorded the following error.

INVEXCEPTN, Exception while above ASTDEL

How ever the PC code portion of the error differs. The first one is:
SDA>examine/inst FFFFFFFF800A3708
EXE$REFLECT_C+00638: SLL R7,#X3B,R2

The other is:
SDA> examine/inst FFFFFFFF803359C0
CNX$SEND_MSG_CSB_V2_C+00250: LDQ RD6,#XFFD0(R13)


Can some one explaine to me the meaning of these? Both site are currently running OpenVMS version 7.3.

[Jefferson Humber]

The INVEXCEPTN could be down to many things.

How upto date are you with ECO patches for you v.7.3 release ?

Upto to date list available here -> ftp://ftp.itrc.hp.com/openvms_patches/

[Volker Halle]

Louann,

if possible, please provide the full crash information (the CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS from the date of the crash) - but at least the output of the SDA> CLUE CRASH command - as an attached .TXT file.

In case of an invalid exception, you need to look at the PC of the failing instruction in the Signal Array. Together with the condition code in the Signal Array and the instruction, a first analysis may be possible.

The instruction in your first example shown can NOT generate an exception. So it was either a TRAP and you're looking at the updated PC after the failure or you looked at the wrong PC.

In your second example, R13 must have pointed to an invalid/inaccessible address for this instruction to have caused an exception.

Talking about patches should be delayed, until you better understand the circumstances of the crash.

Volker.

[Jeff Chisholm]

There is an in-line bugcheck in EXE$REFLECT at offset 634, with SLL R7,#X3B,R2 immediately following at offset 638. Let's have a look at the CLUE files as Volker suggested please.

[Louann Duchemin]

Here is one of the print outs requested.

[Volker Halle]

Louann,

sorry, but the bugcheck errlog entry does not help at all.

Pleass look at your system disk in the directory pointed to by the logical CLUE$COLLECT. You will find one 'CLUE' file for each valid bugcheck:

CLUE$node_ddmmyy_hhmm.LIS

Date and time are the bugcheck date and time.

If you use the command $ TYPE CLUE$HISTORY, you will get a one-line summary information for each bugcheck seen on your system (use $ SET TERM/WID=132, as the information is 132 columns wide).

Please attach the 'CLUE' files from the relevant crashes.

Volker.

[Louann Duchemin]

The information in the file is very old. Information is dated Feb. 2000. There is nothing current here.

Do you know if there are any issues with upgrading the memory in the DS10's? This is what happened at the site just prior to this Bug Check.

[Volker Halle]

Louann,

where did you get the SDA information from, which you showed us in your initial posting ? Do you still have access to the crashdump ? If so, you could post the output of the SDA> CLUE CRASH command.

Maybe you're using DOSD and have not correctly set up your CLUE$DOSD_DEVICE logical during startup.

Hardware (memory) problems should show up as MACHINECHK or MCHECKPAL bugchecks.

Volker.

[Louann Duchemin]

The information came from the DIAG. Looks like we were not able to get a crash dump.

OpenVMS (TM) Alpha system dump analyzer
...analyzing a compressed selective memory dump...

%SDA-E-NOTSAVED, S0/S1 space not saved in the dump file

[Volker Halle]

Louann,

the bugcheck-PC examined in your initial posting

EXE$REFLECT_C+00638: SLL R7,#X3B,R2

is in the central INVEXCEPTN bugcheck reporting routine. For an INVEXCEPTN bugcheck, you can not use the SDA> EXA/INS @PC command to obtain the failing instruction. You need to provide and examine the bugcheck-PC from the signal array. The SDA> CLUE CRASH command always does the right thing for you - depending on the crash context.

Volker.

[Volker Halle]

Louann,

you cannot use the bugcheck PC reported in ERRLOG.SYS for any exception-related bugchecks, as it points to a central routine and not to the actual failing PC.

If you have access to the console output from the time of the crash, you could find out, if there has been an error while writing the dump.

Make sure that your dump file is big enough (run @AUTOGEN SAVPARAMS TESTFILES FEEDBACK) and see, which dumpfile size AUTOGEN would suggest.

If the system sapce could not be saved in the dump, there is nothing further you can do.

Volker.

[Louann Duchemin]

Unfortunatly, clue crash can not be run on an active system.

What about any issues with VMS73_ECO Patch kit 5 and DS10's? I've had 5 DS10's have a crash of one of there nodes this pass weekend with bugchecks.

[Volker Halle]

Louann,

SDA> CLUE CRASH obtains the most important crash footprint from the dumpfile. No readable dump - no crashdump info, sorry. Speculation does not help.

You said the 'CLUE' files were all very old. Did have have any crashes, for which no CLUE files have been created ? This would definitely indicate a problem when writing the dump. CLUE files are automatically created during startup (see SYS$STARTUP:CLUE$STARTUP_node.LOG files for errors reading the dump). A one-line information is also appended to the CLUE$HISTORY file.

Check that your SYS$SYSTEM:SYSDUMP.DMP files are big enough (as suggested by AUTOGEN).

Volker.