OK, so this is just a misleading error message, and doesn't mean the engine has crashed. Just that it forfeited. So in principle it should be solvable by implementing a cold-turkey timeout that aborts the search.
It will be hard to do this in an elegant way, for a microMax-type design. (Which counts on the search itself for performing the game-level move by returning from the root before UnMake when that moves comes up.) I guess I could just save the best move in a global in the code section that prints the PV in the root (which gets executed when the root alpha increases). And after the search returns in the main program with the 'abort flag' set, add some code that would perform the thus saved move as if it was an input move. (The abort flag already exists for the purpose of terminating an analysis search.)
@Guenther - 2016 is pretty long ago. I don't remember it, and I cannot find any executable of that date on the computer I am on now. Typically I do use an extra number behind the letter to indicate a change in the package that does not affect the executable in an essential way. In my source repository I see 3 commits between the official version 5.0b and Sept 2016, but one of those was just the update of the manual, another one fixes a problem that only existed on some Linux distros with an unusual C compiler, and the third keeps track of some info on the position during search that is never used (but this might cause a minuscule slowdown).
These patches could be in 5.0b3, but it is more likely that 5.0b was compiled from the 5.0b source I had on Windows, with just the version number changed. And that this change was made because I updated the fmax.ini file in the package, by adding definitions for 2 new variants ('apothecary chess'). This would not affect any of the other variants.
