Okay, so the line was life, the image file of a HCC task was deleted, the listing of the task stayed in the client and this is what happened with a few extra log flags active from finishing a previous task through the crash of the 1155 job till the next good task launching:

09/10/2009 16:16:41	World Community Grid	Computation for task R00398_76090d67ec71f416354fcab23ba0c205_02_0 finished
09/10/2009 16:16:42	World Community Grid	[dcf] DCF: 3.079506->2.901685, raw_ratio 1.301295, adj_ratio 0.422566
09/10/2009 16:16:42	World Community Grid	Starting X0000084060631200703061155_0
09/10/2009 16:16:42	World Community Grid	[cpu_sched] Starting X0000084060631200703061155_0 (initial)
09/10/2009 16:16:42	World Community Grid	Starting task X0000084060631200703061155_0 using hcc1 version 606
09/10/2009 16:16:43	World Community Grid	[sched_op_debug] Deferring communication for 1 min 0 sec
09/10/2009 16:16:43	World Community Grid	[sched_op_debug] Reason: Unrecoverable error for result X0000084060631200703061155_0 ( - exit code -529697949 (0xe06d7363))
09/10/2009 16:16:43	World Community Grid	Computation for task X0000084060631200703061155_0 finished
09/10/2009 16:16:43	World Community Grid	Output file X0000084060631200703061155_0_0 for task X0000084060631200703061155_0 absent
09/10/2009 16:16:43	World Community Grid	Starting X0000084060725200703061154_0

Can't tell if this is not according expectation. The Result log

Result Name: X0000084060631200703061155_ 0--
<core_client_version>6.10.13</core_client_version>
<![CDATA[
<message>
- exit code -529697949 (0xe06d7363)
</message>
<stderr_txt>
Unrecognized XML in parse_init_data_file: hostid
Skipping: 849476
Skipping: /hostid
Unrecognized XML in parse_init_data_file: starting_elapsed_time
Skipping: 0.000000
Skipping: /starting_elapsed_time
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1255680360.000000
Skipping: /computation_deadline


Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Out Of Memory (C++ Exception) (0xe06d7363) at address 0x774942EB

Engaging BOINC Windows Runtime Debugger...

What's interesting is that the error was reported several times before, so now know by simulation what one of the causes is ;>)

i have had problems with norton killing BOINC tasks..

it happend in the past for Pirates@home. and it has happend to me for a few others as well as i lost some work units for WCG in the past do to norton killing them.

no clue why it happens but is has been happening for years now and then you will find a new set of work units being called or flaged as "autodock" mabey the people at WCG or Boinc or Norton should figure why this happens

I havent gotten any beta's this round so i dont know if my version will do it or not

A project reset should remove all files in the project, so they shouldn't be re-downloaded, but older clients will continue downloading all files waiting to be downloaded at time of reset...


In any case, BOINC checks on startup if any missing files, and any missing files is tried re-downloaded. It doesn't matter if it's an application-file, a wu, or one of the small picture-files for the simple gui, all will be tried re-downloaded. (*)

If a file is missing when a task should start running, this task will error-out. This is the same if file was missing on client-start and haven't finished re-downloading, or file has been deleted after client started. In case all files a task uses has re-downloaded before it's this tasks time to start, there's no problem.

All files is verified to be correct on download, but not normally on application-start. To verify files on application-start, project must enable <verify_files_on_app_start>. Most projects, including WCG, for some reason doesn't use this option, meaning a corrupt file won't be replaced... Failing to verify files is especially bad in case it's the application-file(s) that's been corrupted...

For the few projects that does verify the files, a corrupt file will error-out the task then tries to run. Also, if user really desires, he can disable file-verifying on application-start, even for the few projects that uses this option.


(*) There'll likely be a client-change soon, so missing files isn't re-downloaded if they're not currently needed, example missing application-files doesn't really need to be re-downloaded if no task currently on client that uses this application.

Suggest you just kill them. You're more likely to cause issues. This beta version has expired anyhow. The next having an incremental number, I hope so ;>)

Thanks again!

I just hope that I have followed the advice given here to tell Norton to stay away from BOINC folders so that this doesn't happen again in the future.

The final part of my initial post wasn't answered. Will the fact that all my machines returned 'errors' because of what Norton did, will they no longer be counted as being reliable and therefore not be given beta WUs in the near future (if any were to be actually sent?