I think it makes a lot of sense. I haven't tried to make the app multithreaded. Is it possible the COM components I use create additional threads? The errors don't always occur when COM controls are in use, so I don't think it's entirely to blame. In what other ways could I be starting additional threads? IO? If Scripting.FileSystemObject and Debug.WriteLine aren't thread safe, this alone could explain most of this.

Hi, Sean

if your "good" machine is single-processor, you might have threading issues,
which are surfacing on dual-processor machine. Especially if you have
interop. Some Win32 APIs are not threadable. Same for some Net methods and
classes.
If other applications do run there fine - blame your app first.

HTH
Alex

[quoted text, click to view]
taking place on two separate machines. On one machine the automation suite
completes 100% of the time. The other machine is a beefier dual proc
machine. On this machine the program sponaneously quits, throws memory
could not be read errors, and sometimes system.ExecutionEngineExceptions.
Sometimes it takes 3 hours of testing before the script fails, other times
it's right away. Release and Debug versions don't seem to make any
difference. I don't think this is a code issue, as it is not reproducible
and runs fine on the other machine. The system.ExecutionEngineException
errors were in an interop dll. Could I have bad hardware? Memory? I've
reinstalled the .Net framework, thinking something could be mismatched in
version. Are there any JIT issues that might come into play with a dual
processor?