I have a Domino server located on a VMWARE session. The Nic driver I am using is a AMD PCNet Family PCI Ethernet v.4.38.0.0 and it is dated 10/1/02. Whenever Domino is started it is functioning for 20mins to 1 hour. After that point clients are unable to connect to the server, “Server not responding”. Logging into the VMWARE session show that the server is up but I am unable to stop the Domino service located in Service.msc. The log.nsf file does not indicate any errors being logged; however, the Domino console displays: Thread=[1190:0002-146C]Stack base=0x000FE7E0, Stack size = 6032 bytes
PANIC: LookupHandle: null handle
In order to stop the service I had to kill each process in task manager. I then ran updall -r, fixup - f -j -v -l, and compact -c -i (only one time) to confirm no databases were corrupt. Unfortunately, this did not resolve my problem. There are two other Domino services running in its own VMWare session without problems. Please advice on a fix.
This is telling you the domino server has crashed. In most cases this required a reboot of th server. However you need to find out what is causing the crash. Check the log to see what the server was doing last before the crash. In most cases its an corrupt database or an agent in a database causing this. Turn on verbose logging on amgr to check if an agent is crashing the server. You may also consider upgrading to a newer version that 7.0.
I upgraded the server to the latest version 7.02 and restarted the Domino service. After 2 hours the system crashed during the crash the console log displayed update information affecting the DC TimeOff database. I then restarted the OS since that was not performed during the upgrade.
Before relaunhing Domino I moved all NSD and console log files to another folder (wanted to have a new set of log files that reflect the time of the upgrade), deleted mail.box, deleted FT folders, and ran updall -r and compact on all databases. It is still compacting all databases, but once complete I will launch Domino and stop all services, one at a time, to see if a NSD file is generated.
The culprit has been identified as an agent. A new copy of the database may need to be implemented since updall, compact, and fixup is not correcting the problem.