Hi there,what could be the possible reasons for a server to crash with
“PANIC: LookupHandle: handle out of range”
when calling a document’s save-method?
There’s an agent running which calls a function from a library. It passes a NotesDocument-object. Accessing this doc works (I’m logging some fields), but as soon I’m calling doc.save(true, false), the server crashes…
Any help will be greatly appreciated!
TIA,
Buzzy
Subject: Things we tried
We already tried the folling
compact -c -i
updall -X -R
fixup
and created a new replica.
Still, the server crashes 
Subject: Can you post the fatal thread
Hi,
Can you post the fatal thread like this example:
JYR
Subject: Here we go…
############################################################### thread 1/3: [ nAMgr: 1218: 0b28] FATAL THREAD (Panic)
############################################################
[ 1] 0x7c82860c ntdll.KiFastSystemCallRet+0 (4f0,493e0,0,12c46c)
[ 2] 0x77e61c8d kernel32.WaitForSingleObject+18 (4f0,493e0,1,12c688)
@[ 3] 0x601a8d34 nnotes.OSRunExternalScript@8+1300 (12c,1)
@[ 4] 0x601a91ca nnotes.FRTerminateWindowsResources+986 (1,0,1010,1)
@[ 5] 0x601a958f nnotes.OSFaultCleanupExt@24+895 (b34dd8,1010,0,0,0,12c9b8)
@[ 6] 0x601a961a nnotes.OSFaultCleanup@12+26 (0,1010,0)
@[ 7] 0x601b4b34 nnotes.OSNTUnhandledExceptionFilter@4+276 (12d9f0)
@[ 8] 0x60179bf8 nnotes.Panic@4+520 (60bc0aff)
@[ 9] 0x60002a9c nnotes.LockHandle@12+252 (45313630,12da20,12da2c)
@[10] 0x60002906 nnotes.OSLockObject@4+22 (60f00480)
@[11] 0x600113da nnotes.NSFItemQuery@40+138 (1f,1f,151d1500,0,0,12da3c,f10f10,ffffffff,0,0)
@[12] 0x602cd199 nnotes.CMimeHeader::PutToItem+361 (0,12e078,1a630000,11074a4)
@[13] 0x602c1a5e nnotes.CMimeDirectory::Itemize+702 (0,0,113a578,113a710)
@[14] 0x632329ca nlsxbe.ANNote::ANNFlushMIMEDirectories+266 (151c2f84,0,113a578,0)
@[15] 0x6323a3ac nlsxbe.ANNote::ANNUpdateNoteExt+172 (6335ffff,120000,1,0)
@[16] 0x6323ab42 nlsxbe.ANNote::ANNUpdateNote+114 (6335ffff,120000,0,1)
@[17] 0x6323b2a1 nlsxbe.ANNote::ANNUpdateNote+49 (12e874,11377b0,113a578,12e874)
@[18] 0x632065e7 nlsxbe.ANNote::ANDispatchMethod+119 (12e874,12e844,164072b4,12e874)
@[19] 0x63203556 nlsxbe.ANCLASSCONTROL@16+2086 (399b08,109,12e828,12e874)
@[20] 0x63203879 nlsxbe._tag_NotesADTControl::ClassControl+25 (113a5a4,399b08,109,12e828)
@[21] 0x6004f76d nnotes.LSsInstance::AdtCallBack+269 (399b08,63202d30,109,16407298)
@[22] 0x600664fd nnotes.LScObjCli::ProdMethodCall+61 (16407258,494,1639595c,10004)
@[23] 0x60066402 nnotes.LSsThread::AdtDoProdCallout+162 (1641f2e0,16407258,10004,16395910)
@[24] 0x6006631d nnotes.LSsThread::AdtCallMethod+45 (5,163968c0,1,2)
@[25] 0x60021ac6 nnotes.LSsThread::NRun+5926 (1641f2e0,0,151cc694,0)
@[26] 0x60022236 nnotes.LSsThread::Run+182 (1641f2e0,12e9b4,60ae0746,399b08)
@[27] 0x600a879d nnotes.LSsInstance::Resume+29 (399b08,151cc694,12e9e0,60ae03f8)
@[28] 0x60ae0746 nnotes.LSIThread::Run+86 (151cc694,258,1,151cc694)
@[29] 0x60ae03f8 nnotes.LSIThread::RunInternal+72 (120002,258,4c23cc,c12576b1)
@[30] 0x60ae066c nnotes.LSIThread::RunToCompletion+332 (151cc694,258,1,151acbd4)
@[31] 0x60adbeef nnotes.CLSIDocument::RunScript+639 (151b9b94,2a,1,60bbe9b9)
@[32] 0x605f8675 nnotes.CRawActionLotusScript::Run+565 (2bf5,15199d94,0,12ee2c)
@[33] 0x605f4b6a nnotes.CRawAction::Run+58 (0,12f924,0,12ee58)
@[34] 0x605f577d nnotes.CRawAction::Execute+221 (151acaf4,0,12f62c,605f2b16)
@[35] 0x605edad6 nnotes.CAssistant::RunAlone+22 (151ad814,12f924,151b1914,151ad814)
@[36] 0x605f2b16 nnotes.CAssistant::Run+3590 (151ad814,12f9a4,12fb70,12fb68)
@[37] 0x631343e3 namgrdll.RunTask@32+2051 (1,5aa,0,0,0,12f9f0,f10f10,ffffffff)
@[38] 0x6313470f namgrdll.ProcessRunMessage@4+63 (12fb68)
@[39] 0x63134791 namgrdll.ProcessMessage@4+33 (12fb68)
@[40] 0x63134955 namgrdll.ExecutiveMain@4+261 (0)
@[41] 0x63139695 namgrdll.AddInMain@12+309 (400000,3,396fbc)
@[42] 0x0040102f nAMgr.NotesMain@8+47 (3,400000)
@[43] 0x00401164 nAMgr.notes_main+212 (0,0,0,3)
@[44] 0x00401056 nAMgr.main+22 (3,3350a0,332a58,403000)
@[45] 0x0040133d nAMgr.mainCRTStartup+323 (0,0,7ffdf000,0)
[46] 0x77e6f23b kernel32.ProcessIdToSessionId+521 (4011fa,0,78746341,20)
Subject: Agent accessing MIMEEntity crashes when Save method is called for the document object
Technote 1170695
Solution
The issue was reported to Quality Engineering as SPR# LVAE5ZEMU2; however, there are no plans to address it.
This issue occurs when the Save method is called before the CloseMIMEEntities method (of the NotesDocument class) has been called.
To avoid the issue, ensure that the CloseMIMEEntities method is called prior to the Save method.
JYR
Subject: Didn’t help…
…but thanks.Our last guess is that one field contains too much Characters to be processed as a standard RFC822-field (65 characters including a “/”)…don’t know, if this is the cause
Thanks,
Buzzy