Well, I haven't been timing the interval precisely, but when I've been paying attention, it seems to happen fairly consistently at around the 4hr:45min mark, or maybe the 4hr:50min mark. If you can install a current supported version thats the ideal situation. I am of course just guessing, but its an educated guess. If the time to failure is pretty much constant then it is likely to be a side-effect of the amount of work that has been done by the software and reducing the processor utilisation won't help. If the time between failures appears random then it may be the kind of timing/chunking issue I described. The high CPU utilisation may be shortening the time between failures. You're running a really good stress test on the software with what you are doing.Īnother option, if you have the hardware, might be to run it on a machine with more processor capacity.

The more complex software is, the more likely it is to have these kinds of problems. These assumptions can be perfectly valid for years even if they do not match the letter of the documentation (or even if they do the documentation can change or be incomplete to start with), but which go away as machines get faster or something deep in the OS changes the handling of data very slightly. Its really easy to build in assumptions about how data that is written arrives at the reader (assuming one blob or various kinds of fragmentation, becoming multiple fragments or different subdivisions of the data). Timing and chunking issues are a particularly awkward area and are very prone to subtle changes over time.

This is the problem with old Windows software, or software from any OS. Most of what is in the event log IS gibberish unless you have a passionate interest (wrote the software that produced it) in whatever it is. If its a disk error then you'd see something in the event viewer complaining (with a red icon) about hardware. The reference to read error could be to disk, network or inter-process communication.

Does chessmaster 9000 run on windows 10