After 4% and 2hrs both WUs use 216MB with 805MB VM. During checkpointing, the max used RAM value jumped from 218MB to 221MB. Maybe this rise is the crucial point for my computer since the error occurred always with percentage .960%.
I made a new backup. When restarting both WUs had 209MB RAM and 805MB VM, but RAM moved soon to 213MB before the percentage was raised at all.
BTW the computer is an intel i7 920 with 6GB RAM, HT active. VM is set to max 6434. The latest error occurred while running both remaining DDDT2 WUs along with 4 HCMD2 WUs and 2 HFCC WUs.
And concerning backups - if I wrote 'stop boinc' I meant stopping all programs/services/etc. of boinc, not only the boinc manager. And as I wrote in my first posting restoring the WU comprises the slot directory, the client state file (active_tasks, file error codes, result section) and the changed project file(s). CPDN has some extensive manuals how to achieve it. And if checkpointing works as it should you can restore ANY WU from backup if you know what you are doing. Of course power failures during checkpoint writing are another topic - that way I had some HFCC WUs which restarted at 0% after 80% done with active time remaining unchanged getting the usual credit for twice the time...

dkt, the tasks are not finished yet - actually at 68% and 92%, but beyond all other copies of that WUs which had errors. It's just a theory which I try to support or refute.
And suspending/resuming isn't sufficient as long as you have the leave_apps_in_memory option active (didn't test whether it works without this option). For backups all boinc services must be stopped to avoid lock file conflicts.

Thanks for the explanation of how you resurrect dead WUs, Mathias (aka mweisensee). Very clever. Can you do it for humans, too?
However, before "everybody" starts doing this, I think we should hear the opinion of the scientists. It is possible that it could introduce bias into the results, as I explain in thread Changes to distribution of error work units in my post about Monte Carlo methods in the DDDT2 CHARMM program.

I don't think that "... some of the code 29 errors are caused by extremely ambitious requirements of some (monster) tasks." It is more likely that some parameters are going out of range and causing the equivalent of the simulation bumping into the side of the simulation space. This explanation was given for some problems encountered by the CEP.

How much more RAM is significant?

Here are 3 that I'm currently running that use more than 210MB:
ts05_a048_ps0000_2 - using 211,562K of RAM.
ts05_b494_ps0000_1 - using 215,220K of RAM.
ts05_b426_ps0000_0 - using 216,744K of RAM.
I don't know how much VM.

piroque,

In Task Manager you can add columns for different items measured. In Process Explorer (By MS Sysinternals too), you can right-click for the properties screen and visit the performance tab. There's a Virtual and Physical memory section.

edit: address