Here's an output log from Weini, when using winboard (under Windows OS).

the last 3 digits of the time are milliseconds (after the sign "-")

So at 202ms Weini received from winboard a "time" command with 10centisec on the clock. Weini trigger "stop pondering" and request a "think" just after (stm 0 mode 0).
Pondering is finished after "End of search" while TimeMan is working to get next move search time ; all of this in less than 1ms. Based on its estimation, TimeMan gives 7ms to think, having 100ms on the clock and still many moves to do ... but an "emergency situation" is detected, and instead of 7ms, Weini used 49ms (which is still < 100ms). The TC ends inside the tree exactly after 49ms (251ms is the current time) and Weini starts pondering again.

Weini will then never receive the next "time" command, nor any other command saying it is Weini's turn (stm, mode) but at 323ms, the engine receive a result command saying it lose on time (when pondering !).

It seems to me that thinking/pondering switch in Weini are quite fast and I really don't understand this situation that is happening a lot when using "sudden death" clock type.

The first thing you should do is creating a winboard debug file and compare
the timings for I/O with your log.

From your log it is not clear to me when the searched move really is sent to WB.

Yes, absolutely necessary since one possible reason for the loss on time is that WB did not receive a proper "move ..." command so it still thought it were the engine's turn.

It might even be better to simply write all those own debug messages to standard output (instead of a separate logfile), then they will appear in the Winboard debug log together with all communication via WB protocol.

Two interesting thoughts :
* it seems (I didn't check the source code) that winboard/xboard is thinking every string received on stdout (even starting with a #) is an issue if it contains "not found" inside. From the doc :

In support of the -firstHost/-secondHost features, which allow a chess engine to be run on another machine using the rsh protocol, xboard recognizes error messages that are likely to come from rsh as fatal errors. The following messages are currently recognized:
unknown host
No remote directory
not found
No such file
can't alloc
Permission denied

# COMMENT
The engine can send any string of printable characters, terminated by a newline, for inclusion in the winboard.debug file, provided the line starts with a '#' character. If the engine has set feature debug=1, it is guaranteed that WinBoard (and any future version of it) will completely ignore these lines in any other respect.

* the time control issue never ever happens on xboard (linux), only with winboard.

Two interesting thoughts :
* it seems (I didn't check the source code) that winboard/xboard is thinking every string received on stdout (even starting with a #) is an issue if it contains "not found" inside. From the doc :

In support of the -firstHost/-secondHost features, which allow a chess engine to be run on another machine using the rsh protocol, xboard recognizes error messages that are likely to come from rsh as fatal errors. The following messages are currently recognized:
unknown host
No remote directory
not found
No such file
can't alloc
Permission denied

# COMMENT
The engine can send any string of printable characters, terminated by a newline, for inclusion in the winboard.debug file, provided the line starts with a '#' character. If the engine has set feature debug=1, it is guaranteed that WinBoard (and any future version of it) will completely ignore these lines in any other respect.

* the time control issue never ever happens on xboard (linux), only with winboard.

Maybe a problem of not flushing stdout when sending the engine move to WB (and/or maybe also other commands sent to the GUI)?

But this code is inside the DTOR of some Logger object specifically construct inline and acting as a stream in my Logger implementation ; maybe compiled with VisualStudio the DTOR is called a little later. At least this never happens with xboard and linux (gcc6 on debian 9)...

But this code is inside the DTOR of some Logger object specifically construct inline and acting as a stream in my Logger implementation ; maybe compiled with VisualStudio the DTOR is called a little later. At least this never happens with xboard and linux (gcc6 on debian 9)...

Ok I check that, adding more logs, and both under windows and linux I am pretty sure the move is send to GUI as soon as I wanted from both Weini and GUI point of view :