Scheduling priority

Unfortunately, it's not a similar situation as it's nothing like the previous problem of 4.5 years ago.  The error there was to do with an API version mismatch after a software upgrade.  All that means is that various driver and kernel components were built with different versions of build tools and as a consequence were incompatible with each other.  This is not what is happening in your case.

Even if you think it sounds similar, because it was so long ago, it's highly unlikely to be so.  System software and drivers, and science apps for that matter, will have changed a lot in that time.  At that time I think the search would have been one of the radio pulsar searches and not the current gamma-ray pulsar search.  In cases like this, you should just start a new thread and give more details about your particular compute errors.

Checking/reinstalling graphics drivers is always a good first step when lots of GPU crunching errors start occurring. If you seem to have fixed the problem and then after a period it comes back again, you have to start thinking about other causes.  A few days ago, I documented what seems to be a similar problem in this particular message and in a couple of further reports that followed.  Please have a read through those messages and see if what is reported there is what you are seeing on your machine.

Your problem isn't exactly the same but it may well be related.  In my various cases, the actual error message was to do with trying to allocate more GPU memory than a seemingly bogus and quite small allocation limit.  In your case the error message seems different.  I checked one of yours at random and this is what I got

Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x00007FF923F04D8C read attempt to address 0xFFFFFFFF

which I interpret to mean that the app was trying to read a memory location that it wasn't allowed to.  Maybe this is also some sort of memory allocation error - I certainly don't know.

Returning to what you posted, when you say, "waiting a while to get new work", did you check in BOINC Manager (Advanced view) to see if you could see the reason for 'waiting'?  Did you look at the entry for Einstein on the projects tab to see if, under the 'Status' column, it said something about project communication being suspended for quite a large number of hours with a counter counting down each second until that full backoff time had been run down to zero?

If you get a large number of compute errors very quickly (and you have several hundred all showing zero run time - so that's pretty quick :-) ) the client can call a 24hr halt to proceedings - presumably to give you some time to notice, investigate and potentially fix whatever the error happens to be.   Sometimes, things like this can be a transient problem and if you notice the situation, you can try stopping and restarting BOINC to see if the issue clears itself.

Once you stop and restart BOINC the backoff seems to be automatically canceled.  If not you can 'select' the Einstein project and then click 'update' to override the backoff and force communication.  I suggest you look for any repeat occurrence of your problem and see if normal crunching has resumed after a string of errors has instigated a backoff.  If you can see that behaviour, it would seem to be very much like what I have observed.

I have commented on things I think might be causing this. It's only a guess and it could be a misplaced guess.  If you can document the details of what happens to you, it might allow the Devs to work out what the problem really is.  In my case, there has been another machine go into a 24hr backoff and then start normal crunching again, just by canceling the backoff.  If you can observe the same behaviour, with totally different hardware and drivers, it would really indicate an issue with the tasks or the application rather than OS or drivers.