« on: July 15, 2018, 02:11 AM »
Ah, that's interesting.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.
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)
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.