Resolving HmiRTm.exe Crash in WinCC Advanced V11 SP2 Runtime

The HmiRTm.exe process is the WinCC Runtime Advanced executable that hosts compiled HMI projects on PC-based panels and runtime stations. Under TIA Portal V11 SP2 (WinCC Advanced V11 SP2), this process can terminate unexpectedly when the operator presses a navigation button immediately after authentication, leaving the plant-facing HMI screen blank and the operator unable to acknowledge alarms, change recipes, or drive the process. This reference documents the reproduction path, isolates the contributing design choices (notably the Activate Screen system function and its second parameter), and enumerates the field-proven workarounds: Project > Compiler > Rebuild All, deletion of the HMI INI folder under the project tree, and full project re-creation. The information is derived from Siemens customer support feedback and integrator field experience with TP 900 Comfort panels and PC Runtime stations.

1. Problem Scope and Affected Versions

The crash is reported on PC-based HMI Runtime stations running TIA Portal V11 SP2 with the WinCC Advanced V11 SP2 option installed. Reproductions have been documented on:

• PC-based Runtime stations (Windows XP SP3, Windows 7 32-bit/64-bit) used as client HMI nodes.
• Siemens TP 900 Comfort panels running the same V11 SP2 runtime image.
• Projects that combine a recipe management subsystem (built from the standard WinCC TIA Portal Recipe Tool) with a multi-screen navigation hierarchy and per-button access protection.

While the symptom in the field is reported on V11 SP2, the runtime architecture and the Activate Screen semantics documented in this article are preserved through the TIA Portal V13 / V14 / V15 / V15.1 / V16 / V17 / V18 / V19 / V20 / V21 generations. The same class of fault can reappear on newer versions when the project contains stale INI artifacts or when the build cache is not refreshed prior to RT start.

2. Symptom Description and Reproduction Steps

The fault follows a deterministic sequence on the affected station:

1. The WinCC Advanced RT project starts. The Menu / Start screen is displayed in the root window.
2. The operator presses a navigation button on the Menu screen that is protected by an access level. A login dialog appears in front of the navigation target.
3. The operator enters valid credentials. The dialog is accepted, the HMI logs the user on at the configured authorization level, and the dialog closes.
4. The operator presses the same navigation button a second time to perform the actual screen change.
5. The runtime raises an unhandled exception inside HmiRTm.exe and the process is terminated. The HMI screen is blank; the operating system may report a Windows Error Reporting dialog referencing HmiRTm.exe.
6. Re-starting the runtime from the project loader, from the autostart entry, or by re-loading the project reproduces the fault without re-entering credentials; the fault is sticky until the project is re-built or the INI folder is cleared.

A related symptom appears when the same operator cycles login → logout → login → logout against a navigation button group: the crash returns after a small number of cycles even when the user has been re-creating the project from a backup. This is the field evidence that the build cache and the persisted INI data are part of the root cause.

3. Root Cause Analysis

Three contributing factors have been identified, any one of which is sufficient to trigger the crash under load:

3.1 Stale Build Cache Inside the Compiled Project

WinCC Advanced uses a multi-stage build process. Incremental builds preserve compiled screen objects, recipe structures, and tag lists inside the project tree. After heavy editing — or after swapping the recipe structure or the user administration — the persisted intermediate representation can be inconsistent with the current editor view. When the runtime loads the project it deserializes these caches; an inconsistency between the cached screen tree, the user administration tree, and the active screen number at the moment of Activate Screen causes HmiRTm.exe to dereference an invalid handle and exit.

3.2 Mis-Use of the Second Parameter of Activate Screen

The Activate Screen system function in WinCC Advanced / TIA Portal takes two parameters:

The second parameter is not a screen number. It is the object number assigned by the Tab sequence editor to a specific control inside the target screen. Configuring the same value (e.g. 0) for every button is legal but means:

• If the focus is in the permanent window when the system function is called, the permanent window retains the focus after the screen change.
• If the focus is in the root screen when the system function is called, the first operator control in the Tab sequence of the target screen receives the focus.

