Troubleshooting TIA Portal V15.1 WinCC Runtime Advanced Loader Failure

When the START button in the WinCC Runtime Advanced loader silently fails to launch a downloaded project on a Windows PC, engineers typically assume the engineering project is corrupt, the runtime is mismatched, or the PLC link is broken. In practice, the loader itself can be the bottleneck. With TIA Portal V15.1, the loader is the front-end that owns the compiled runtime file *.fwc (containing pdata.fwc). If the loader cannot resolve its working configuration, the START button becomes a no-op while direct execution of pdata.fwc still succeeds. This article documents the diagnosis, the official Siemens loading rules, and the field-confirmed fix set used to restore reliable loader operation on WinCC Runtime Advanced V15.1 stations.

Problem Description and Field Symptoms

Symptoms reported on TIA Portal V15.1 / WinCC Runtime Advanced V15.1 stations deployed on Windows 7 / Windows 10 PCs:

• The engineering download (TIA Portal → target PC) completes without error and a fresh *.fwc is deposited in the project directory.
• Manual launch of pdata.fwc starts the runtime and the HMI tags update, proving the compiled project and the PLC connection are healthy.
• The WinCC Runtime Advanced Loader (the tray application hosting the START button) accepts the download but nothing happens when START is pressed. No HMI window appears, no error dialog, no log entry to the Windows Event Viewer.
• After a successful first download, subsequent downloads only succeed immediately after a full PC restart. A second download within the same Windows session fails or silently no-ops.
• The Loader window itself stops opening on subsequent reboots until the runtime service chain is reset.
• Reinstalling Runtime Advanced, repaving the project with a blank program, or pointing the loader at a fresh project directory all reproduce the failure.

Affected Versions and Components

The issue is documented against the following product stack. Newer V16, V17, V18, V19, and V20 versions carry forward the same loader architecture, so the diagnostic logic applies to any WinCC Runtime Advanced deployment where the START button fails to launch.

Root Cause Analysis

Three independent root causes have been confirmed in field incidents where the loader START button fails while direct project launch still works.

Cause 1 — Loader service account or user profile corruption

The WinCC Runtime Advanced loader stores its active project pointer, the path to the runtime executable (HmiRtm.exe), autostart flags, and licensing state in the per-user registry hive (under HKCU\Software\Siemens\Automation or the equivalent Wow6432Node path on 64-bit Windows) and in a project-specific *.fwc manifest. If the user profile is rolled back, restored from a non-matching image, or if the loader is launched under a different Windows user than the one that performed the original download, the registry values go stale and the START button silently resolves to a non-existent path. The Windows event log shows nothing because the failure is in the loader's own pre-flight, not in a Win32 API call.

Cause 2 — TIA Portal and Runtime Advanced version mismatch

Siemens' official loading documentation states that the project cannot be loaded if the version of WinCC Runtime Advanced installed on the target device does not match the configured device version in the TIA Portal project. This applies to the loader hand-off as well: if the engineering project was last compiled under a different service pack (V15.1 base vs. V15.1 + Upd1, for example) than the installed runtime, the loader rejects the launch and the START button appears to do nothing. Direct double-click of pdata.fwc can still succeed in some cases because the file-association handler performs a more lenient check than the loader's pre-flight.

Reference: Siemens TIA Portal documentation — Overview for loading of projects (RT Advanced).

Cause 3 — Windows image / file system state corruption

Repeated full-PC restarts being required to permit a single download, combined with the loader window failing to open on subsequent reboots, is a strong indicator that the underlying Windows image has a corrupted loader dependency — typically a broken COM registration for the loader, a missing or rolled-back runtime executable in the Siemens install path, or a damaged scheduled task that the loader uses to detach the runtime from the engineering session. The defect is invisible to chkdsk and to the TIA Portal installer because the binaries are present and version-correct. Replacing the Windows image with a known-good restore point has been confirmed to resolve the symptom end-to-end.

Pre-Diagnostic Checklist

Capture the following before changing anything. The data is required if the issue is escalated to Siemens support or to your internal platform team.

1. Confirm the TIA Portal version on the engineering station: Help → About. Note the build (for example, V15.1 + Update 7) and the exact build number.
2. Confirm the installed Runtime Advanced version on the target PC: Control Panel → Programs → SIMATIC WinCC Runtime Advanced V15.1. Read the exact version including SP and update level.
3. Open the loader's Settings panel (the configuration button at the bottom of the loader window). Capture:
   • Project file path (must point to a real *.fwc file).
   • Runtime executable path (must point to HmiRtm.exe in the Siemens install directory).
   • Autostart setting (on / off).
   • Display mode (full screen / windowed).
4. Export the loader's registry hive from an elevated command prompt: reg export "HKCU\Software\Siemens\Automation" loader_hkcu.reg /y (or the equivalent Wow6432Node path on 64-bit Windows).
5. Capture Application and System event logs filtered to the Siemens runtime sources (Siemens HMI, HmiLoader, HmiRtm) for the last 24 hours.
6. Note whether the loader START button has ever worked on this specific PC, and the most recent change event (Windows update, image restore, profile reset, antivirus action).

