MT5 build 6182: chart API error 4102 after notification activity stops - page 2

New comment
 
Thank you for reviewing the code. In that declaration, total is the first formal parameter of OnCalculate: const int total. It is the local parameter name for the bar count that the documentation calls rates_total; it does not require a separate global declaration. The return type and parameter types/order match the ten-parameter form. For example, the indicator in the attached paired diagnostic compiled with 0 errors and 0 warnings on build 6182.

The chart query being investigated runs in OnChartEvent; OnCalculate only returns its bar-count argument. I can use the conventional parameter names in a future diagnostic for clarity, while preserving the already published executed sources.

Thank you also for the service suggestion. Moving both readers into one service would change the execution contexts, so I would treat that as a separate control or architectural alternative, rather than evidence that the original two-context timeout has been explained. The latest attachment in comment #9 includes returning-callback ordering controls and the raw failure logs; the internal cause and the separate historical 415 discrepancy remain unresolved.
 
paburon #:
Further controls using the returning callbacks from v2 are attached, with unchanged executed sources/templates and raw TSV logs (unmodified timestamps; no added header). The README defines all columns and test bounds.

Using a positive ChartID captured at initialization instead of chart ID 0 still produced 4102: H4 indicator call 2758 took 3156 ms, while the EA call succeeded. Both queried the controller-owned chart ID; IsStopped was false before and after. Thus the zero-ID alias is not necessary for this observed failure.

With separate returning events for the EA and indicator reads, four timeframes completed 15064 reads without errors. Reverting to paired reads, with the same initialization diagnostics, reproduced 4102 on M15 indicator call 1795 after 3031 ms. A paired-read control with an intermediate returning event completed four timeframes / 16544 reads without error at about 66-73 calls/sec per reader. This scheduling also changes cadence, so the clean samples do not establish a concurrency fix. An earlier serial attempt timed out without reader logs and remains incomplete.

These synthetic tests do not resolve the historical 415 discrepancy or prove an internal terminal defect. Could you advise on a supported diagnostic for identifying what prevents the timed-out chart request from completing? No proprietary indicator code, account data or private paths are included.

Ok, so with this code you can actually reproduce the error 4102, right ?

Please provide your config (from your MT5 log) : https://www.mql5.com/en/forum/449342

I know the error 4102 very well from experience, I know why it triggers, but I don't know what is the exact trigger in your case.

I would also need your MT5 Experts and Journal logs at the time you run the test code. Because, my computer is very fast and I was never able to reproduce the error 4102 with it, so I need to see the logs when it's reproduced. Once I have your logs, I will check again.

 
Yes. The attached synthetic code has produced real error 4102 here: test94, H4 indicator call 2758 took 3156 ms; test98, M15 indicator call 1795 took 3031 ms. The paired EA reads succeeded. This is intermittent; a fresh run is not guaranteed to reproduce it.

The matching startup Journal records show MetaTrader 5 x64 build 6182, Windows 11 build 26200, 14 x Intel Core Ultra 5 225U, AVX2, 15 GB RAM, UAC, GMT+9. They reported 1 GB free memory for test94 and 2 GB for test98, with 55 / 235 GB disk. These are startup readings, not continuous load measurements.

The raw TSV measurements for those exact failures are already in the v3 attachment in comment #9. Relevant startup Journal lines for test98 are copied below (2026-09-18, GMT+9):
23:16:14.831 Terminal MetaTrader 5 x64 build 6182 started for MetaQuotes Ltd.
23:16:14.831 Terminal Windows 11 build 26200, 14 x Intel Core Ultra 5 225U, AVX2, 2 / 15 Gb memory, 55 / 235 Gb disk, UAC, GMT+9
23:16:14.833 MCP bind error on 127.0.0.1:22346 [Only one usage of each socket address (protocol/network address/port) is normally permitted. (10048)]
The same bind error occurred at test94 startup. I do not know whether it is relevant. Account/server/IP details and personal paths are omitted. I have preserved anonymized session excerpts locally; the attachment picker did not retain the selected file in this reply.

There is a limitation with the requested platform logs: no persisted Experts rows were found in either session window. These synthetic programs write their measurements directly to TSV files rather than Print(). Also, the runner force-stopped its owned terminal after the test completion flags, so buffered platform-log tails may be missing . I cannot reconstruct those missing lines. The flushed TSVs do contain the actual API returns, errors and durations. I will preserve a graceful terminal shutdown in the next diagnostic to improve platform-log capture without changing the reader code. Thank you for checking.
 
I reproduced 4102 again in fresh test124 and captured the platform logs through a graceful shutdown. The EA reader, indicator reader and template are byte-identical to test98/v3. Only the controller's completion path now requests TerminalClose(0); it does so after both readers finish, not during the failed call.

M15 indicator call2481 returned false/4102 after3172ms (uptime343048265 to343051437). The matching EA read succeeded at343048265. IsStopped was0 before and after. Both queried chart51252896750391. Graceful shutdown was requested at343051640, after the failure; terminal exit code0.

