META TESTER 5 Cloud Network — Agents disconnected and unable to self reconnect - page 2

New comment
Fxrobustix #:
Now that the schedule values are clarified, I would stop editing common.ini manually and reproduce the problem once from a clean Agent Manager configuration. Compare the affected machine and the working laptop at the same time, recording build number, DNS resolution, outbound connection attempts and exact UTC timestamps. If the laptop connects while the workstation sends no outbound request, that points more to local agent state than the ISP. Can you post one fresh Manager log from startup until the first failed connection attempt?

Here's a fresh log from the workstation (build 6140, currently connected and working fine — 44/44 agents, receiving cloud passes normally):

CS      0       03:26:07.884    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       03:26:07.884    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 136 / 191 Gb memory, 150 / 464 Gb disk, UAC, admin, GMT+7
CS      0       03:26:07.892    Startup MQL5 account: XXXXXXXX, cloud network mode is on
CS      0       03:26:07.893    Startup initialization finished
CS      0       03:59:16.242    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       03:59:16.243    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 134 / 191 Gb memory, 164 / 464 Gb disk, UAC, admin, GMT+7
CS      0       03:59:16.253    Startup MQL5 account: XXXXXXXX, cloud network mode is on
CS      0       03:59:16.253    Startup initialization finished
CS      0       03:59:29.285    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       03:59:29.286    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 134 / 191 Gb memory, 164 / 464 Gb disk, UAC, admin, GMT+7
CS      0       03:59:29.295    Startup MQL5 account: XXXXXXXX, cloud network mode is on
CS      0       03:59:29.295    Startup initialization finished
CS      0       09:21:31.418    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       09:21:31.419    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 121 / 191 Gb memory, 195 / 464 Gb disk, UAC, admin, GMT+7
CS      0       09:21:31.427    Startup MQL5 account: XXXXXXXX, cloud network mode is on
CS      0       09:21:31.427    Startup initialization finished
CS      0       17:35:27.159    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       17:35:27.160    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 132 / 191 Gb memory, 211 / 464 Gb disk, UAC, admin, GMT+7
CS      0       17:35:27.169    Startup MQL5 account: XXXXXXXX, cloud network mode is on
CS      0       17:35:27.169    Startup initialization finished

Important context: the machine itself was never rebooted or manually restarted at any point during this window. It has been running continuously. So these 5 "Startup" entries are the manager process restarting on its own, not the OS restarting.

Two observations:

  1. No connection-state lines at all. Every entry stops at "initialization finished" — there is never a "Connecting", "Connected", "Registered", or "Failed" line logged afterward, even though the machine is actively connected and processing cloud passes right now. So the manager log by itself cannot be used to determine connection status — build 6140 apparently doesn't log the cloud handshake at all, which makes diagnosing silent failures much harder.
  2. Restart #2 → #3 is only 13 seconds apart (03:59:16 → 03:59:29), while the other gaps (33 min, 5h22, 8h14) are unexplained given that nothing on my end triggered them — no reboot, no manual relaunch, no Windows update that I'm aware of. Since the machine wasn't restarted, these look like the manager process itself crashing or being stopped and relaunched — possibly by a Windows service supervisor — without any error being logged.

Given point 1, would it be possible to get a build that logs the actual cloud connection attempt/result (TLS handshake, registration accepted/rejected, schedule acknowledged)? And regarding point 2 — is there a separate crash/event log for the manager process that would show why it restarted 5 times in one day with no user action?

the cloud server connection just stopped. 44 cores disconnected , but the laptop is still connected and make passes. So basically it is not only the ISP, or something very special about the ISP. Why the workstation dont run and its locked and laptop fully ok ?
tcp 443 indicate a normal ping at 45ms.
Not a single change of IP

here is the log of the workstation:


CS      0       17:35:27.169    Startup MQL5 account: xxxxxxx, cloud network mode is on
CS      0       17:35:27.169    Startup initialization finished
CS      0       18:09:10.545    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       18:09:10.546    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 114 / 191 Gb memory, 246 / 464 Gb disk, UAC, admin, GMT+7
CS      0       18:09:10.553    Startup MQL5 account: xxxxxxxx, cloud network mode is on
CS      0       18:09:10.553    Startup initialization finished
CS      0       19:22:35.323    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       19:22:35.324    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 92 / 191 Gb memory, 239 / 464 Gb disk, UAC, admin, GMT+7
CS      0       19:22:35.336    Startup MQL5 account: xxxxxx, cloud network mode is on
CS      0       19:22:35.336    Startup initialization finished
CS      0       22:30:38.203    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       22:30:38.204    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 176 / 191 Gb memory, 271 / 464 Gb disk, UAC, admin, GMT+7
CS      0       22:30:38.212    Startup MQL5 account: xxxxxxx, cloud network mode is on
CS      0       22:30:38.212    Startup initialization finished
Fxrobustix #:
Compare the affected machine and the working laptop at the same time, recording build number, DNS resolution, outbound connection attempts and exact UTC timestamps. 