A persistent focus object that points into a screen whose compiled handle is stale (see 3.1) is the practical mechanism that raises the unhandled exception. Configuring the object number to a value that is valid for the target screen is therefore not optional, it is part of the runtime contract.

3.3 Corrupt INI Artifacts Under the Project

The runtime persists per-station settings, last-user data, recipe file references, and access-level state under

\<projectfolder>\INI\HMI\{xxxxxxxxx}\

where {xxxxxxxxx} is a project-specific directory whose name is derived from the project ID. The contents include the runtime's view of users, audit trail, alarm log offsets, and the screen-change journal. A partial write during a prior RT termination (crash, power loss, or forced stop) leaves this directory in a state that is rejected on the next start. WinCC will not roll back the contents and will not re-validate the structure; it will fail later when a screen change is requested, and the resulting unhandled exception in the RT process presents as the HmiRTm.exe crash.

4. Workaround Matrix

5. Step-by-Step: Apply the Rebuild All Workaround

Use this procedure as the first response to the HmiRTm.exe crash. The procedure does not require a license re-export and is non-destructive to the source project.

5.1 Prerequisites

• TIA Portal V11 SP2 with WinCC Advanced V11 SP2 installed.
• The project file (typically *.ap11 or *.ap11_zip) opens without compile errors in the editor.
• Read/write access to the project directory and to the TIA Portal working directory.

5.2 Procedure

1. Close the running HmiRTm.exe on the target station. Verify via Task Manager that no HmiRTm.exe and no Siemens.Automation.Portal.exe remain in the process list.
2. In the TIA Portal project tree, right-click the HMI station (the PC system or the Comfort panel that hosts the failing runtime).
3. Select Compiler > Rebuild All from the context menu.
4. Confirm the rebuild in the dialog. The compiler clears the persisted .hmi / .bin outputs and regenerates them from source.
5. Wait for Compile (complete) in the information area. Errors must be resolved before proceeding; warnings should be reviewed.
6. Re-load the project to the target station using Online > Extended Download to Device (or the loader-based transfer for a panel).
7. Start WinCC Runtime. Validate the login + navigation button sequence end-to-end.

6. Step-by-Step: Clear the HMI INI Folder

Use this procedure when Rebuild All alone does not clear the fault, or when the runtime has crashed at least once.

6.1 Procedure

1. Close the runtime and the TIA Portal editor.
2. In Windows Explorer, navigate to the project root directory (the folder that contains the .ap11 file).
3. Open the path \<projectfolder>\INI\HMI\.
4. Identify the directory whose name is an alphanumeric project ID (for example {1234ABCD}). This is the HMI-specific INI directory.
5. Delete that directory. Do not delete \INI\ itself — other sub-directories may contain PC station or PLC data that must be preserved.
6. Re-open the project in TIA Portal.
7. Re-translate the project (Project tree > HMI station > right-click > Translate > Software (complete)). The deleted directory is regenerated from source.
8. Compile and re-deploy the project to the target station. Start the runtime and verify.

7. Step-by-Step: Re-Create the PC Station in a New Project

This is the third-tier workaround. It clears the project-level caches that the editor and the runtime share (user administration ID space, recipe path resolution, alarm log mapping) and is therefore a more thorough reset than Rebuild All alone.

1. Open the failing project in TIA Portal V11 SP2.
2. Select the PC System node in the project tree.
3. Choose Copy. The system places the PC System on the clipboard of the project navigator.
4. Create a new TIA Portal project (Project > New). Set the project name and storage path; do not reuse the old project path.
5. In the new project, choose Edit > Paste. The PC System is recreated in the new project tree.
6. Re-link any cross-project references (PLC tags, area pointers, script libraries).
7. Compile the new project with Rebuild All.
8. Transfer and start the runtime. Validate the navigation/login sequence.

Field experience shows that the fault is suppressed for a number of RT cycles but returns after several login/logout iterations. Plan the maintenance window accordingly: this workaround buys time, it does not replace a code-side fix.

8. Activate Screen — Object Number Field Reference

