When exactly one HMI project stops the editor on open, the fault is in that project file, not the installation. Close the editor, make two copies before anything else, prove the software with a known-good project, read the Event ID 1000 entry in the Application log, and test one recovery copy per attempt. A project of 70 screens and 3 weeks of work survives this because the original is never opened.
When exactly one HMI project stops the editor on open and every other project opens normally, the fault sits in that project file, not in the software installation. The editor is designed to close cleanly on a fault it cannot handle, so the shutdown itself is the record of where it gave up. The order of work is fixed: close the editor, copy the project before anything else, prove the software with a known-good project, read the fault record in the Windows Application log, and test one recovery copy per attempt. A project holding 70 screens and 3 weeks of work cannot be rebuilt by reinstalling anything, so every step below keeps the original file untouched until a copy opens, saves and checks out.
What each symptom points to
Match your case against these patterns before you open anything else:
- One project stops the editor on open, every other project opens. The fault follows that project's data. Work on the file and leave the installation alone.
- The editor closes at the same point each time, after the project window appears and while the screens load. Note the point precisely. It is the first detail a support engineer asks for, and it tells you whether the next attempt behaved the same or differently.
- Every project fails to open, including ones that opened reliably last week. The editor installation or the machine is at fault. Stop file experiments until the software side is diagnosed.
- A copy restored from a CD-R or another read-only medium opens but will not save. The read-only flag travels with the file. Clear the flag and retest before you judge the data; clearing read-only on an HMI backup restored from a CD-R walks through that exact failure.
- A dialog names the editor's program file and says it has to close. Windows has already recorded the same shutdown in the Application log as Event ID 1000, and the log entry carries more detail than the dialog does.
Whatever the pattern, the next step is the same: make the file safe before another open.
Copy the project before anything else
Close the editor completely. Copy the project file and any companion files it needs with the file manager, first to a separate working folder and then, if you can reach one, to a second location such as a network drive or a removable disk. Make 2 independent copies. Write down the original's file size and its last-modified date and time, so you can tell later whether anything moved.
Rules for this stage:
- The original stays closed and unopened. Every test from here on runs on a copy.
- Name the copies so the history is obvious: original, working-copy-1, working-copy-2.
- No cleanup utilities and no manual edits to the project's internal files. Their structure is undocumented, and a mishandled edit can destroy what a support engineer could still have recovered.
Check before you go on: the original is untouched, 2 copies exist in different places, and the size and timestamp are written down.
Check the editor with a known-good project
Open a project that worked reliably last week. Let it come up fully, then close it without saving anything and without changing a screen. If it opens cleanly while the problem project still fails, the failure travels with the problem project's data. If the known-good project fails to open too, the installation or the machine is at fault, and no further file experiments make sense until that is fixed; that path has its own article, HMI editor crash diagnosis before software repair.
That split catches real faults: one documented case found repeating print-screen failures pointed at editor build itself, with no single project to blame.
Read the fault record in the Application log
Every application shutdown on Windows is written to the Application log as Event ID 1000, one entry per event. To reach it, press Windows+R, type EVENTVWR, expand Windows Logs, and select Application. The newest entries sit at the top.
Three parts of the entry carry the diagnosis:
- Faulting application name should print your editor's program file. If it names something else, the fault belongs to that other program and your project may be innocent.
- Faulting module name identifies the component that failed. Compare 2 entries: the same module in both means the same failure happened both times.
- Exception code, printed as a hexadecimal value, is what support engineers match against known faults.
If you need more depth, make sure the Windows Error Reporting service is running, reproduce the failure once, and note the .dmp file it creates. windbg.exe from Debugging Tools for Windows reads that dump, and its !analyze command names the faulting module. Send the dump with the project duplicate when you hand the case over.
Check: you can find the Event ID 1000 entry for the failure and read the faulting module name.
Test one copy at a time
Open working-copy-1, not the original. Three outcomes:
- The copy opens. Use the editor's normal Save As immediately to write a recovery copy under a new name, then close. From then on you work in that recovery copy. Walk through the screens against what you last knew, because a file that opens can still be missing content.
- The copy fails at the same point. Close the editor and leave that copy alone; another open of the same file adds nothing. Each attempt consumes one copy, so duplicate the preserved original again before the next idea, and change exactly one thing per attempt.
- The copy behaves differently. Note what changed between attempts. A change in behaviour is information about which part of the file is troubled.
Then look for older copies. Search the folders where you normally save and back up, compare names, sizes and timestamps, and test candidates one at a time, each on a fresh duplicate. When an earlier copy opens, save it under a new name at once. Its content stops at the date of that backup, so check what is missing before it goes anywhere near production.
Example: a 70-screen project that fails on open
Inputs. Project size: 70 screens, counted in the editor's screen list. Work behind it: 3 weeks since the project was started. Symptom: exactly 1 project stops the editor on open while all the others open. Log behaviour: Windows writes 1 Event ID 1000 entry per application shutdown, so 2 attempts produce 2 entries. Copies prepared before any test: 2, per the procedure above.
The rule in words. Never open the only copy. Prove the editor with a known-good project, read the event entry after every failed open, and spend one copy per attempt.
The arithmetic. Files on hand after copying: 1 original + 2 copies = 3 files. Attempts available before duplicating again: 1 per copy, so 2 attempts, and the original is opened 0 times. Screens protected in every test: all 70 live in the untouched original, so screens lost even if every copy fails is 70 - 70 = 0. Event entries after two attempts: 2, and the same faulting module in both means the same failure on every open.
Result. The known-good project opens cleanly, and both copies fail at the same point with the same faulting module in both Event ID 1000 entries. The fault travels with the project data. An older backup copy from the site's backup folder opens, so it is saved at once under a new name and its screens are walked against what was added since that backup was made, to list exactly what is missing.
Decision. One project failing while the others open puts the fault in the project file; every project failing puts it in the installation, and the known-good test separates the two in one open and one close. The recovered backup returns to the machine only after the screen check passes, and the untouched original and its 2 copies stay in place until the recovered version has run.
When to stop and send it out
Stop opening files when every preserved copy fails at the same point, when no earlier backup opens, or when the next idea would mean editing the project's internal files. Those files carry an undocumented structure, and hand edits outside the editor's own commands are where recoverable projects become unrecoverable ones.
Hand the case over as a package: a duplicate of the preserved project, never the only original, with the error message text, the Event ID 1000 entries and the known-good project result attached. Support can reproduce the failure on their copy while yours stays where it is. Once a damaged file is confirmed, the repair work itself follows the same steps as recovering a corrupt CODESYS project file after a crash.
Before anything recovered goes back on the machine, walk its screens against the validated design and download it the way you would any changed project, because a recovered file can hold older content than the version that ran last.
The decision
Recommendation: before any other step, close the editor and make 2 copies, then open one known-good project once. If the known-good project opens and every copy of the problem project fails at the same point, recover from the newest backup copy that opens, save it under a new name, and check its screens before it returns to the machine. If the known-good project fails too, leave the project file alone and treat the installation as the fault.
The decision for each case:
- One project fails, known-good opens: project data fault. Recover on copies, newest backup that opens wins, original never opened.
- Every project fails: editor or machine fault. Follow the editor-crash diagnosis path; the project file is most likely intact.
- A restored copy opens but will not save: clear the read-only flag that came with it, then retest.
- Nothing opens and no backup helps: send a duplicate with the event entries, and keep the original at home.
Questions
Does the editor keep an automatic backup of my project?
Some editors write autosave or backup copies, some do not, and the location changes between versions. Check the project folder and any backup folder your site uses before you decide there is nothing to find. Any candidate file goes through the same test as the main project: duplicated first, opened on the copy, one candidate per attempt. A file that opens is saved at once under a new name so the original candidate stays untouched.
Can reinstalling the editor bring the project back?
No. The project data lives in the project file, and a reinstall touches the software only, so it cannot repair a damaged project. Reinstall only after a known-good project has also failed to open, because that result points at the installation or the machine rather than at your file. Keep the preserved copies through the reinstall and do not let an installer touch the folder that holds them.
What do I send when I hand the problem to support?
Send a duplicate of the preserved project file, never the only original. Add the exact error message text, the Event ID 1000 entries from the Application log with the Faulting application name and Faulting module name lines, the exception code if the entry shows one, and the result of your known-good project test. State where the open stops: before the project window, partway through loading, or after the editor is up.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.