MetaTester doesn't use DNS; it has its own system for resolving IPs.

Cyril Louis Marc Maillet #:

Here's a fresh log from the workstation (build 6140, currently connected and working fine — 44/44 agents, receiving cloud passes normally):

Two observations:
  1. No connection-state lines at all. Every entry stops at "initialization finished" — there is never a "Connecting", "Connected", "Registered", or "Failed" line logged afterward, even though the machine is actively connected and processing cloud passes right now. So the manager log by itself cannot be used to determine connection status — build 6140 apparently doesn't log the cloud handshake at all, which makes diagnosing silent failures much harder.
  2. Restart #2 → #3 is only 13 seconds apart (03:59:16 → 03:59:29), while the other gaps (33 min, 5h22, 8h14) are unexplained given that nothing on my end triggered them — no reboot, no manual relaunch, no Windows update that I'm aware of. Since the machine wasn't restarted, these look like the manager process itself crashing or being stopped and relaunched — possibly by a Windows service supervisor — without any error being logged.

Given point 1, would it be possible to get a build that logs the actual cloud connection attempt/result (TLS handshake, registration accepted/rejected, schedule acknowledged)? And regarding point 2 — is there a separate crash/event log for the manager process that would show why it restarted 5 times in one day with no user action?

The information you're seeking is already logged.  You're looking at the Agents Manager log file, which contrary to your point #2, is logging each time you open the Agents Manager window.  If you want to see what's going on with the individual agents, you'll have to look at their log files.
Shalem Loritsch #:

MetaTester doesn't use DNS; it has its own system for resolving IPs.

The information you're seeking is already logged.  You're looking at the Agents Manager log file, which contrary to your point #2, is logging each time you open the Agents Manager window.  If you want to see what's going on with the individual agents, you'll have to look at their log files.
well,
the good news is since im permanently connected to a vpn, there is no restart anymore in the log file. Only one per day. Even if i check the dashboard regularly.
I also get a more stable in/out data traffic connection that lead in more passes given.

The metatrader developers should be inform that in many Asian countries and probably other regions, the ISP are acting as rights violators, breaking connections, and probably stealing datas from computers, as well as they surely made impossible to generate money with tester or any other trading strategies due to there political dictatoship and delayed packets data feed.

CS      0       12:35:51.483    Startup MetaTester 5 build 6140, 21 Aug 2026
CS      0       12:35:51.484    Startup Windows 10 build 19042, 88 x Intel Xeon  E5-2699 v4 @ 2.20GHz, AVX2, 174 / 191 Gb memory, 289 / 464 Gb disk, UAC, admin, GMT+7
CS      0       12:35:51.494    Startup MQL5 account: xxxxxxxxxx, cloud network mode is on
CS      0       12:35:51.494    Startup initialization finished
new build 6157 seem to have a more stable IN/OUT datas transmission

or maybe its just about the vpn config
Cyril Louis Marc Maillet #:


if you did a search of this forum, you would have seen that these matters have been discussed many many times "over the years", therefore all issues you mention are welknown by devs and long time members. What do you expect devs can do about it? I am a member of groups of traders that has many traders that live in such geograpical locations, and all of them use vps's in other jurisdictions. And i am sure that if you would have done even a simple search of google would have brought up this common solution.
Michael Charles Schefe #:
if you did a search of this forum, you would have seen that these matters have been discussed many many times "over the years", therefore all issues you mention are welknown by devs and long time members. What do you expect devs can do about it? I am a member of groups of traders that has many traders that live in such geograpical locations, and all of them use vps's in other jurisdictions. And i am sure that if you would have done even a simple search of google would have brought up this common solution.
have done many search, but dont find any real infos about the truth behind those jurisdictions.

As of now i will go full time on vpn for sure.

and for sure Vps can increase speed but thats another budget ...
Cyril Louis Marc Maillet #:
have done many search, but dont find any real infos about the truth behind those jurisdictions.

As of now i will go full time on vpn for sure.

and for sure Vps can increase speed but thats another budget ...
most traders who use vps's will not use them for extra speed, but for improved connection reliability -- not extra speed, as increasing speed, rarely happens. The main difference between a vps and a local home connection is that most vps's have business grade hardware -- and greatly improved connection to the www.
12
New comment