Step-by-Step Resolution

Execute the steps in order. Stop at the first step that restores normal loader behavior and proceed to the verification section.

Step 1 — Validate loader configuration in the Settings dialog

Open the WinCC Runtime Advanced Loader. Click the small configuration button at the bottom of the loader window to open Settings. Verify the two path fields:

• Project file (*.fwc): must resolve to the actual *.fwc deployed by TIA Portal. If the field is blank, the loader has lost its pointer to the compiled project.
• Runtime executable: must point to HmiRtm.exe, typically at C:\Program Files\Siemens\Automation\WinCC RT Advanced\HmiRtm.exe. A missing or renamed binary yields a silent START failure with no error to the operator.

If the project path is wrong, browse to the correct *.fwc and apply. If the runtime path is wrong, restore the default and apply. Try the START button.

Step 2 — Confirm TIA Portal and Runtime Advanced versions match

Open the TIA Portal project, navigate to Devices & Networks, select the HMI station, and on the inspector pane read the configured Version field for the panel. It must be identical to the runtime version installed on the PC, including the same service pack. If they differ, update the project to target the installed runtime or install a matching runtime, recompile, and re-download.

Reference: Siemens TIA Portal — Overview for loading of projects (RT Advanced).

Step 3 — Reset the loader's user-state

The loader keeps per-user state. If the Windows user profile has been touched (roaming profile reset, mandatory profile change, image restore of a different user), reset the loader's per-user state:

1. Close the loader completely.
2. Export, then delete the loader's per-user settings key (or the equivalent path discovered during the pre-diagnostic export): HKCU\Software\Siemens\Automation\HmiLoader
3. Delete the cached project pointer file in the user's local AppData, typically: %LOCALAPPDATA%\Siemens\Automation\HmiLoader\*
4. Re-launch the loader. It will prompt for the project file and runtime executable. Browse to the deployed *.fwc and confirm the runtime path.
5. Press START and confirm the runtime window opens.

Step 4 — Re-register loader COM components

If the loader window itself has stopped opening, the COM registration for the loader is likely broken. Identify the loader's COM / OCX modules in the Siemens install directory and re-register them from an elevated command prompt. The exact module names vary by service pack; the canonical pattern is to enumerate the OCX / DLL files under the install directory and re-register them:

cd "C:\Program Files\Siemens\Automation\WinCC RT Advanced"
for %m in (*.ocx *.dll) do regsvr32 /s %m

Re-launch the loader and verify the START button.

Step 5 — Reinstall the runtime cleanly

If Steps 1–4 do not resolve the issue, perform a clean reinstall of WinCC Runtime Advanced V15.1. Microsoft's TIA Portal install guidance is the cleanest reference for the prerequisite steps:

1. Fully shut down the PC (power off, do not use sleep or hibernate). Power back on.
2. Open Programs and Features, uninstall SIMATIC WinCC Runtime Advanced V15.1.
3. Manually remove the install directory: C:\Program Files\Siemens\Automation\WinCC RT Advanced
4. Reinstall from the TIA Portal V15.1 media or installer package.
5. Reboot. Launch the loader, browse to the existing *.fwc, and test START.

Reference: Microsoft Learn — Problems installing TIA Portal V15.1 (general installer hygiene: full reboot, retry from elevated prompt).

Step 6 — Restore a known-good Windows image

Field-confirmed last-resort fix: if the loader fails to open on every reboot, and the START button is a no-op even after Steps 1–5, the Windows image itself is the most likely cause. Restore the PC to a known-good system image taken before the first occurrence of the symptom. This is the resolution the original reporting team applied, after which the loader operated normally across multiple download cycles without requiring a restart.

Verification

After applying any of the steps above, verify correct loader operation with the following matrix.

Prevention and Long-Term Stability

V15.1 is no longer maintained, so the long-term answer is to plan a migration to a current TIA Portal version. In the meantime, the following practices reduce the likelihood of loader corruption on a V15.1 station:

• Use a single dedicated Windows user for runtime operations. Do not let operators log in to a different account than the one that performed the engineering download.
• Disable Windows automatic driver and feature updates on the runtime PC. Stage updates on a clone first, then promote.
• Snapshot the Windows disk image immediately after a successful loader commissioning. The restore path documented in Step 6 is the fastest recovery if the image later drifts.
• Match the engineering TIA Portal build, the project's compiled device version, and the installed runtime version exactly. A spreadsheet or a physical label on the PC is sufficient to enforce this in a multi-engineer plant.
• Avoid antivirus real-time scanning on the Siemens install directory and on the runtime project directory. Several common endpoint protection products have been observed to quarantine the loader's COM components during signature updates.
• When planning a TIA Portal upgrade, refit the runtime PC to a current TIA Portal version (V18 or later) rather than staying on V15.1 and absorbing the maintenance risk. See Siemens support entry 109761576 for the V15.1 lifecycle statement.

Loader Diagnostics Matrix

Use this matrix to map a specific symptom to the most likely cause and the first action to take.

Frequently Asked Questions