I like that attitude.I haven't seen a P4 in a while.
It's probably a bug in the validation itself - probably being too aggressive with anti-cheat protection. But unless I can reproduce that on a machine that I have access to, I can't fix it.
Hardware errors don't give that message.
When a hardware error occurs, one of 4 things can happen:
- Crash or BSOD - just to state the obvious...
- y-cruncher catches the error, corrects it, and moves on. Validation will still fail. (see picture below)
- y-cruncher catches the error, is unable to correct it, and prints an error message.
- y-cruncher does not catch the error, and it tells you that the digits don't match at the end.
When y-cruncher catches and corrects an error, it will look like this:
If you're curious, this screenshot was generated by intentionally introducing an error into the computation via the source code.
I don't have access to any unstable machines, and most hardware errors usually end with a BSOD.
So no, this feature hasn't actually been "truely" tested before.
The sanity check error that it gave you can (but not always) show up under the following circumstances:
- Either the system clock or the BIOS clock has been tampered during the computation.
- The program has detected an abnormal frequency* - possibly caused by time-slowing cheats.
- The binary has been tampered with.
- The base clock or the FSB has been tampered with.**
*Note that speed-step and any CPU throttling/power-saving feature does NOT trigger this. (I've made sure of that.)
**This is an unwanted side-effect of the anti-cheat protection. As a result, SetFSB and similar tools may not work as they may trigger a sanity check error.
It is VERY possible that there are other "legit" things that could set off a sanity check error.
I've fixed all the things I know of that I could reproduce on my machines. But I don't have a lot of machines to play with, so it's very likely that it's still buggy.
Bookmarks