how many were still in buffer at point of the invalid result? I don't know, but there are 28 right now.
Was the invalid immediate or ...? I don't know. I only found the problem when I did one of my sporadic checks for invalid/error results about 12 hrs later.
Before posting the above, I examined only results with sent times after the return time of the invalid result. I have just re-checked about 1 in 3 of all Autodock results for the device since the error WU was sent, and the only ones with a quorum of 2 are repair units (names end in 1) and the 3 Inconclusives (out of 81 results).
In case it's useful, I just uploaded the entire results summary list (not individual result pages) to http://www.2shared.com/file/6764188/92df305f/Tasks_9650A_090720.htm .
I think the WCG system has missed sending me to the sin bin in this case.

@Didactylos: Thanks for the tip re pastebins - I didn't know they existed. 2shared seems OK, but I've only used it a couple of times.

To readers who are wondering what that is about: I wanted to make an 80-line text file available here, but without wasting everyone's bandwidth to download it from WCG plus their time to scroll past it in the forum thread. So, I uploaded it to a website where it is publicly accessible, and included a link in my post. Only people who want it need download it. [Hint]

Point taken re the "_1" WUs not all being repair units. Anyway, there were only 2 for the results from single-redundancy projects ... my work cache plus micromanaging CEP WUs to run 1 at a time seems to be keeping me just outside Fast Returner status.
I wondered whether the system might have sent out 2nd copies of WUs that were still In Progress when the invalid result was returned, but there is no sign of that in the earlier results that are still accessible. Some of them would still be waiting for the wingmen anyway.
[Edit]: Checking all of the next 16 Autodock WUs sent immediately after the bad one was returned, I found 2 with names ending in "_0" and a quorum of 2. Not 15, and within normal check-WU proportions I think.
I can't figure it out, so over to you guys.

I don't know how to find validation times, but I have gone through all current results pages for the device, doing on each page: (1) Sort on Return Time, (2) Copy list and paste into a text file, (3) Examine every result, and put an extra entry on the end of the result line in my file, denoting the quorum size - Q1 = 1, Q2 = 2, etc.
Edited my file to make it a bit more readable, replacing space-tab column separators with " | ", deleting device name (all the same), etc.
Uploaded it to http://pastebin.ca/1501511 with expiry in 1 year.
HTH - Rick

Thanks for taking the time to look into this, Sek. One thing that I hadn't thought about is the question of what specifically went wrong inside wcg_dddt_autodock_6.07_windows_intelx86 when the problem occurred, and why it continued executing to give an invalid result instead of aborting, and whether this behaviour could be fixed.
Maybe I could repeat the circumstances ... 4 cores, 1GB RAM, limited pagefile space on the HDD, about 4 tasks suspended in memory (maybe I was trying for a 5th ) just when BOINC started reporting & downloading more data, and then I tried to get BOINC Manager to swap in so I could see what was going on ...

Yeah, the project mix ... I think it's good on a multi-core, especially an Intel LGA775 quad, to run a mix of projects, preferably with 1 or 2 that have high memory cache success rates, so there's less crowding on the memory bus. On my AMD, which has only 512kb cache/core, Perfmonitor shows that FAAH, HCC and rice(?) get lots of cache misses, while CEP and HCMD2 do not. So I tried some CEP and HCMD2 on the Intels. It turns out that neither HCMD2 or CEP score good Points Awarded on the Intels. Autodock jobs score best, possibly because the 3MB cache/core is higher than the fleet average, and I think I'll revert to running only/mostly those on the Intels.
On the other hand, the AMD likes HCMD2 and CEP, which have high cache success rates, and Points Awarded for these seem to be only about 20% behind the Intels, clock for clock.
[Edit] - Forgot to add: I hope the CHARMM page-faulting problem gets fixed before DDDT-2 gets under way. If not, I might run it on 1 core of the AMD, but not on the Intel quads. Sorry, but I figure that running my devices on projects that maximise the points they score maximises my contribution to WCG. I'm doing some 'flu jobs for you though, Stan.