orp
asked on
panic : Lookup handle : null handle
Hi ,
My server (notes 4.57d) keeps crashing with the message :
panic : Lookup handle : null handle
and there is nothing I can do except rebooting the Notes.
Any Idea ?
(I have got another message before this :
Searching administration request database)
Thanks.
Orp.
My server (notes 4.57d) keeps crashing with the message :
panic : Lookup handle : null handle
and there is nothing I can do except rebooting the Notes.
Any Idea ?
(I have got another message before this :
Searching administration request database)
Thanks.
Orp.
ASKER
Thanks for the quick answer, and yes i know there are tons of possibilities - I have found them but non of them fit my problem.
I'll be happy to get the links you are talking about,
THanks again.
Orp
I'll be happy to get the links you are talking about,
THanks again.
Orp
Still we will need more infos. What about the log ?
Is there some pending admin request ? Did you lately recertify users or some other work with the Adminp ?
Is there some pending admin request ? Did you lately recertify users or some other work with the Adminp ?
ASKER
there is nothing special in the log file except the sentence : Searching administration request database.
Did you get a RIP file generated? If so look for the 1st nsf file listed and that will be the database that it died on. I have had that error message several times in the pass and it was always something this version could not handle. Lotus support always told me to upgrage to a newer version and the problem would go away until I would find something new it could not handled.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Orp,
I think Fredrik meant to say the latest R4.5x (4.5.7g) version or perhaps R4.x version (4.6.6c). I'm sure he did mean to upgrade to the latest version (R5.0.2c).
Below you will find the fix list for the QMU's from 4.5.7d to 4.5.7g. None of these fixes (SPRs) really point to an obvious fix for this error, so I would think that the error is probably not directly related to the Notes Server version ... I could be wrong.
Paebdb is correct in that there are many things that could cause this, however; you said that the Server reported "Searching administration request database" before crashing. Knowing this bit of information, I would check the "Administration Requests" database (ADMIN4.NSF) to see if there are any pending requests, or apparent errors. If there are pending requests then this might point you to the culprit (see Technote 169201). Depending on how many Notes Servers are in your Notes Domain, you may want to delete the ADMIN4.NSF and pull a new replica from a Server that is not experiencing any problems. If this is your only Notes Server then you could bring the Server down rename/move ADMIN4.NSF and recreate a new one. Another cause that could be associated with the "Administration Requests" dB is a corrupt Public Name & Address Book (NAB). If the "Administration Requests" dB is doing a lookup in the NAB and it is corrupt this could cause a PANIC. Also, I would do as blackr99 suggested and look for a NOTES.RIP file on the Server. This will assist you in isolating the problem.
If you do not run FIXUP or COMPACT very often then I would do as Fredrik suggested and do some database maintenance. I would recommend doing this after hours as it can be pretty intensive on the Server. Best scenario is to create Programs Documents for this and run them late at night.
1.) Run FIXUP this will check for database integrity and fix any problems that it can.
2.) After FIXUP finishes run COMPACT this will compact all whitespace in the databases.
3.) After COMPACT finishes run UPDALL -R this will rebuild all the view indexes.
*Note: Theses ServerTasks will not run on some databases (i.e. NAMES.NSF, LOG.NSF, DOMLOG.NSF, STATREP.NSF and basically any dB that is constantly held open by the Server).
*** 4.5.7e QMU fixes ***
SPR# BLAE4AFHHQ - Increases the width of the Print range fields in the File Print dialog for calendar entries to accommodate the display of a year with four digits. This affects all non-unix client platforms for both Release 4.5 and Release 4.6 (Macintosh, OS/2 Warp, Workspace On-Demand, Windows 3.1, Windows 95/98, and Windows NT).
SPR# BLAE4AFK5Z - Increases the width of the Date field in the Free Time dialog for calendar entries to accommodate the display of a year with four digits. This affects OS/2 Warp and Workspace On-Demand client platforms for Release 4.5. This does not affect any of the Release 4.6 platforms
*** 4.5.7f QMU fixes ***
Client - OS/2 only
SPR# LMEF4C7NY5 - Correctly store extended characters in Web documents when editing them from an OS/2 client.
*** R4.5.7g QMU fixes ***
API
SPR# PJAN4F5T93 - Fix a problem with NSFNoteComputeWithForm that caused a memory overwrite when a date was stored in a text field and the date was in the year 2000 or greater. One of the manifestations of the problem was a crash in Agent Manager when agents created mail messages using the R4.6x mail stationery, "Gray Gradient with Lines," when the form was stored in the document. There could be other manifestations depending on the memory configuration on any given system. This problem affects both clients and servers.
Client
SPR# CLEC43UL2C - Fix a performance problem resulting from a workstation reloading the design collection of a database each time a view or folder was opened for the first time. Obviously, this performance problem would be greatly amplified on slow connections.
Server
SPR# KSMH4F9U8K - Fix a problem with the security of Agents.
Template - Mailfile
SPR# WEVT4F8354 - Fix a display problem in the "From The Desk" letterhead that causes the AM/PM part of the time to fail to be available when the year is displayed as four digits.
SPR# TKIE4F76AQ - Change the tmpDate field in the "Gray Gradient with Lines" mail stationery subform from type Text to type Date/Time.
Hope this help you in your fight : )
St. Harris
I think Fredrik meant to say the latest R4.5x (4.5.7g) version or perhaps R4.x version (4.6.6c). I'm sure he did mean to upgrade to the latest version (R5.0.2c).
Below you will find the fix list for the QMU's from 4.5.7d to 4.5.7g. None of these fixes (SPRs) really point to an obvious fix for this error, so I would think that the error is probably not directly related to the Notes Server version ... I could be wrong.
Paebdb is correct in that there are many things that could cause this, however; you said that the Server reported "Searching administration request database" before crashing. Knowing this bit of information, I would check the "Administration Requests" database (ADMIN4.NSF) to see if there are any pending requests, or apparent errors. If there are pending requests then this might point you to the culprit (see Technote 169201). Depending on how many Notes Servers are in your Notes Domain, you may want to delete the ADMIN4.NSF and pull a new replica from a Server that is not experiencing any problems. If this is your only Notes Server then you could bring the Server down rename/move ADMIN4.NSF and recreate a new one. Another cause that could be associated with the "Administration Requests" dB is a corrupt Public Name & Address Book (NAB). If the "Administration Requests" dB is doing a lookup in the NAB and it is corrupt this could cause a PANIC. Also, I would do as blackr99 suggested and look for a NOTES.RIP file on the Server. This will assist you in isolating the problem.
If you do not run FIXUP or COMPACT very often then I would do as Fredrik suggested and do some database maintenance. I would recommend doing this after hours as it can be pretty intensive on the Server. Best scenario is to create Programs Documents for this and run them late at night.
1.) Run FIXUP this will check for database integrity and fix any problems that it can.
2.) After FIXUP finishes run COMPACT this will compact all whitespace in the databases.
3.) After COMPACT finishes run UPDALL -R this will rebuild all the view indexes.
*Note: Theses ServerTasks will not run on some databases (i.e. NAMES.NSF, LOG.NSF, DOMLOG.NSF, STATREP.NSF and basically any dB that is constantly held open by the Server).
*** 4.5.7e QMU fixes ***
SPR# BLAE4AFHHQ - Increases the width of the Print range fields in the File Print dialog for calendar entries to accommodate the display of a year with four digits. This affects all non-unix client platforms for both Release 4.5 and Release 4.6 (Macintosh, OS/2 Warp, Workspace On-Demand, Windows 3.1, Windows 95/98, and Windows NT).
SPR# BLAE4AFK5Z - Increases the width of the Date field in the Free Time dialog for calendar entries to accommodate the display of a year with four digits. This affects OS/2 Warp and Workspace On-Demand client platforms for Release 4.5. This does not affect any of the Release 4.6 platforms
*** 4.5.7f QMU fixes ***
Client - OS/2 only
SPR# LMEF4C7NY5 - Correctly store extended characters in Web documents when editing them from an OS/2 client.
*** R4.5.7g QMU fixes ***
API
SPR# PJAN4F5T93 - Fix a problem with NSFNoteComputeWithForm that caused a memory overwrite when a date was stored in a text field and the date was in the year 2000 or greater. One of the manifestations of the problem was a crash in Agent Manager when agents created mail messages using the R4.6x mail stationery, "Gray Gradient with Lines," when the form was stored in the document. There could be other manifestations depending on the memory configuration on any given system. This problem affects both clients and servers.
Client
SPR# CLEC43UL2C - Fix a performance problem resulting from a workstation reloading the design collection of a database each time a view or folder was opened for the first time. Obviously, this performance problem would be greatly amplified on slow connections.
Server
SPR# KSMH4F9U8K - Fix a problem with the security of Agents.
Template - Mailfile
SPR# WEVT4F8354 - Fix a display problem in the "From The Desk" letterhead that causes the AM/PM part of the time to fail to be available when the year is displayed as four digits.
SPR# TKIE4F76AQ - Change the tmpDate field in the "Gray Gradient with Lines" mail stationery subform from type Text to type Date/Time.
Hope this help you in your fight : )
St. Harris
ASKER
Thank you all for all the rsponses.
I'll try them all althogh most of them I have already tried before.
The pnly thing I haven't tried yet was the Fixup thing.
Please let me know if you have more suggestions.
Orp.
I'll try them all althogh most of them I have already tried before.
The pnly thing I haven't tried yet was the Fixup thing.
Please let me know if you have more suggestions.
Orp.
Did you check the log for messages or errors ?
Did some user do something each time the server crashes ?
If you want I can give you some links to Tech docs about this error, but here are very widespread.