Ah, that's interesting.

From what you know, does this mean that the default priority of the process/program acemd.exe,  is "below normal" on all computers where it is installed, but that it is just on the single older computer that you suspect that is what causes the program to abend with no(?) error message?

Are all these computers running the same OS and, if not, then what are the differences?
Is there an Event Log for the computer (with the abending process) in question? That might help to identify/indicate a possible root cause of the abend. Similarly, the Event Logs for the other computers might be able to throw some light on the behaviour of the non-abending process' default operation.
At the moment, it seems that you cannot be certain as to what the root cause of the abend actually is. You only know (presumably by trial-and-error) that the abend seems to not occur if the process priority is set to normal. (Is that correct?)

Thus, altering the process priority with PT (Process Tamer) might only be a workaround to an as yet undefined problem, at best.

-IainB (July 14, 2018, 10:37 PM)

the computers are running different OS, and everywhere acemd.exe has "below normal" priority.  And there is no problem at all with this, except for this one computer in question.

My guess regarding the root cause for the problem here is: the CPU is an old Intel Quad Q9550, with various grid computing tasks, 4 in total, hence 1 for each core.  What comes in addition is that for the process acemd.exe (GPUGRID), the CPU uses the GPU as co-processor.  And what I notice is that the higher the GPU clock, the more the chance that acemd.exe stops - whenever it runs "below normal" priority.
This does NOT happen if it runs "normal" (also, the problem does not come up if I run only 3 tasks altogether, leaving 1 core free).
So, to me, it seems that I only need to give the CPU processing of acemd.exe some more support by increasing it's priority.

And yes, you are right: altering the process priority with PT obviously is a workaround, but seemingly one that works.

@Erich56: I'm intrigued by this: Why would the process acemd.exe be changing (lowering) its default priority? This would likely be a deliberate design feature, rather than an error, yet you - the user - clearly don't want it to do that.
I wonder - would it make any difference to the default priority if you set the process to "Run as Administrator"? (Not sure whether that is relevant.)

-IainB (July 14, 2018, 09:52 AM)

I don't think that acemd.exe changes it's default priority.  The default priority seems to be "below normal", and what Mouser is suggesting is that once PT changes it to "normal", it's being changed back to "below normal" (after quite variable time spans, which seems strange, anyway).
On all other machines with which I run acemd.exe, there is no problem.  It's just this one PC with an older CPU, where acemd.exe suddenly stopps running. And what I have found out was that this does NOT happen once it's priority is at "normal".
This is the reason behind the whole thing.

I now tried the whole thing with "force to normal" - and this worked (yesterday I had the same situation, and then I tried it with "above normal", and for a short while this worked, too).
So meanwhile I'll let it run on "normal" and see what will happen.