Maybe it´s better to install Win 8.1 directly? Since it must have the most updated drivers or no?

Thanks for your tips and usual help.

If you do that, STILL make sure it puts proper Intel(R) chipset drivers ;)

[Edit:] Oh, SATA/RAID controller driver too...

on top of previous example from my mobo:

[Example Only] Here's the ones I had to force update here ( all Intel(R) devices ) :
- G33/G31/P35/P31 Express Chipset PCI express root port
- G33/G31/P35/P31 Express Chipset Processor to I/O controller
- ICH9 Family PCI express root port, 1, 5 & 6 (3 devices)
- SMBus Controller
- LPC Interface Controller
- Lots of Intel(R) USB Universal Host COntrollers

---

"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.

If it has the same instalation bug then forget the Win 8.1 for now.

There is no other easy way to do that? Some kind of automatic general intel driver update program? Remember if that is the problem, i will need to do that on several hosts... and not all uses the same MB.

---

If it has the same instalation bug then forget the Win 8.1 for now.

There is no other easy way to do that? Some kind of automatic general intel driver update program? Remember if that is the problem, i will need to do that on several hosts... and not all uses the same MB.

The auto installer will tend to only add the inf, and even the web detection thing say older drivers there are 'valid'. The logic with that is possibly along the lines of if the system is booting/running already, then make no automatic assumptions that could make the situation worse. i.e. update those if you know you need them.

Another possibility is that with such chipsets being so ubiquitous in many small variations, they (Intel) made a quality control nightmare for themselves, and have to limit potential spread of accident or misadventure.

The general situation is that many hosts may never need these looked at, and for the bulk of chipsets that predate the OS release, the MS ones would be fine.

I'd argue that special/unusual circumstances exist in gaming/enthusiast and other circles, such as yours for crunching with multiple GPUs, that warrant the extra attention, and push resources closer to limits at every level.

Probably you could compare the situation to something like a factory car can do just fine in a cross country race with much of the same original componentry, but you will want to toss a lot of extra weight, tweak a bit, and reflash the computer in it with something better than a Generic Microsoft fuel curve from 10 years ago.

---

"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.

Ok will do that manualy host by host, but sure not now to much alcohol in my system.

---

I'm not sure whether that's the same problem or not. It looks as if the program reached the normal completion point, but couldn't close down properly for some reason. So, it started again, and crashed on the restart.

Still, lots of lovely debug information logged, so I'll save that for Jason - looks like the replacement wingmate is a very fast host, so it may disappear too soon.

Got one last evening similar to Juan's, on a stock cuda42 task, 3453302106, if you you want to grab the debugging info before it vanishes.

Based on the timing, I think I caused this one myself, by shutting down and restarting BOINC several times while testing a theory related to the "Zombie" AP tasks that started this thread in the first place. (I'll probably post more on that theory in a separate thread when I can.) It seems as if BOINC actually shuts down before the applications do, and this task must have managed to "finish" after BOINC was already terminated. It then restarted at 86.16% but with the "finish file" already present.

I'm not sure whether that's the same problem or not. It looks as if the program reached the normal completion point, but couldn't close down properly for some reason. So, it started again, and crashed on the restart.

Still, lots of lovely debug information logged, so I'll save that for Jason - looks like the replacement wingmate is a very fast host, so it may disappear too soon.

Got one last evening similar to Juan's, on a stock cuda42 task, 3453302106, if you you want to grab the debugging info before it vanishes.

Based on the timing, I think I caused this one myself, by shutting down and restarting BOINC several times while testing a theory related to the "Zombie" AP tasks that started this thread in the first place. (I'll probably post more on that theory in a separate thread when I can.) It seems as if BOINC actually shuts down before the applications do, and this task must have managed to "finish" after BOINC was already terminated. It then restarted at 86.16% but with the "finish file" already present.

Yeah, Boinc client likes to aggressively terminate the processes if it doesn't hear what it wants to hear in fixed time periods (i.e. That's correct termination if the client killed the app, aborting the task.).

Unfortunately that means rapidly starting/stopping can induce modes of failure totally outside of the scope of the application or boincapi embedded in it. This case is solely in the Boinc client's court (complete with some design issues).

That's especially likely when we're talking multiple tasks being asked to shut down while having been still ramping up. That's simply because the system will be under high contention (loading from disk etc), and possibly not yet even reached main code where it can listen for exit requests.

That's where Boinc has some issues with 'thread-safety', and fixed assumptions about time, that really don't apply except on 'Real-Time' operating systems like those used in car computers.

---

"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.

Could be related or no, but this is not the first time one WU end on this error:

ERROR: both checkpoint files are damaged, aborting task

In this WU: http://setiathome.berkeley.edu/result.php?resultid=3461617408

Nothing apparently is wrong with the host, HDD allready checked, no error.
Before and after that the hosts crunch a lot more WU with no error.

Any clues?

---