I have been fighting a similar/same problem. It started last month unexpectedly without any OS/Java ugrades or any new applications. I also use Tomcat as standalone.
I was running TC 4.0.31 on Win2k SP4 on a dual processor PowerEdge 1650. Looking at the Event Viewer logs I was getting Access Violations to a specific memory address so I thought it was hardware related either disk drive or RAM. But then I began running TC from the console and realized that something was being written to the console upon crashing but not being recorded in the stdout.log. When you run from TC from the console and the VM crashes these error message get written to a hs_err_pidXXX file in the %CATALINA_HOME%/bin directory if that is where you have run the startup.sh/bat file. hs_err file was showing an ACCESS VIOLATION but was pointing not to a memory location but to hook.dll and kernel32.dll, consistently. I began to look elsewhere and found that the error was being created from what seemed to be thread starvation. The main thread was unable to spawn child threads and as they were terminated. I am no expert at reading thread states and stack dumps from hs_err but running Xrunhprof seemed to confirm that there was a problem spawning new threads after the service had started. I haven't been able to figure out why but I have saved all my hs_err files, hprof files and other records if anyone is interested. To simplifiy things to try and track the problem I set the Affinity of the tomcat process to just one of the CPUs and the problem went away. I can't tell you the reason why but if I startup TC normally on both CPUs in less than 24hours and sometimes in just a few hours, guaranteed, the TC will either terminate or become unserviceable (Event Veiwer - Application Popup). So now I am running off a single CPU (still less than 20%) and can do so without any problem or errors. I also have moved up to TC 5.0.28 and modified the Xss in tomcat.exe setting to 256k as described in this email: http://66.102.7.104/search?q=cache:aMp-NgH130oJ:forum.java.sun.com/thread.jspa%3FthreadID%3D418834%26messageID%3D3758510+command+line+procrun+tomcat+5.0.28+Xmx&hl=en&gl=us&ct=clnk&cd=1&client=firefox-a If you run 5.0.28 as a service (and who doesn't) you will find that you will need to replace the jmx.jar with a current version of mx4j so that you do not get exceptions if you have not edited out the JMX support in your server.xml file. Failure to do one or the other will mean that you have less than a 50/50 chance of being able to use the Service Manager restart facility because when it tries to restart more times than not TC will fail with a ConcurrentModificationException with the current jmx.jar. After doing all this I began to get Out Of Memory errors and noticed that in the Task Manager that the my peak memory was topping out at 137MB even though I had specified in the service.bat that the --JvmMs and --JvmMx were to be 512MB. So apparently those setting weren't being picked up and putting the options directly into --JvmOptions would crash the server on startup. The ONLY way I have found to get the Daemon Procrun to work correctly is to use the Prunmgr.exe to manually set the service. After digging about quite a bit I found out that the TC maintainers had relabeled Prunmgr.exe to tomcat5w.exe. Launching tomcat5w.exe from the commandline with //MS// [service name] and I was able to set the Xms, Xmx and Xmn settings and confirmed in the Task Manager. I still have not been able to debug why I can't get Xloggc:C:\tomcatgc_log.txt to work though. I hope this helps you out. There are a number of problems with Tomcat at least on Windows. have fun! Steven
