>>>If you want high reliability on old computers, it's a good idea to have some sort of official protocol for evaluating them in case of problems e.g. check power incidents logged by UPS monitoring software, Windows Event logs, periodic dust vacuuming etc.
>
>In this case it's a VM on a Server2008 machine - but we've seen the freeze at more than one customer now.
>
>FWIW I've checked the code and can see one possible issue in the code downloaded from the VFP wiki- basically the message is loaded byte by byte into an object property which has to assign a new block of memory for the entire message as each byte is received rather than using textmerge or adding into a memo field. Some of these messages are large. Perhaps VFP is pushed to a garbage collection state mid-process so it mishandles the termination character and waits forever. Certainly worth a refactor to use textmerge or memo.

Hmm, in the limited work I've done with comms ISTR it's common practice to use buffering, where you let X bytes or kilobytes accumulate, then process. Requiring the listener to handle incoming bytes individually in real-time can expose you to (as you point out) GC, or OS or even (in your case) VM context switching.

For utilities I write that have to run 24/7/365 I include fairly verbose logging. This is always text, direct to disk via STRTOFILE( ..., additive ). I wrap functions in log calls like

DateTime1 Function1 Started
DateTime2 Function1 Completed

If something hangs or takes longer than expected it's usually pretty easy to find in the logs.

There is also a 16MB size limit for a memvar (and presumably object property). Do you get any messages approaching that size?