Probabily an stupid sugestion, so forgive me if its that the case.

What could happening if for any reason the host when is doing the final stage who i belive is doing in with the below normal priority (within the 10 secs) and for a hell of a coincidence was interrupted by an exclusive only app or a high priority task who takes to finish more time and returns to the final stage task after the 10 secs? That could tigger the error? If that could happening that could be the source of the problem and why it is very rare. In this case the boinc code must be fixed to avoid that.

Pretty much. That it is not more frequent & common on many systems points to both coincidence and a deeper logic flaw, rather than a 'bug' outright. The inconsistency in the clock change handling against the last finished file checked timer setting reindorces the logic flaw issue, even ignoring that aborting a successfully completed task is obviously a bad idea.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I've got some interesting research to do on http://www.gpugrid.net/result.php?resultid=7744831.

Well, the coffee has kicked in now. In this particular case, clock changes are exonerated: that happened, if at all, at 01:00 (and I think it failed to connect to the NTP server).

But BOINC was extremely busy.

05:47:38 Einstein finished a task, started upload
05:47:39 SETI reported a task, and requested new work
05:47:40 SETI finished a task, started upload
05:47:42 SETI was allocated new work, preparing to download
05:47:42 GPUGrid called boinc_finish

05:47:44 Windows reported that the shell had stopped unexpectedly and explorer.exe was restarted.

The process tree (then as now) was

Winlogon starts explorer.exe
Explorer starts boincmgr.exe
Boincmgr.exe starts boinc.exe

So if explorer stops, the whole pack of cards falls over. Anyone know why calling boinc_finish while all that I/O is going on could cause explorer to crash?

So if explorer stops, the whole pack of cards falls over. Anyone know why calling boinc_finish while all that I/O is going on could cause explorer to crash?

Possibilities range from cosmic ray strikes through to Global DLL data corruption via the Microsoft C-Runtimes, induced by wanton use of TerminateProcess() in Boinc (and standard boincapi) code.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

LOL. Could be an ET interference?

What it´s clear, killing a allready crunched WU (who takes hours to crunch) seems like a waste of resources and sure not a good programing practice. The rest is with the devs.

---

Perhaps.........................
You may never know of interference from me!

---

Boinc....Boinc....Boinc....Boinc....