How to Troubleshoot EA Runtime Abnormalities: First Preserve MT4 Logs, Then Change Settings

Author: Thomas | EA and Platform Practice | October 5, 2026

When an EA suddenly stops trading, generates duplicate orders, or performs differently than expected after a restart, the most common mistake is to immediately change parameters, reinstall the program, and then guess where the problem lies. This can overwrite the most valuable on-site information. Troubleshooting should first preserve evidence, and then distinguish causes at the program, terminal, and account levels.

First Preserve Records Before and After the Abnormality Occurs

Record the time the abnormality appeared, the full trading symbol, chart period, EA version, parameter file, and account positions at that time. The time here must indicate whether it uses computer time, trading server time, or a self-converted Beijing time; do not directly splice together records from different clocks.

Logs do not necessarily contain the program's entire decision-making process. Information that the developer did not output cannot be used to infer normal execution merely from the absence of errors. Keeping continuous records before and after is more helpful for determining the sequence of events than a single error screenshot; before publishing or sending to support staff, first check whether they contain account numbers, personal information, or other sensitive content.

Experts and Journal: What to Look at in Each

The Experts tab in MT4 mainly presents runtime information for mounted EAs, including the program's own messages and related operation records. The Journal tab focuses on the client terminal's activity in the current session. When troubleshooting the same abnormality, you can compare the information in both places, but do not treat either one as complete execution proof.

Using Open in the right-click menu of the corresponding tab can open the relevant log directory and write the currently displayed records into a log file. Official help states that EA logs are located in MQL4/LOGS under the terminal data directory, and terminal logs are located in LOGS; files are usually named by date. The data directory may differ for different installation instances, so you should enter it from the terminal you are currently using to avoid mistakenly taking files from another terminal.

First Determine: Not Triggered, or Triggered but Not Executed

"No new orders" may correspond to at least several different states: strategy conditions were not met; the program did not load properly; automated trading permission is restricted; the trade request was rejected; the request result differs from expectations. Seeing only the program identifier on the chart does not allow you to directly determine which one it belongs to.

First, based on the strategy's original rules, confirm whether it should really trigger on the specified symbol and period. Then check whether there is loading, initialization, or trading operation information in the relevant time period. If a trade request exists, verify the result against the return message and account order records; do not determine that execution was successful based solely on text printed by the program. If logs lack key steps, you should ask the developer to add logging.

Permission Checks Should Correspond Item by Item; Do Not Open Everything

MT4 terminal settings and the EA's own properties affect automated trading permissions; operations such as changing the account, chart symbol, or period may also be related to the terminal's automated trading settings. Check the current actual settings and use the program documentation to determine expected behavior; do not replace troubleshooting by repeatedly clicking buttons.

Do not unconditionally enable DLL calls or other external access just to make the program start trading. First confirm whether the program actually needs the corresponding capability, whether the source is trustworthy, and whether its purpose is clearly explained. Insufficient permissions may be the cause at a certain step, but opening all permissions is not a reliable solution.

Before Restarting, First Confirm How Existing Positions Will Be Handled

After preserving current orders, pending orders, and program state, then decide whether to restart. Whether restarting the program will recognize existing orders depends on the specific implementation; you cannot assume every EA can automatically restore its original internal state. This is especially true for programs with position adding or multi-order management logic, where repeated starts may conflict with existing positions and need to be checked against the program rules.

Turning off automated trading does not mean existing positions have been closed, nor should "program paused" be understood as risk disappearing. How to handle existing orders should be decided in advance, not guessed temporarily after an abnormality occurs. If you suspect the program is generating abnormal orders, handle it according to the established pause and manual check process, while verifying the actual exposure in the account.

Use a Single Change to Test the Fix Result

A simulated environment can be used to reproduce operations and check program behavior, but it cannot prove that live execution conditions are exactly the same. Change only one clear factor at a time, preserve the parameters and logs before and after the change, and then observe whether the relevant abnormality disappears. If you change the version, modify parameters, and switch accounts at the same time, it is often difficult to determine which step had an effect.

An effective troubleshooting record should state the phenomenon, time, evidence, changes made, and recheck results. Unexplained abnormalities should continue to be verified with the developer or platform support; do not use "trading has resumed" to replace root cause analysis, and do not present a technical fix as a profit guarantee.

Leveraged trading may cause significant losses. This article is for operations and maintenance knowledge sharing and does not constitute a buy or sell instruction. Log troubleshooting can help locate problems, but it cannot guarantee program safety, strategy effectiveness, or future returns.