Not such a mystery if you think about the opposite case, whereby Boincapi kills science applications without prejudice. 

Exactly.  It's just like the science app has a wife:

" Do this"

"Don't Do that"

"You don't own me!"

"Give me your Credit Card, I'm Going Shopping"

Personally, I'm waiting on Richard's Boinc-Lite edition, which apparently comes with its own gag.

A new version of the rescheduler which now also works on the win/64 platform. If you are running this platform *please* make a backup copy first just in case it is not working as expected. Also there are additional settings so please check the configuration (via the tabsheets) as it needs your boinc bin and data path.

Greetings,
Marius

-Running units are now excluded from the rescheduling (better because the
slot info wasn't changed). Because of the changed deadlines it is still
possible that boinc starts other tasks while the previous running tasks
are marked as waiting.
-The platform is now also changed while rescheduling (sorry about any
inconvenience if this has caused problems)
-Because of changed locking there are two new settings for binaries and
datapath. (There is no need to copy reschedule to the datapath anymore)
-If boinc is not installed as a service it will do a "boinccmd.exe --quit"
and after the reschedule a "boinc.exe -detach". This should solve the
problems on any system where boinc is not installed as a service (win/64).
-Changed the locking scheme (it is no longer locking the stderrdae.txt to
test if boinc is running).
-Solved some problems in the test algorithm for the automatic reschedule.

No, the command is "boinccmd.exe --quit" not "boinc.exe -quit" or are we talking about the same? Have you experienced this before and what are the circumstances that happened?

if you refer to boinc.exe not exiting immediately, i have that covered by checking if the process has exited. Has been running well for the last couple of days.

Greetings,
Marius

Please forgive me if I'm being dense. I'm an engineer, not  a programmer, but I can (usually) figure things out  I have been using the various Marius versions (currently 1.8 ), but I have noticed an interesting (to me) thing.

I normally run Marius in the "find VLAR/VHAR" mode. In the last day that was almost all of them...sigh. Because a 100 of these puppies waiting for the CPU was a bit excessive, I went for the 75% to GPU option (as an experiment) without the VLAR/VHAR option (but after running VLAR/VHAR).

I got the requested mix, but Marius 1.8 didn't show the change (bug, or perhaps something no one would want?). BOINC showed the change after starting. I manually stop and start BONIC  because I don't trust the script (sorry).  Anyway, most of the changed VLAR/VHAR (back to the GPU) tasks (previously tagged as CPU) ran fine within normal (wall clock) times.

Three died in Varkill. I can't help but wonder why the others didn't. OK, I understand that Marius has different parameters. Perhaps they are too strict or am I missing something?

My computer is a Q6600 with 8600GTS video card running on Vista.

No big deal, but I kind of wonder why I can process tasks on the GPU that Marius says are poison

I'm a programmer in real live, not a astronomer or engineer and seti is just one of my many bad habits..

If you show the interesting part of your log we can figure out exactly what happened. The tool always pushes V*AR to the CPU just like Raistmer scripts does (bit depending if you checked the True Angle Rate) and additionally it tries to make the proper distribution which is not always possible if you have many V*AR.

I have no idea why VLARKILL occurred even after a reschedule. I think Raistmer can answer this one better then me. However i noticed a couple of vlarrkils on my account also while using the tool, but nearly not as much as it used to be (before that complete series went down the drain).

Greetings,
Marius

Thanks for the update Marius.