All tasks end with exit code 69 (0x45) Netbios session limit exceeded

It's not cool to malign someone else for your incorrect interpretation of the problem. I'm responding just to correct the notion that you were misled.

I guess you chose this thread to report your problems because of the "network BIOS session limit was exceeded" error message, as reported by the OP back in July, 2018.  If you had read that report and the reply provided by Holmis at the time, you would have found,

and you would have seen that the problem was graphics driver related.

This same type of 'Windows misinformation' seems to crop up quite regularly.  You really need to examine the stderr.txt stuff on the website to find better information.

You first used this thread for your 9 May 2022 problem report which had the very same Windows misinterpretation of an app error code.  It was a totally different problem this time since you were immediately (and correctly) advised that you were using a beta app that was not appropriate for your type of GPU.

Fast forward to 8 March 2023 and you again have a bogus Windows message.  Once again it was not related to the problem.  The task you linked at the time no longer exists so I've chosen this one which does.  I looked at a few around the same date and they all show something similar, with the same bogus Network BIOS message.  At the top of the 'Stderr Output' you will see the "exit code 69" which Windows tries to interpret.  There's lots of things which give the '69' code.  I seem to recall this code being referred to as "unspecified error" under Linux.

You need to look down towards the bottom of the output to get a better interpretation.  I'm not a programmer so this is just a guess as to what actually happened.  The message is:-

Error during OpenCL FFT (error: -36)followed by:-

ERROR: gen_fft_execute() returned with error -282502848which indicates that a particular routine crashed whilst trying to perform an FFT.

If you keep following, you see that the science app's main routine 'main()' returned an error code of '5' when handing things back to BOINC.  In turn, BOINC called the boinc_finish() routine and passed the value '69' which is exactly what Windows misinterpreted.  It seems to me that '69' is just a 'catch-all' code which just means "something crashed" :-).

When you use old hardware that is probably well past its 'use by' date, you need to expect unspecified, hardware related errors.  Sometimes it's power quality from old PSUs, particularly from capacitor degradation.  Sometimes it may be that doping elements in silicon chips do suffer from increased diffusion due to elevated temperatures over the 'continuous use' lifetime of the device.  Reducing frequency may buy you a bit more lifetime but eventually the crashing may return.

Not necessarily, since the 'headroom' that any particular GPU has is just a 'luck of the draw' type of thing.  Since manufacturers tend to select chips with higher headroom to use in their "super-clocked" variants, it's probably possible for a device using the default frequency to still have a lower headroom.  I guess a lot depends on how carefully the manufacturer selects the 'better' chips for the SC cards.

The only person that can sort out hardware issues like this is the person with physical access to the hardware.  Please don't suggest that you've been given wrong advice when you didn't work out that it's a totally different problem this time.