To assign the object number deliberately, open the target screen, select the desired control, and read its number from the Tab sequence editor. Use this number as the second parameter of Activate Screen on every button that targets this screen. Using the same value (typically 0) for every button is supported but couples the focus behavior of every screen; do not assume it is safe across recipe screens that have non-trivial operator control layouts.

9. TIA Portal Process and Service Topology (Background)

The WinCC Advanced V11 SP2 runtime depends on a set of background services and helper processes that are installed together with the TIA Portal setup. The current Siemens documentation — Overview of processes and services of TIA Portal components — documents the full service map for the modern TIA Portal (V21). The conceptual structure is preserved on V11 SP2:

• Siemens TIA Portal — the editor process that compiles the project and writes the .hmi / .bin outputs.
• Siemens Automation License Manager — provides the runtime license handle to HmiRTm.exe.
• S7DOS Help Service / SIMATIC S7DOS — supports diagnostic and trace functions used by the runtime.
• WinCC Runtime Advanced Loader — starts HmiRTm.exe with the configured project file and manages the autostart behavior.
• HmiRTm.exe — the WinCC Runtime Advanced itself; the process that is terminated by the crash under investigation.

When the runtime crashes, the order in which the loader and the runtime re-start is determined by the autostart settings in the project. After a crash, do not assume that a clean start has been performed: stale handles from the failed process may be inherited by the new one. A Rebuild All + project re-transfer is the only reliable reset.

10. Diagnostic Checklist

Run through this checklist in order before contacting Siemens Customer Support. The output of each step is required to scope the support case.

1. Capture the exact text of the HmiRTm.exe error dialog. Note the faulting module if shown (e.g. HmiRTm.dll, HMIRuntime.dll).
2. Capture the Windows Event Viewer entries under Windows Logs > Application from the source Application Error at the time of the crash. Note the Faulting module name, Exception code, and Fault offset.
3. Confirm the TIA Portal version and the WinCC Advanced version. From the editor, choose Help > About and record the exact build numbers.
4. Confirm the HMI device (TP 900 Comfort image vs. PC Runtime) and the operating system version with service pack level.
5. Verify that the project has been subjected to Rebuild All immediately before the most recent RT start. If not, perform Rebuild All and re-test.
6. Verify that the \<projectfolder>\INI\HMI\{xxxxxxxxx} directory is present and that its contents were regenerated by the most recent translate. If the directory is missing or has zero-byte files, delete it and re-translate.
7. For each Activate Screen call on the navigation buttons, record the screen name and the object number. Confirm that the object number is the Tab-sequence index of a real control on the target screen, or is intentionally 0.
8. Re-create the PC Station in a new project (W3) and re-test. If the fault does not reappear in the new project within the same number of login/logout cycles, the original project carries a corrupt cache; archive the original and contact Siemens with the artifacts from steps 1–4 plus the new project as a reference.
9. Send the archived .ap11_zip project (use Project > Archive to preserve the source) to Siemens Customer Support, referencing the diagnostic outputs from the previous steps.

11. Prevention and Engineering Best Practices

• Use Rebuild All in the project lifecycle. Build it into the deployment run-book as a mandatory step before every runtime start, every backup restore, and every transfer to a panel.
• Treat Activate Screen as a typed call. Resolve the object number from the Tab-sequence editor of the target screen and bind it explicitly. Avoid 0 on screens that have more than one focusable control and an active recipe view.
• Keep the recipe subsystem separate from the navigation tree. Avoid calling Activate Screen on a recipe screen directly from a button whose access level is changed at runtime. Resolve the screen name through a string tag if the recipe view is data-driven.
• Maintain a clean project tree. Remove orphan screens, unused tags, and dead recipe structures after every major change. The INI cache reflects the project ID space and grows stale if dead entries are not pruned.
• Version-control the project archive. Store every .ap11_zip with a build number; if a corruption is observed, the previous archive is a known-good baseline.
• Plan a TIA Portal upgrade path. V11 SP2 is end-of-life. Newer TIA Portal versions carry numerous runtime fixes; an upgrade should be evaluated once the production system is stable. Validate the upgrade in a sandbox project that includes the same recipe structures and user administration.

12. FAQ