Below are all23 persisted Journal rows from this startup through shutdown and all3 Experts rows in that window. Explicit placeholders remove account/server/IP information, personal paths and the controller's broker symbol. Timestamps and ordering are retained. The readers use flushed TSVs; Experts therefore contains the controller shutdown messages, not per-read Print output. The underlying cause remains unresolved.

Journal (2026-09-19, GMT+9):
LO 0 04:50:28.122 Startup successfully initialized from start config "[PRIVATE_PATH_REDACTED]
OK 0 04:50:28.902 Terminal MetaTrader 5 x64 build 6182 started for MetaQuotes Ltd.
HQ 0 04:50:28.903 Terminal Windows 11 build 26200, 14 x Intel Core Ultra 5 225U, AVX2, 1 / 15 Gb memory, 39 / 235 Gb disk, UAC, GMT+9
CK 0 04:50:28.903 Terminal [PRIVATE_PATH_REDACTED]
QJ 0 04:50:28.903 Terminal launched with [PRIVATE_PATH_REDACTED]
HD 3 04:50:28.905 MCP bind error on 127.0.0.1:22346 [Only one usage of each socket address (protocol/network address/port) is normally permitted. (10048)]
LS 0 04:50:32.966 Experts expert GracefulController ([CONTROLLER_SYMBOL],H4) loaded successfully
HF 0 04:50:34.079 Network [REDACTED: account/server/IP/session information]
KK 0 04:50:34.079 Network [REDACTED: account/server/IP/session information]
DF 0 04:50:34.561 Network [REDACTED: account/server/IP/session information]
QG 0 04:50:34.561 Network [REDACTED: account/server/IP/session information]
KK 0 04:50:34.561 Network [REDACTED: account/server/IP/session information]
LP 0 04:50:35.335 Experts expert ReadRaceEA (P415N_343032640,M15) loaded successfully
HN 0 04:50:35.460 Indicators custom indicator ReadRaceIndicator (P415N_343032640,M15) loaded succesfully
OG 0 04:50:35.616 Trades [REDACTED: broker/VPS message]
OD 3 04:50:54.214 Experts GracefulController ([CONTROLLER_SYMBOL],H4) calls TerminalClose(0) function
EI 0 04:50:54.225 Experts expert ReadRaceEA (P415N_343032640,M15) removed
KP 0 04:50:54.226 Experts expert GracefulController ([CONTROLLER_SYMBOL],H4) removed
CH 0 04:50:54.292 Indicators custom indicator ReadRaceIndicator (P415N_343032640,M15) removed
PK 0 04:50:54.465 Terminal exit with code 0
PD 0 04:50:54.468 Network [REDACTED: account/server/IP/session information]
RG 0 04:50:54.513 Terminal stopped with 0
QF 0 04:50:54.515 Terminal shutdown with 0

Experts (same session):
NK 0 04:50:54.213 GracefulController ([CONTROLLER_SYMBOL],H4) GC124 completion: requesting TerminalClose after reader completion or existing watchdog outcome. signal_generation_enabled=false trading_enabled=false
NP 3 04:50:54.214 GracefulController ([CONTROLLER_SYMBOL],H4) TerminalClose(0) function called
DH 0 04:50:54.218 GracefulController ([CONTROLLER_SYMBOL],H4) GC124 OnDeinit reason=9
 
paburon #:
I reproduced 4102 again in fresh test124 and captured the platform logs through a graceful shutdown. The EA reader, indicator reader and template are byte-identical to test98/v3. Only the controller's completion path now requests TerminalClose(0); it does so after both readers finish, not during the failed call.

M15 indicator call2481 returned false/4102 after3172ms (uptime343048265 to343051437). The matching EA read succeeded at343048265. IsStopped was0 before and after. Both queried chart51252896750391. Graceful shutdown was requested at343051640, after the failure; terminal exit code0.

Below are all23 persisted Journal rows from this startup through shutdown and all3 Experts rows in that window. Explicit placeholders remove account/server/IP information, personal paths and the controller's broker symbol. Timestamps and ordering are retained. The readers use flushed TSVs; Experts therefore contains the controller shutdown messages, not per-read Print output. The underlying cause remains unresolved.

