I feel people are losing track of what's going on here, and what the real issue is! :( Ok laying it all out:
1. This exact hardware ran 32 bit windows until 2 weeks ago, and fairly thumped through the tasks. This included FAAH, it had no issue, and was hammering through them. I ran a lot of FAAH on this machine.
2. I upgraded to Windows 7 Ultimate 64 bit.
3. I noticed that, although I was running the machine lots, indeed 24 hours a day, machine credit was going down dramatically. The machine (windows 7 foibles aside) is fast and working ok.
4. I looked further and have worked out that it's not a mere bit of credit maths allocation that's gone wrong, for some reason, FAAH on W7 U 64 bit, on exact same hardware it was fine with before, is running A LOT SLOWER. I mean a LOT slower, like 20 something hours on a machine that's estimated to (and probably was) running them in 5.X hours. OTHER tasks are still belting through with great gusto.
5. I've ran all WCG tasks for a couple days on it, and they in general seem fine. The credity graph is shooting back up again, it was woeful running what from memory was just HHC and FAAH, as FAAH was hogging it - slowly.
6. This isn't so much about credit though, poor credit is a SYMPTOM. The poor credit is CAUSED by taking SO LONG to run FAAH on a machine that should be completing them in a FRACTION of the time. See?

Something is up with FAAH, and perhaps HFCC. I've been running HFCC on it and none are valid yet so can't list claimed / given.

THAT is the issue, FAAH is for some reason running a LOT LOT slower.

I don't know why, the process seems to be incrementing CPU cycles same rate, isn't doing wierd activity... not page faulting overly .. It's a mystery. Unless maybe it's doing something in machine code that's specific to 32 bit processors but surely others would have seen? Why is FAAH on one core running like crap when on adjacent core, HCC is running fine?
And if it IS USING these CPU cycles, what's it DOING with them?!

I am switching to FAAH. I should start on Wednesday tu crunch until Sapphire is reached. I must first empty the pipeline of HFCC WU's and this should take one more day. I will run on three type of i7 processors all running 8 threads each, and with Win7 64bit. All processors are overclocked (dunno if this has an impact). I will see if there are differences in the ratio credit claim/award with each processor type.

"Run with wingmen" : Do you mean are multiple people running them to cross reference results? I thought that was generally the case but ok, clicking on the only 2 results now in results list for that computer:

Name: faah10612_ZINC32118998_xMut_md07200_00
Minimum Quorum: 1 Replication: 1
Result Name App Version Number Status Sent Time Time Due /
Return Time CPU Time (hours) Claimed/ Granted BOINC Credit
faah10612_ ZINC32118998_ xMut_ md07200_ 00_ 0-- 607 Valid 06/02/10 14:44:16 08/02/10 00:23:32 13.60 273.9 / 144.7
Name: faah10443_ZINC19664077_xMut_md07200_02
Minimum Quorum: 1 Replication: 1
Result Name App Version Number Status Sent Time Time Due /
Return Time CPU Time (hours) Claimed/ Granted BOINC Credit
faah10443_ ZINC19664077_ xMut_ md07200_ 02_ 1-- 607 Valid 06/02/10 11:14:52 07/02/10 20:24:51 13.87 279.3 / 146.4
faah10443_ ZINC19664077_ xMut_ md07200_ 02_ 0-- - No Reply 27/01/10 11:15:22 06/02/10 11:15:22 0.00 0.0 / 0.0

So I'm thinking that's a no? I though there normally was, maybe project changed policy.

@Highwire:
'"Run with wingmen" : Do you mean are multiple people running them to cross reference results?'
He means the small number of FAAH results where there were 2 Valid results in the quorum, i.e. where your or the wingman's device is being checked, or where the first guy on the WU got an error of some kind.
On these results, you can check that your credits are the same as the wingman's.
Not really a useful exercise, since the credits will always be the same if the results are Valid, and the CPU times will normally be different anyway.
With the second result you list above, you are on the right track (2 in quorum), but you ran the WU alone after the wingman timed out.

If it's helpful, I calculated the averages for 10 recent single-member-quorum FAAH results from my 3.25GHz QX9650 (Win XP-32), and 10 from my Q9650 @ 4.03GHz (Win XP-64). These should run very close, clock-for-clock, to your Q9550, as only their memory access speeds will be different, and I'm on XP-32/XP-64, not Win 7-64.
Both machines would have been running 1 or 2 HCC WUs concurrently with the FAAH WUs. This eases potential memory bottlenecks on the LGA775 FSB, since HCC makes fewer main memory accesses than FAAH.
CPU Time | Claimed | Awarded
QX9650, 3.25GHz, Win XP-32:
4.8 | 103.3 | 117.1
Scaling the average CPU time to 3.0GHz:
4.8 x 3.25 / 3.0 = 5.2 hours
Q9650, 4.03GHz, Win XP-64:
3.65 | 100.2 | 117.4
Scaling the average CPU time:
3.65 x 4.03 / 3.0 = 4.9 hours
Does that match your performance pre Win 7?
[Edit]: These statistics were gathered after Highwire reported the slow-execution problem.

I don't see what running with wingmen would tell us given it's already proved that this machine is running FAAH a lot lot slower than it should?

"If there were something wrong with the application, then more than just the very few would experience this. There are already 16,000 connected to WCG with W7."
'Something wrong' is a loaded phrase but it's certainly not running correctly, when other tasks ARE running correctly.

And even if 16,000 are running WCG, what % are running FAAH, what % are running on 64 bit, what number are running FAAH *ON* W7 64 bit, and what number of these would know the signs that it was running slowly, or how to check?

I noticed it because of the upgrade, if it was a new machine, or I was less nosey, maybe I'd have just assumed 'that's the length of time it should take'.

I've put some FAAH back in the que for that computer, will switch back for a bit and see how long they take, on old OS.