bad dumpfile

[Willem Grooters]

VMS7.3-2:

Had a crash and wanted to analyse it, but SDA cannot open the dumpfile:

$ ana/crash sysdump.dmp

OpenVMS (TM) system dump analyzer
%SDA-E-NOTALPHADUMP, dump file does not contain an OpenVMS Alpha dump

Same error was in CLUE log generated after booting from this crash.

Looked in HELP and found /OVERRIDE switch, but that didn't get me any further:

$ ana/crash sysdump.dmp/over

OpenVMS (TM) system dump analyzer
%SDA-W-NOTALPHADUMP, dump file does not contain an OpenVMS Alpha dump
%SDA-W-DUMPEMPTY, dump file contains no valid dump
%SDA-W-INCDUMPFORM, dump file format incompatible with this version of SDA
...analyzing an Alpha full memory dump in override mode...

%LIB-F-BADBLOSIZ, bad block size

I presume I need to create a new dumpfile, so do I need to crash the machine for that?

Willem

[John Gillings]

Willem,

Was this system rebooted between the crash and the attempt to analyze the dump?

It looks like exactly what the error says, there's no dump information to analyze.

You don't need to create a new dump file. The file itself can't be "corrupt" - it's just a bunch of blocks. If the system crashes, the dump will be written to the file, and should be analyzable. HOWEVER, you MUST analyze it or use the SDA COPY command to copy it elsewhere before rebooting the system again. A "normal" reboot will invalidate any dump information.

If the dump has been lost, perhaps you have console logs? These may be sufficient to identify the cause of the bugcheck.

Maybe this makes it a bit clearer:

BUGCHECK
BOOT
dump can be analyzed or COPYd
REBOOT
dump is now invalid

[Wim Van den Wyngaert · Accepted solution]

Willem,

Perhaps your dump file is too small (e.g. due to upgrades in which the dump file size wasn't enlarged). If you have a log of the console you can check if it dumped ...

WIm

[Willem Grooters]

Hi John.

Quite obviously a boot: after crash! I was triggered to investigate by the contents of a CLUE logfile - created during that boot.

The requirement to copy the dumpfile fires another question.
AFAIK, it's usual to check for a crash on (re)boot. I didn't add anything (yet) to do this, but there IS a CLUE logfile on my system, so I assume something is built-in somewhere. This does raise the question when SYS$SYSTEM:SYSDUMP.DBP is 'invalidated'. It must be AFTER the investigation in the startup procedure. Given the output in the logfile, this is not safe enough!
What would happen if the system stopped for another reason (power loss, for instance). In that case there will be no SYSDUMP written, and SYSDUMP.DMP may be invalid - as stated. (This could well have happend, which would explain the situation)

Willem

[Wim Van den Wyngaert]

Willim & John,

Just a stupid question (don't have that many crashes over here).

Why is a dump invalidated during a normal boot ? Couldn't it stay valid until the next crash ?

Can I rename the dump and do re-create ?

Wim

[Ian Miller.]

I think a crash dump may be invalidated on a normal shutdown not by startup

[Mobeen_1]

Willem,
Looks like you need to define a new dump device (try to do this to a different disk/place) and then the only option of generating a new dump is by bringing down the machine and while at boot prompt (>>>) issue a Ctrl+P

rgds
Mobeen

[Helmut Ammer]

Hello Willem,

do you know from the console log what physical device the dump was written to.

Is your dump file located on the system disk?

Is the dump disk a shadowset?
If yes check pp 3-6 in Alpha System Analysis Tools Manual (V7.3-1 AA-REZTC-TE).

Regards
Helmut

[Volker Halle]

Willem,

starting with OpenVMS Alpha V7.1, system dumpfiles are NOT invalidated anymore during normal shutdowns. The errlog-buffers are written to SYS$SYSTEM:SYS$ERRLOG.DMP, so SYSDUMP.DMP is not written to during shutdown at all.

Try $ DUMP/BL=COU=1 SYS$SYSTEM:SYSDUMP.DMP to see if anything has been written at all.
If the system disk can be accessed via multiple pathes, all of them may need to be added to the DUMP_DEV console environment variable.

You should also be able to at least find the bugchecks entry with $ ANAL/ERR/ELV TRANSLATE /SIN=.../BEFORE=... - the errlog entries are read from SYS$ERRLOG.DMP during startup and added to ERRLOG.SYS

As of V7.3-2, SDA should be able to correctly find dump information on shadowed system disks.

Volker.

[Willem Grooters]

Currently I'm far, far way from the server so I am not able to try out the suggestions.
However:
When cheking the status (Luckily I can access it), I found it restarted one night. When trying to see why, I got the very same message.
Today, attempting to run a commandprocedure, the connection appeared hung - but yes: the machine had indeed rebooted - presumably because of a crash. ANALYZE/CRASH however, which is in the startup-sequence somewhere, revealed exactly the same problem; a new CLUE-logfile has been created stating the very same message.
So it seems I have no ability to find out what was wrong.