Journal (2026-09-19, GMT+9):
LO 0 04:50:28.122 Startup successfully initialized from start config "[PRIVATE_PATH_REDACTED]
OK 0 04:50:28.902 Terminal MetaTrader 5 x64 build 6182 started for MetaQuotes Ltd.
HQ 0 04:50:28.903 Terminal Windows 11 build 26200, 14 x Intel Core Ultra 5 225U, AVX2, 1 / 15 Gb memory, 39 / 235 Gb disk, UAC, GMT+9
CK 0 04:50:28.903 Terminal [PRIVATE_PATH_REDACTED]
QJ 0 04:50:28.903 Terminal launched with [PRIVATE_PATH_REDACTED]
HD 3 04:50:28.905 MCP bind error on 127.0.0.1:22346 [Only one usage of each socket address (protocol/network address/port) is normally permitted. (10048)]
LS 0 04:50:32.966 Experts expert GracefulController ([CONTROLLER_SYMBOL],H4) loaded successfully
HF 0 04:50:34.079 Network [REDACTED: account/server/IP/session information]
KK 0 04:50:34.079 Network [REDACTED: account/server/IP/session information]
DF 0 04:50:34.561 Network [REDACTED: account/server/IP/session information]
QG 0 04:50:34.561 Network [REDACTED: account/server/IP/session information]
KK 0 04:50:34.561 Network [REDACTED: account/server/IP/session information]
LP 0 04:50:35.335 Experts expert ReadRaceEA (P415N_343032640,M15) loaded successfully
HN 0 04:50:35.460 Indicators custom indicator ReadRaceIndicator (P415N_343032640,M15) loaded succesfully
OG 0 04:50:35.616 Trades [REDACTED: broker/VPS message]
OD 3 04:50:54.214 Experts GracefulController ([CONTROLLER_SYMBOL],H4) calls TerminalClose(0) function
EI 0 04:50:54.225 Experts expert ReadRaceEA (P415N_343032640,M15) removed
KP 0 04:50:54.226 Experts expert GracefulController ([CONTROLLER_SYMBOL],H4) removed
CH 0 04:50:54.292 Indicators custom indicator ReadRaceIndicator (P415N_343032640,M15) removed
PK 0 04:50:54.465 Terminal exit with code 0
PD 0 04:50:54.468 Network [REDACTED: account/server/IP/session information]
RG 0 04:50:54.513 Terminal stopped with 0
QF 0 04:50:54.515 Terminal shutdown with 0

Experts (same session):
NK 0 04:50:54.213 GracefulController ([CONTROLLER_SYMBOL],H4) GC124 completion: requesting TerminalClose after reader completion or existing watchdog outcome. signal_generation_enabled=false trading_enabled=false
NP 3 04:50:54.214 GracefulController ([CONTROLLER_SYMBOL],H4) TerminalClose(0) function called
DH 0 04:50:54.218 GracefulController ([CONTROLLER_SYMBOL],H4) GC124 OnDeinit reason=9

I'd be interested to know what happens on your machine if you insert Sleep(2000) in your indicator code like so:

 Set("DONE",lparam);
 Sleep(2000);
 // No polling loop: the first finisher returns; the second schedules one next round.
 if(State("READY")>=lparam && GlobalVariableSetOnCondition(key+"GO",lparam,lparam-1))Pump(lparam+1);
 
Thank you, Ryan. Before changing the paired diagnostic, I measured Sleep(2000) in a separate minimal indicator OnChartEvent on this same build 6182. It returned in 0 ms (uptime 353931140 to 353931140), with GetLastError()=0 immediately afterwards. The EA OnTimer control took 2000 ms (353931328 to 353933328), also error 0. IsStopped() was false before and after both calls. This was one isolated call per context, not yet an insertion into the paired reader. The official Sleep documentation says it cannot be called from custom indicators: https://www.mql5.com/en/docs/common/sleep . Thus I cannot treat it as an effective two-second indicator delay or a demonstrated fix.

I also tested whether the test terminal's MCP startup bind error was necessary. Four new instrumented runs used MCP enabled/disabled/enabled/disabled. The startup bind error was present in the enabled runs and absent in the disabled runs. The configuration was restored byte-for-byte afterwards; other MT5 instances were left running.

Both disabled runs still recorded native 4102. In trial 1, the D1 indicator ObjectGetInteger call 1551 took 3141 ms (353007484 to 353010625), returning 0/error 4102; the paired EA read succeeded at 353007484. In trial 3, the M15 indicator's next-round EventChartCustom call at round 1746 took 3000 ms (353066140 to 353069140), returning false/error 4102. An immediate diagnostic ObjectGetInteger then took 3016 ms (353069140 to 353072156), also 0/error 4102. IsStopped was false before and after these calls, and graceful shutdown was requested afterwards.

Instrumentation difference: both Pump functions now capture EventChartCustom's immediate error and duration, and perform the extra object read only after a failed event send. ReadFixed and callback scheduling are unchanged; no waits were added. These are new instrumented binaries, not the byte-identical readers of test124. Earlier -1010 protocol results without the immediate API error remain unclassified.

This excludes the test terminal's own startup MCP bind failure as a necessary condition for these observed 4102 failures. It does not exclude other processes/shared resources, identify the terminal's internal trigger, or explain the separate historical 415 discrepancy. No proprietary indicator source or account information is included.
 
paburon #:
The official Sleep documentation says it cannot be called from custom indicators: https://www.mql5.com/en/docs/common/sleep . Thus I cannot treat it as an effective two-second indicator delay or a demonstrated fix.

My bad. I thought that Sleep() had been updated for universal use. Obviously, it hasn't.

I keep circling back to the fact that Alain doesn't experience the code "bug" on his super-fast computer.

 

In the EA, Sleep() can be used to reduce resource usage:

 if(!ReadFixed((int)lparam)){Finish();return;}
 Sleep(2000);
 Set("READY",lparam);
 // No polling loop: the first finisher returns; the second schedules one next round.
 if(State("DONE")>=lparam && GlobalVariableSetOnCondition(key+"GO",lparam,lparam-1))Pump(lparam+1);
12
New comment