Benu wrote:

Martin <ml_news@ddnospamddml1dd.co.uk.dd> wrote in message news:<L2Bwc.23$Tp4.12@newsfe6-gui.server.ntli.net>...

[...]

Try memtest86 to check out the RAM, and the GIMPS torture test to check out the CPU & RAM.

Silicon runs better the cooler it is.

Good luck,
Martin

I posted the "Setiqueue Blues" message, the computer internals are
clean, yet the problems that I conveyed still exists. I strongly feel
that the problems that I am experiencing with seti driver and
setiqueue are somehow a setiqueue software/network related problem.

[...]

Presently, the only configurations that work within my home network
are: (1) PC A with seti driver using PC B's setiqueue and PC B with
seti driver using PC A's setiqueue or (2) PC A & B seti drivers
uploading to a public Setiqueue host.

Setiqueue will simply not correctly serve a local seti driver client
on the same machine, it will receive the result, attempts to download
a wu, records the wu in the pending queue and then lockup the machine
during the download to the seti driver client and kill all tcp/ip
processes. There are no error messages generated in the Win2K system
event logs and there is no indication within setiqueue logs about a
problem with all of the debug options set.

The only way to resolve this is to reboot the machine. I truly do not
understand why a stable environment suddenly behaves this way. If
anyone has an answer, please share your advice.

Strange indeed. You should not be able to crash the OS in that way!

Have you got any high process priorities set anywhere?
Local firewall correctly configured?
IP addresses/ DHCP/ host names/ protocols set appropriately?
Any antivirus stuff active?!! (Can cause much 'unexpectedness'.)

If Memtest86, GIMPS torture test, and a thorough disk scan/ check all pass ok, then I don't know. ...Try linux? (;-))


Good luck,
Martin