Fix C-More Micro simulator program faults in ea1-run.exe

Read the five tokens in the fault record

Windows raises this dialog when an application dies with an unhandled exception, and each field has a job:

• AppName: ea1-run.exe names the process that died. Here it is the simulator runtime.
• AppVer: 1.1.6.42 is that process's build number.
• ModName: eatxfunction.dll names the module that held the faulting instruction.
• ModVer: 1.11.6.52 is that module's build number.
• Offset: 000027ea is the position of the faulting instruction inside the module, written in hexadecimal.

Screenshot every dialog. One record says where the fault sat. Three records say whether it sits in the same place every time, and that pattern decides everything that follows.

The record names a module but stays silent about what that module does inside; neither the record nor the vendor documentation spells out the internal job of eatxfunction.dll. Use the module name and offset as comparison values between runs and let the bisection find the object.

An AppVer of 1.1.6.42 is an early build of this software; releases in the V4 range have shipped since. If your dialog shows the same two version numbers, your installed build is years behind what the manufacturer currently ships.

Symptoms and what each points to

Collect three fault records from three simulator runs before you edit anything, then match your pattern:

• Same module, same offset every run: eatxfunction.dll at 000027ea each time. The fault is deterministic, so one object or one navigation path sets it off. Bisect the linked screens.
• Same module, offset moves between runs: the fault lands in different code each time, which points at state carried across navigation or an unstable host PC. Count the jumps to fault, test a reduced project, and test on a second PC.
• Different modules from run to run: the host PC is the suspect, typically drivers, security software or a damaged install. Test on a clean PC before you touch the project.
• The fault fires only after many jumps, never the first few: the effect builds up. The jump count to fault is your metric, and it tells you whether each change you make helps or hurts.

Each pattern leads to a different next step, which is why the records come before the edits.

Checks before you change anything

1. Screenshot every fault dialog with all five tokens visible.
2. Reproduce the fault on demand and count the clicks to it. That count is the baseline every later run is measured against.
3. Compare your versions against the reported ones. AppVer 1.1.6.42 and ModVer 1.11.6.52 on your dialog mean your build matches the reported fault.
4. Skip the moves that cannot touch the faulting code: restarting the simulator and clicking more slowly only delays the same exception, and a reboot clears leftover state from earlier sessions while the fault returns on a fresh run.
5. Download the project to a panel once, early, as a comparison point. Panel behavior is data for the diagnosis; it is not a fix for the simulator.

The simulator is the run-time test bench; the editor's preview mode is a separate tool with its own quirks, covered in why C-More Micro preview mode will not sort screens.

For the same layer-by-layer split applied to a crash at startup, see isolate the layers after an HMI DLL crash at startup.

Update the software build first

Bring the software current before you edit the project, because conclusions drawn on a years-old build may not carry to the build you ship with.

1. Get the current C-More Micro programming software release from the manufacturer's official download page. Install from that source and no other.
2. Open the same project, start the simulator, and rerun the click loop from a fresh start.
3. If the fault is gone, write the new build numbers next to the project file and stop here.
4. If the same module and offset still fire, move to the bisection. A different offset after the update is useful too: it says the update changed the code path, so keep recording tokens on every run from here on.

If the programming software itself crashes outside the simulator, work through diagnosing an HMI editor crash before any software repair first.

Bisect the linked screens on a copy

Bisection works because a fault triggered by one screen cannot stay hidden while the suspect set keeps halving. Work on a copy and leave the original untouched; if the project file itself opens unreliably, recover an HMI project that crashes on open before you start cutting.

1. Save the project under a new name and run the simulator on the copy. Count the clicks to fault. That number is the baseline.
2. Walk one navigation loop at a time: screen A to B and back, then A to C and back. Note the first loop that faults.
3. Delete half of the linked screens from the copy. Delete every jump object that targeted them, then search the remaining screens for jump targets that now point at a deleted screen number and clear those too.
4. Rerun the loop from a fresh simulator start. Fault gone: the trigger is in the removed half, so restore that half and cut it again. Fault still firing at the same offset: cut the remaining half.
5. When three or fewer screens remain under suspicion, remove them one at a time. The screen whose removal ends the fault holds the trigger.
6. Bisect the objects on that screen the same way: remove half the clickable objects, rerun, and keep halving until removing one object ends the fault.
7. Inspect the object you isolated: its target screen, any overlay or popup it opens, and any second action assigned to the same touch. Rebuild it from scratch on the same screen and retest. A copy of the object carries its settings with it, so copying can bring the bad setting along.
8. Restart the simulator for every test run so each run starts from the same state.

Example: bisecting a project of 24 linked screens

Inputs. A project copy with 24 linked screens; the reported project is described only as a large set of linked screens, so 24 is this example's own setup. The baseline comes from reproducing the fault: it fires by click 10 in the full project. Every record so far names eatxfunction.dll and offset 000027ea, the deterministic pattern. The module and offset are the reported values; the screen count and the click counts are the example's setup.

Rule in words. Each round deletes half the screens still under suspicion and reruns one navigation loop from a fresh simulator start. The suspect set halves every round, so the worst-case number of screen-level rounds is the number of times 24 can be halved down to one screen, which is log2(24) rounded up.

Arithmetic. log2(24) = ln 24 ÷ ln 2 = 3.178 ÷ 0.693 = 4.59, so 5 screen-level rounds worst case. The halving chain runs 24 → 12 → 6 → 3, then single screens. One path: round 1 deletes 12 screens, fault persists, 12 suspects. Round 2 deletes 6, persists, 6 suspects. Round 3 deletes 3, the fault ends, so those 3 come back as the suspects. Round 4 removes 1 of the 3, persists, 2 suspects. Round 5 removes 1 of the 2, the fault ends, and that screen holds the trigger. The screen has 6 clickable jump objects, and log2(6) = 1.792 ÷ 0.693 = 2.59, so 3 object-level rounds worst case. This path takes 2: round 6 removes 3 of the 6 objects, persists; round 7 removes 1 of the 3 and the fault ends. Worst case for the whole search is about 8 simulator runs; at a couple of minutes per run it fits inside half an hour.

Result. The isolated object pairs its screen jump with a second action on the same touch. Rebuilt from scratch on the same screen, it survives a 40-click run, four times the baseline of 10, with no fault dialog.

Decision. A single deletion that ends the fault is the trigger found. If the fault survives every cut with the same module and offset, the suspect is the software build: stop cutting and take the records to the manufacturer's support channel.

Confirm the fix with a repeatable click test

1. In the updated software, open the repaired project and start the simulator.
2. Click every jump object at least once, then repeat the full loop.
3. Click well past the baseline. With a fault that came at click 10, run 40 clicks with no dialog; four times the baseline is the pass mark.
4. Check that ea1-run.exe stays running in Task Manager and no fault dialog appears.
5. Download the project to a panel and repeat the loop. The simulator runs on PC hardware with PC drivers behind it, and the panel runs its own firmware, so a simulator pass and a panel pass are two separate results. Get both before you call the project done. If the fixed project is headed to a customer's panel, send the HMI program update on a flash card.
6. Keep the reduced project copy as the regression test: rerun the full loop on it after every future edit to the project.

Recommendation: record the five tokens from every fault dialog, bring the C-More Micro software current from the manufacturer's official download page, and rerun the loop. If eatxfunction.dll and offset 000027ea still fire, bisect the linked screens on a project copy until removing one object ends the fault, rebuild that object from scratch, and confirm with a click count at least four times your baseline. Keep the token record and the reduced copy as the standing check on future edits.

Questions