Info on FILCNTNONZ bugcheck?

[Tony_289]

Hello, Has anyone experienced the dreaded FILCNTNONZ bugcheck (file count non zero after process rundown)? Any hints as to what conditions may trigger this? Here is some background:1) running OpenVMS 7.1-2, and 7.2-2. 2) not easy to simply upgrade or apply ECO's. 3) Many, many cyclic and muliple process creations and terminations are involved. 4) 99.9% of processes running at time of crash are batch jobs. Thanks!

[Hein van den Heuvel]

This could be "An attempt to close a file, whose disk has timed out in mount-verification".

Google gives a hit on an ECO: VMS721H1_SYS-V0600

CrashDump Summary
-----------------
Bugcheck Type: FILCNTNONZ, Open file count nonzero
after process rundown
Current Image:
Failing PC: FFFFFFFF.D269A360
PROCESS_MANAGEMENT+3C360
Failing PS: 18000000.00000000
Module: PROCESS_MANAGEMENT (Link Date/Time:
18-OCT-2000 07:01:30.44)
Offset: 0003C360

Images Affected:[SYS$LDR]IO_ROUTINES.EXE
[SYS$LDR]IO_ROUTINES_MON.EXE



Case CFS.103399 ?


hth,
Hein.

[Volker Halle]

Tony,

there are a couple of possible reasons for this crash. It can either happen during image (in IMAGE_MANAGEMENT.EXE) or process (in PROCESS_MANAGEMENT.EXE) rundown.

You'll find the $DASSGN system service failure status in R0 and the channel control block address in R5 or R3:

$ ANAL/CRASH sys$system:sysdump.dmp
SDA> EVA/COND R0
SDA> READ SYSDEF
SDA> FORMAT/TYPE=ccb @R5 - or @R3
SDA> SHOW DEV/ADDR=@@R5 - or @@R3 - should show disk

There are a couple of patches, which refer to a solution for this kind of problem. The most promising ones would be those referencing CFS.103399 (as referred to by Hein). For V7.2-2 it's VMS722_SYS-V0200, there does not seem to be a patch for this problem for V7.1-2.

If you could provide the CLUE files from CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS (at least the CLUE CRASH output from SDA> CLUE CRASH) as an attachment to your next reply, I can further confirm this.

Volker.

[Tony_289]

Thanks Hein/Volker for the responses! I have attached the Clue listing from the 7.1-2 system. My apologies, the other system is 7.2-1 (bad typing :-( ). My site has never had this bugcheck at times of mount verification, just once (on the 7.2-1) did someone log out and "trigger" the bugcheck. For either version, the bugchecks seen had the current process be a job in the Sys$Batch Queue. By the way, the listing attached is from a scheduled shutdown of the applications running on the node. All other times the bugcheck occurred during "normal" runtime conditions. We are looking into upgrades and ECO's, but previous searches for resolutions didn't seem to match our problem.

I appreciate any tips for troubleshooting or analysis of this problem. Let me know if you desire further info. Thanks

[Volker Halle · Accepted solution]

Tony,

this IS the problem referred to by Hein (CFS.103399).

Unfortunatley, there never have been patches released for the NOW UNSUPPROTED versions V7.1-2 or V7.2-1 to fix this longstanding problem. Those versions were already UNSUPPORTED when the solution had been coded.

Use the SDA commands from my previous post to confirm that R3 is indeed pointing to the CCB and SDA> SHOW DEV/ADDR=@@R3 will show you the device.

If you have a software service contract with HP, you can try to contact them and ask for the solution (a new SYS patch or at least new exec images for V7.1-2 and V7.2-1), but you'll certainly be charged for this (if HP accepts this call at all) ...

Volker.

[Tony_289]

Thanks for confirming, Volker. I will take this back to those who have the cash, and see what can be done (hopefully soon!)I'll double-check R3

I've enjoyed "ask the wizard" and this forum is really helpful. I'll close this thread as resolution is contingent upon when the upgrade happens. Thanks all!

Tony