It looks like faulty units. Also have you tried updating to 7.14.3

Mike

I record the reasons for getting retries of FAH2 work, so I've been seeing this "second hand" for quite a while now (unfortunately I've not been recording the exact O/S version and client version...). My Linux systems have been happily running retries on these batch 2735 jobs; almost, if not all, the failing tasks are Windows 10 systems (I think there have been some Windows 7 ones, but not many). The majority of errors are checksums, but some of them are "wrong size" errors

I don't think I've ever had an FAH2 job fail on any of my systems (not counting [very rare] system crashes or Server Aborts when prior users have taken just over the deadline to send in results!!!) So, either my Linux systems are picking up the files from somewhere different and getting fair copies or there is something about those jobs that upsets various clients on Windows 10...

I can't think of any reason why this particular batch should be giving so much grief, but if other batches were being equally problematic we'd be seeing a lot of users in here complaining! I wonder if the WCG tech people are aware of this issue?

@Mike Gibson - I have done retries for tasks that failed on various clients - the latest one I saw failed on 7.16.5 (! - not specific to one client, then...) but most of the failures I'm seeing lately are 7.14.3 so that's not likely to help!

@smeyer55 - A successful FAH2 job doesn't have a wingman; what you're seeing is a failure followed by a failed retry - eventually it'll either get sent to Linux or a Windows system that doesn't fail... I am frequently the third user to have tried one of these, as the first retry went to another Windows 10 system...

A recent case in point FAH2_002735_zinc1628661_000004_000008_127 where the first task was on Windows 10 Core x64 Edition (18362) with client 7.14.3 and a "wrong size" error, and the first retry was on Windows 10 Enterprise x64 Edition (18363), again with client 7.14.3 and an "MD5 check failed" error. Both of them failed on the same file, which had one of those long hexadecimal file names and a .dms extension. Mine ran o.k.! (Ubuntu 18.04, client 7.14.2.)

Whatever the issue might be, it's getting to be almost as regular as the Windows 8 "Required Privilege not held" error (as seen from my retry-processing viewpoint)...

Hope something comes along to resolve this, but I'm at a loss to explain it (and have no Windows systems to look at for ideas...)

Cheers - Al.

that it's happening on other WCG subprojects would make me more inclined to think it's an issue with your machine.

Unless you have another theory - given the number of workunits - what are the odds of you getting bad WUs that frequently - which run fine on other PCs?

I'm running other FAH work units fine on all the machines. It is just that particular series that is failing.

Steve

This is just a shot in the dark, but a couple of years ago I had this same problem occurring sporadically on some machines at the end of my wireless. It was 99.9% cured when I upgraded from wireless G to Wireless N. If you have a wired connection, it might be somewhere in the connections or maybe a defective cable, especially if it is only one one machine.
Just a thought.
Cheers