Hallo,
bei den letzten Server Crashes hat mir folgendes Dokument geholfen (aus dem Domino-Forum auf notes.net)
---------------------
Yes, they do contain a lot of information because it's a collection of all known facts at the time of the crash. However, I can give you the simplest scenarios which might help you to be proactive.
The actual crash will generate a callstack in the nsd log. On Windows look for "FATAL THREAD" and on Unix look for "fatal_error". Once you have found that look at the function stack which follows immediately. This usually gives you a clue about what was going on at the time of the problem. Consider first which process crashed. Was it amgr? Then look for an agent. http? server? (by the way, the 'n' in nserver indicates that this is an Intel executable). Then, when you look at the call stack try to figure out what the function names might indicate. NIFUpdateCollection, for example, indicates that a view was being updated. Familiarity with the C API can certainly help here. This is the single most important piece of information in the NSD log file.
Another very helpful piece of information is to know what databases were open by the thread that crashed. That way, if you are trying to locate a bad database you might be able to narrow it down. To do this you will need 3 pieces of info from the NSD log. First is the id of the thread that crashed.
############################################################
### FATAL THREAD 5/64 [ nserver:03cc: 1696]
### FP=0x0314fbc0, PC=0x1001f725, SP=0x0314e9e0, stksize=4576
### EAX=0x00000001, EBX=0x00000000, ECX=0xffffffff, EDX=0x00000000
### ESI=0x00000000, EDI=0x00000000, CS=0x0000001b, SS=0x00000023
### DS=0x00000023, ES=0x00000023, FS=0x00000038, GS=0x00000000 Flags=0x00010202
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
@[ 1] 0x1001f725 nserverl._PerformCommand@8+11669 (d3390002,5d8c0001,2,20205)
@[ 2] 0x1001abd0 nserverl._ConsoleProgram@8+1072 (d3390002,5d8c0001,10006,1010004)
@[ 3] 0x10001adf nserverl._Scheduler@4+1295 (0,80430d77,0,100015d0)
@[ 4] 0x6000fd46 nnotes._ThreadWrapper@4+342 (0,0,0,0)
[ 5] 0x77e8758a KERNEL32.SetFilePointer+394 (6000fbf0,0,0,dddd04d2)
In this example the process id is 03cc and the thread id is 1696 (this is a simulated crash performing a server console command)
1696 is a physical thread, but you need the corresponding virtual thread, so go to the table for process 03cc
------ TLS Mapping -----
NativeTID VirtualTID PrimalTID
[ nserver:03cc: 1192] [ nserver:03cc: 2] [ nserver:03cc: 2]
[ nserver:03cc: 1632] [ nserver:03cc: 4] [ nserver:03cc: 4]
[ nserver:03cc: 2180] [ nserver:03cc: 5] [ nserver:03cc: 5]
[ nserver:03cc: 296] [ nserver:03cc: 6] [ nserver:03cc: 6]
[ nserver:03cc: 1696] [ nserver:03cc: 7] [ nserver:03cc: 7]
and you find that the virtual thread is 7. Finally, go to the open database table
------ Open Databases -------
C:\R6devel\Domino\Data\names.nsf
Version = 43.0
SizeLimit = 0, WarningThreshold = 0
ReplicaID = 80256be1:00545e95
bContQueue = NSFPool [ 0: 412]
FDGHandle = 0xf0190048, RefCnt = 51, Dirty = N
DB Sem = (FRWSEM:0x0244) state=0, waiters=0, refcnt=0, nlrdrs=0 Writer=[]
SemContQueue ( RWSEM:#0:0x029d) rdcnt=-1, refcnt=0 Writer=[] n=0, wcnt=-1, Users=-1, Owner=[]
By: [ nserver:03cc: 7] DBH= 6, User=
and you see that this thread had names.nsf open at the time of the crash.
Thema: NSD Analyse: Gibt es irgendwo ne Doku? (Gelesen 4009 mal)