Hello everybody, best wishes to all Boinc people!!!

I have spent some time on this before reporting, just to check what happens with successive new clients versions (I'm currently using 6.5.0 for Windows x86_64). As far as I can trace it, this seems to happen since versions 6.2.x and particularly 6.4.x.

This happens on Phenom Quad Core under Windows XP64 with Boinc 6.5.0, which is always on. This doesn't seem related to a x86 or x86_64 project.

It seems that when a process hangs into compute error, it is not (always?) able to die elegantly! It is well indicated that there's a "compute error" in the Boinc's task list, but the process stays in the Windows process list. I don't know if there's an automatic mechanism in Boinc's scheduler to detect dead processes. If yes, it doesn't work well!

Even if I ask for an update of the project which is in "compute error". The reporting works well, but the process in error isn't killed.

Of course, my preferences specify that Boinc SHOULD NOT "leave applications in memory while suspended".

These "ghost processes", which stay in task manager process list (Windows), are well identified as boinc_project processes; they are well sons of the boinc_master process. They use just a few kilo-octets of RAM, but they don't run at all (0% activity).

After a while (a week of 24/24 activity), when there is 4 to 6 ghost processes, one or two cores aren't computing anymore (on Windows, 75% or 50% global CPU activity).

To purge the ghost processes, I'm forced to stop and restart the Boinc's service. When I do so, all ghost processes are detached from father boinc_master. Once detached, you have to kill them one by one in the task manager. (I'm using BoincView and SysInternals Process Explorer to monitor this, the process parenting is graphicaly explicit.)

As multiple projects behave like this (MilkyWay, Spinhenge, Minirosetta, Aqua, etc), I can't conclude that this is only a matter of coding at project's side. Perhaps the new Boinc's scheduler (since 6.2.x for me) has something to do with this on multi-core's machines. I never remark anything like this with the very stable 5.10.45.

Could you check that?

If this is a matter of correctly setting preferences on multi-core machines, I'll be glad to have explanations of what to do and why.

Best regards