Separate a screen-specific failure from a shared editor problem by comparing other screens, independent projects and a minimal new project. Preserve your original files, collect reproducible evidence and use the software vendor's documented repair or support path rather than changing licensing files or reinstalling without a diagnosis.
Start HMI editor crash diagnosis by finding the smallest case that fails: one screen, every screen in one project, or a simple screen in a new project. That distinction tells you whether to investigate project content or the shared engineering environment first. Preserve the original project before making changes. A successful compile does not prove the graphical editor is healthy, and a crash alone does not justify reinstalling software or changing licensing files.
Match the symptom to the next check
Record the exact action that closes the application. Opening a screen, selecting an object and compiling a project are different failure points.
- Only one screen crashes: investigate that screen's objects, templates and dependencies in a project copy. This pattern suggests a content-specific trigger, but does not prove corruption.
- Every screen in one project crashes: check shared project resources and compare with an independent project. Copying the whole project may carry the same trigger with it.
- A simple screen in a new project also crashes: investigate components shared by the editor, including the installation and workstation environment. Confirm that the new project uses a comparable target and editor type.
- The project opens on another compatible workstation: compare the software builds, installed components and local environment. This is evidence of a workstation-specific difference, not proof of one particular cause.
- The crash happened once and cannot be repeated: preserve the report and record the circumstances. Avoid disruptive repairs without a repeatable symptom or supporting evidence.
These patterns guide the investigation. None identifies a failed component by itself.
Protect the project and running equipment
Create a vendor-supported project archive or backup before testing. Keep an untouched copy separate from your working copy. Confirm that the archive can be opened in the intended software version without converting your only original.
Record the engineering application's full version, update level and installed packages. Also record the operating system version, the HMI target type and any recent installation changes. Package names alone are not enough to compare two workstations.
Keep this work separate from the running machine. Do not download a test project, change the runtime configuration or stop production merely to check whether an editor opens a screen. Any necessary changes to running equipment belong under the site's maintenance and change-control process.
An editor crash is also separate from the choice between a factory status display and an operator HMI. Changing the viewing hardware does not establish why the engineering application closes.
Run a controlled set of project checks
Use a working copy and change one thing at a time. Keep a short results table with the project, action, result and crash-report reference.
- Confirm the original trigger. Open the affected screen once and record whether the crash happens immediately, during loading or after an editing action. Avoid repeatedly reopening it without collecting new information.
- Try a different screen in the same project. If it opens, compare the resources used by the failing screen with those used by the working screen.
- Create a minimal new project. Use a comparable HMI target and a basic screen without imported objects or custom controls. If this also crashes, the original screen is no longer the only useful place to investigate.
- Try an independent known-good project if available. Use a compatible project that is not derived from the affected one. Do not convert or overwrite its only copy.
- Compare on another workstation when practical. Use the same supported software build and required components. A different update level makes the comparison less conclusive.
A project copy is useful for safe experimentation. It is not an independent control if it contains the same screens, shared resources and dependencies as the original.
Understand what compile and library checks prove
Compile the relevant HMI target or station and save the complete warnings and errors. Resolve meaningful project errors through the documented workflow, then retry the original editing action.
However, compilation and graphical editing exercise different parts of an engineering application. A successful compile can coexist with an editor crash. Treat the compile result as evidence about that operation, not as a clean bill of health for the installation.
If the failure is isolated to one screen, a vendor-supported library export and reimport can help narrow the problem. Perform it only in a disposable project copy. Preserve the original screen rather than deleting it from the sole working project.
Library operations may retain the resource that triggers the failure. Likewise, rebuilding a screen from copied objects may reproduce the same problem. Where practical, compare a basic new screen with versions that add the suspect objects one at a time. Stop when you have a useful reproduction rather than rebuilding an entire project without a clear test.
Check the shared workstation environment
When independent projects fail at the same editing action, review the environment before choosing a repair.
- Check the vendor's compatibility information for the operating system, engineering-software release and installed updates.
- Confirm that the required HMI editing components are installed at compatible levels. Do not assume every component shares the main application's update state.
- Compare the onset of the problem with recent changes, such as application updates, component installations or graphics-driver changes. Timing is a clue, not proof of causation.
- Check available disk space and any storage or resource errors recorded around the crash. Follow the application's documented requirements rather than an invented minimum.
- Save the application crash report and relevant operating-system event entries. A repeatedly named module is useful support evidence, but it may not be the root cause.
Do not disable endpoint protection, weaken access controls or run unofficial cleanup utilities as a general troubleshooting step. If security software records a blocked operation, investigate it through the approved support process.
Use the documented repair path
Consider installation repair when the evidence points beyond one project, especially when a minimal new project reproduces the crash. Repair is a reasonable next action, but it may not resolve the crash.
Use only the software vendor's or its distributors' installation media, updates and recovery instructions. Confirm that the package matches the installed release and that the proposed update or repair is supported for that configuration.
Before proceeding, preserve project archives, required libraries, installation records and licensing information. Check the vendor's instructions for handling licenses during repair or reinstallation. If the installer offers no repair option, do not improvise an uninstall sequence. Obtain the documented procedure or ask vendor support which component should be repaired.
Do not delete licensing folders, alter activation data or infer a licensing fault from a file's modification date. A timestamp does not establish why an editor crashed. If the software reports a license problem, use its official license-management or recovery procedure.
Verify the original failure after repair
Repeat the same tests used before the change so that the result is comparable.
- Open the minimal test project's screen.
- Open the originally affected screen in a working copy.
- Open several other screens, including ones with shared templates or additional controls.
- Make a small reversible edit, save it and reopen the project.
- Compile the relevant target again and review the resulting messages.
Record exactly what now works and what still fails. Opening one blank screen is not enough to establish that the original problem is resolved. Editor recovery also does not establish that a project is ready to download to running equipment; retain the normal review and commissioning process.
Give support a reproducible case
If the crash remains, send vendor support the full software build, operating-system details, installed component list, exact reproduction steps and crash reports. Include the results from the minimal project and any compatible-workstation comparison.
Provide a reduced project that still reproduces the failure when possible. Remove confidential content only from a separate copy, then check that the reduced version still fails. Use an approved secure transfer route for project files and diagnostic packages.
The useful handoff is specific: which action fails, which projects fail, what changed and which checks have already been completed. That gives support a better starting point than an unexplained request to reinstall everything.
Questions
What should I check if every HMI screen crashes the editor?
Start by testing a basic screen in a new, comparable project. If that also crashes, investigate the shared engineering environment rather than rebuilding every screen. Installation components, software compatibility and workstation changes are possible investigation paths, but this pattern alone does not establish the root cause.
Does a successful compile rule out an HMI editor problem?
No. Compilation and graphical editing exercise different application functions. Save the compile results because they help describe the project's condition, but repeat the screen-opening test separately. A project can compile successfully while the editor still fails when loading a screen.
When should I repair or reinstall the engineering software?
Consider repair when independent projects or a minimal new project reproduce the same failure, after checking compatibility and preserving your work. Follow the vendor's documented repair or reinstallation procedure for the installed release. A crash does not, by itself, prove that a full reinstall is necessary.
Should I delete a recently changed licensing file?
No. A changed timestamp does not establish that a licensing file caused the crash. Do not delete licensing folders or alter activation data. If there is an explicit licensing error, use the vendor's official license-management, reset or recovery process and preserve the information needed for support.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.