This new version will consider failed jobs as successful from a BOINC perspective. This means that the error output will be returned to the MCPlots server for further analysis and they will not be re-run on other hosts.

ask failed and was sent again:
https://lhcathome.cern.ch/lhcathome/result.php?resultid=259207127
195 (0x000000C3) EXIT_CHILD_FAILED
[pre]10:38:30 CET +01:00 2020-01-14: cranky-0.0.29: [INFO] Running Container 'runc'.
10:38:32 CET +01:00 2020-01-14: cranky-0.0.29: [INFO] ===> [runRivet] Tue Jan 14 09:38:30 UTC 2020 [boinc ppbar mb-inelastic 500 - - pythia8 8.301 tune-AU2ct10 100000 14]
10:38:58 CET +01:00 2020-01-14: cranky-0.0.29: [ERROR] Container 'runc' terminated with status code 1.
10:38:59 (83383): cranky exited; CPU time 10.353307
10:38:59 (83383): app exit status: 0xce
10:38:59 (83383): called boinc_finish(195)[/pre]

Thanks. I forgot to updated the native version. Done now.

.
Looks like it works now.
https://lhcathome.cern.ch/lhcathome/result.php?resultid=259228178
https://lhcathome.cern.ch/lhcathome/result.php?resultid=259228031

Output example:
[pre]13:22:14 CET +01:00 2020-01-14: cranky-0.0.30: [INFO] Running Container 'runc'.
13:22:16 CET +01:00 2020-01-14: cranky-0.0.30: [INFO] ===> [runRivet] Tue Jan 14 12:22:15 UTC 2020 [boinc ppbar mb-inelastic 1960 - - pythia8 8.301 tune-2m 100000 14]
13:22:44 CET +01:00 2020-01-14: cranky-0.0.30: [INFO] Container 'runc' finished with status code 1.
13:22:44 CET +01:00 2020-01-14: cranky-0.0.30: [INFO] Preparing output.
13:22:45 (31177): cranky exited; CPU time 10.676736
13:22:45 (31177): called boinc_finish(0)[/pre]

Has anything else been changed in how these communicate between the VM, Boinc and VBox? Starting since versions 300.03/5.19 I have had quite a few powered-off VMs left in VBox on job completion and corresponding ghost images in Virtual Media Manager, all requiring manual deletion.
Just Windows, I think.

Nothing changed in the communications between VBox and BOINC.
I suppose it's due to the high unsuccessful rate of the newly started revision 2363:

Successful: 34661
Unsuccessful: 29649

Thanks. CP
Just thought it strange that both Windows hosts had 5 or more each, undeleted VMs. Since manually deleting all of those, I have not had any others fail to tidy up after themselves on departure so whatever it was has resolved itself.