1747988 Members
4880 Online
108756 Solutions
New Discussion юеВ

Bugcheck 0000036c

 
SOLVED
Go to solution
Wim Van den Wyngaert
Honored Contributor

Bugcheck 0000036c

I have a bugcheck on an Alphas6taion 400/400 running VMS 7.3. In a cluster with 2 GS160 (it's the q station). See enclosure.

I suspect that a file has gone bad.
A power cycle has already been done.
system parameters have not been changed since previous boot (2 years ago).
I tried minimal boot and it bugchecks too.

How to debug this bugcheck ?

Wim

PS Machine is not at my location.
Wim
25 REPLIES 25
Wim Van den Wyngaert
Honored Contributor

Re: Bugcheck 0000036c

Looks scrambled at the end.
Post it again.

Wim
Wim
Jur van der Burg
Respected Contributor

Re: Bugcheck 0000036c

The system disk is bad. Errorcode = 910 = %SYSTEM-W-NOSUCHFILE, no such file while trying to start SYSINIT.EXE. Check the disk by booting from a CD or alternate disk.

Jur.
Wim Van den Wyngaert
Honored Contributor

Re: Bugcheck 0000036c

I mop booted the station into another station but this without page/swap file.

Then I verified the disk with anal/dis/read/repair. No errors at all.

Did anal/rms of sysinit.exe. No errors.

Tried booting it again from disk. Bugcheck.

Strange.

Wim

Wim
Wim Van den Wyngaert
Honored Contributor

Re: Bugcheck 0000036c

%EXECINIT-I-LOADING, loading SYS$FILES_64.EXE
%EXECINIT-E-LOADERR, error loading SYS$FILES_64.EXE, status = 00000910
%EXECINIT-I-LOADING, loading SYS$XFS_CLIENT.EXE
%EXECINIT-E-LOADERR, error loading SYS$XFS_CLIENT.EXE, status = 00000910
%EXECINIT-I-LOADING, loading SYS$XFS_SERVER.EXE
%EXECINIT-E-LOADERR, error loading SYS$XFS_SERVER.EXE, status = 00000910
%EXECINIT-I-LOADING, loading SYS$LFS.EXE
%EXECINIT-E-LOADERR, error loading SYS$LFS.EXE, status = 00000910

These files don't exist on my other systems too.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: Bugcheck 0000036c

I filled the disk completely while booted via mop. Then verified it again. Still no error.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: Bugcheck 0000036c

I stopped the whole GS160 cluster. Then restarted it (yes, lucky I can do that today). Bugcheck is present even when booted as first node in cluster.

I also defragmented the disk before reusing it. No problems while defragmenting.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: Bugcheck 0000036c

I analyzed the dump. See encl.

Wim
Wim
Hoff
Honored Contributor

Re: Bugcheck 0000036c

PROCGONE involves looking at the registers to see what happened. 00000910 is file not found/FNF, as others have mentioned. Then digging around from there.

V7.3? ECO it or (better) upgrade to V7.3-2 and ECO it. Chasing old bugs and particularly chasing old and fixed bugs is a waste of time. I'd slam in a replacement copy of OpenVMS Alpha onto this disk.

Do check the system battery for this box; the boot year is 1858. That can cause various weirdness, though I've not specifically seen it trigger a crash.

Those files listed as 00000910 errors are very likely the remnants of an old Spiralog installation, and that product should have been deinstalled several releases ago. I'd *guess* that a series of 00000910/FNF references are not the proximate trigger for the error, though stranger things have happened. See if a combination of SYS_LOADABLE REMOVE on the Spiralog images and invoking SYS$UPDATE:VMS$SYSTEM_IMAGES.COM cleans up that part of the diagnostic display. (The diagnostic bootstrap might point at the specific file.)

As for another approach toward troubleshooting, enable boot time diagnostics via R5 (30000, IIRC), and look to clear out the Spiralog loadable images via the LOAD_SYS_IMAGES parameter.

But then, the best approach with what is very clearly a somewhat questionable system disk that's not being used for anything other than as a quorum node is to slam new V7.3-2 bits onto the disk, load the current ECOs, slam CLUSTER_AUTHORIZE.DAT and VOTES and EXPECTED_VOTES from values expected for the the cluster, and see if that fixes this case.

I have to ask what you expect to gain by debug this. Not to be sarcastic or cynical or such here; I've simply found that there are cases when the knowledge and the value that might be provided from troubleshooting a bugcheck is worth zero. And it costs. Analyzing a crashdump is the software equivalent of troubleshooting hardware. There are cases where that approach is valuable, and there are cases when it is better to swap out the gear with the more current gear. But for this "quorum host" box, new bits (ECOs and/or upgrades) seem an easy and efficient and expeditious diagnostic.

Stephen Hoffman
HoffmanLabs LLC


Richard Brodie_1
Honored Contributor

Re: Bugcheck 0000036c

I'm not an expert but I would take a look at SHOW EXEC and compare it with a live system. What was the last module loaded, and the first not loaded?