System crashing on our Charon Box, running Openvms 7.3

[vmsserbo]

The VMS crash dumps I have looked at say "INVEXCEPTN, Exception while above ASTDEL or on interrupt stack" which is a generic error to say that the error occurred at a higher priority than the error handler, and does not really tell you what happened. It could be a hardware problem, it could be an operating system or similar error.
These crashes continue to be a mystery. The first mystery crash was on November 9th. Here is the list of TEAM10 boots:

TEAM10 BOOTED AT 9-NOV-2006 15:02 ! Thursday
TEAM10 BOOTED AT 10-NOV-2006 15:00 ! Friday
TEAM10 BOOTED AT 16-NOV-2006 15:05 ! Thursday
TEAM10 BOOTED AT 17-NOV-2006 15:19 ! Friday
TEAM10 BOOTED AT 17-NOV-2006 15:05
TEAM10 SHUTDOWN AT 17-NOV-2006 15:38 BY SYS_DAVIDP
TEAM10 BOOTED AT 17-NOV-2006 15:39 ! Planned
TEAM10 BOOTED AT 18-NOV-2006 14:59 ! Saturday
TEAM10 BOOTED AT 4-DEC-2006 08:32 ! Power Outage to the Computer Room
TEAM10 BOOTED AT 5-DEC-2006 15:09 ! Tuesday
TEAM10 BOOTED AT 9-DEC-2006 15:09 ! Saturday
Anyone have any thoughts of what it could be or where we could find more clues?

[Ian Miller. · Accepted solution]

any CLUE files in SYS$ERRORLOG?

[Volker Halle]

Miles,

OpenVMS VAX (since V6.2) has a standalone CLUE utility, which should keep the crash footprint from the last 100 crashes or operator shutdowns.

$ CLUE:==$CLUE
$ CLUE/DISPLAY

The last crash (or shutdown) CLUE file can be found in CLUE$OUTPUT:CLUE$LAST_TEAM10.LIS

INVEXCEPTN crashes are most likely operating system or privileged software errors. Did you recognize, that those crashes seem to mostly happen around 15:00 ??? So this may be some other 'clue' ;-)

You can extract the most important crash parameters (called CANASTA parameters) from each crash using the command:

CLUE_DISPLAY> n ! where N is the 'crash number #' from the CLUE/DISPLAY crash listing (first column).

Please provide the CANASTA paramters from a typical INVEXCEPTN crash or even provide the full CLUE$OUTPUT:CLUE$LAST_TEAM10.LIS file as a .TXT attachment.

Volker.

[vmsserbo]

Thanks I will

[B Claremont]

A couple of suggestions:

- Double check that no Windows processes are trying to access the disk container files or disk drives allocated to the CHARON-VAX system.

- If you have a NIC dedicated to the CHARON system, check it for problems.

Bruce Claremont
www.MigrationSpecialties.com
OpenVMS Stealth Marketing Squad

[Stanley F Quayle]

This might not be a CHARON-VAX problem.

If you migrated from a working system, but changed from another disk technology (DSSI?) to CHARON's SCSI and MSCP disks, youshould verify that you have the latest VMS patches.

CHARON-VAX isn't a match to every possible VAX model. You should also AUTOGEN -- I've seen "unstable" VMS installations when migrated to different hardware.

You should also keep your reseller in the loop. CHARON-VAX is updated regularly -- you might need the latest version...

[Volker Halle]

Please let's stop speculating about possible reasons for OpenVMS VAX on a CHARON-VAX crashing with INVEXCEPTN ! Once the CLUE file is available, we can look at it and figure out, where the problem might be coming from. Until that information is available, everything else is unfounded speculation.

Volker.

[vmsserbo]

I have attached the info of the clue?

[Volker Halle]

Miles,

this crash is most likely in non-Digital OpenVMS software ! You must have some 3rd-party privileged software running. The OpenVMS execlets are normally symbolized correctly by CLUE. Your crash is reported at:

ALLOCATABLE_S0+3D5DFAB PC>83D68F2F PUSHL 54(R10)

R10 being 00000067, which causes an acccess violation at virtual address 000000BB

The question now is, who owns that code ? Most likely suspect would be: MULTINET

Volker.

[comarow]

It might well be in memory management and system primitives. Should it be a real VAX I'd make sure you had the lastest
SYS eco. MAke sure you have the latest
Multinet ECO.

Have fun.

Bob

[John Travell]

Sounds to me like you need interactive analysis of the crashdumps.
Do you have this machine on a s/w support contract ? If not, you need to see if there is a budget available to pay for independent analysis.
Is there any security restriction on sending the dump offsite ? If not, there are a number of people with the expertise to do that analysis in the group (me included). The alternative would be to establish a VPN between your site and your approved expert.

[Volker Halle]

Miles,

your OpenVMS VAX system is running MULTINET. You can try to symbolize the failing PC address using the MULTINET.STB file to be found somewhere on your system disk:

$ ANAL/CRASH SYS$SYSTEM:SYSDUMP.DMP

Search for ASCII string 'INET' in allocatable S0 space:

SDA> SEARCH/STEPS=BYTE/LENGTH=LONG MMG$A_SYS_END:@EXE$GL_RPB 54454E49

Note: It will take a while to search through the dump, so be patient ...

Match at xxxxxxxx <<< should report 1 match

SDA> EXA xxxxxxxx ! Verify address found above, you should see the string 'INET'

Find MULTINET.STB on your system disk, then:

SDA> READ/RELOCATE=xxxxxxxx dev:[dir]MULTINET.STB

SDA> SHOW CRASH
SDA> SHOW STACK

These commands should load the MULTINET symbols and provide a better symbolization of the crash stack and failing PC.

Volker.

[Jim_McKinney]

MultiNet symbols can be loaded in SDA as follows

$ define mu$sda multinet:multinet$sda
$ analyze/system
SDA> mu load