Resolving WinCC Flexible 2007 Display Bugs with HF2 Hotfix

David Krause16 min read
SiemensTroubleshootingWinCC
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Resolving WinCC Flexible 2007 Display Bugs with HF2 Hotfix

Overview

Siemens WinCC flexible 2007 was released as the engineering suite for the SIMATIC HMI panel family, succeeding WinCC flexible 2005. In the weeks following general availability, integrators reported a cluster of runtime defects concentrated in display refresh, dynamic property binding, and the engineering environment itself. Siemens responded with Hotfix HF2, a cumulative update that addresses the most disruptive items, while advising integrators with stable 2005 installations to defer migration where no driver compels the move.

This reference consolidates the field-reported symptom catalog, the engineering-environment failure modes, the official mitigation path via Hotfix HF2, and the practical workarounds that have proven effective on MP 277 and adjacent panels. It is written for commissioning engineers, control system integrators, and plant automation support staff who must decide whether to upgrade, patch, or hold.

Affected Environment and Scope

The defects observed in the field are confined to the following envelope:

  • Software: WinCC flexible 2007 base release and SP1, prior to Hotfix HF2. Post-HF2 builds carry the HF2 build identifier in Help > About.
  • Primary panel confirmed in failure reports: SIMATIC MP 277 (8" and 10", both key and touch variants).
  • Adjacent panels sharing the same runtime code base (require project-level verification): MP 270, MP 370, TP 177, OP 177. Defect exposure is highest on MP 277 because its feature set stresses the binding cache and font subsystem the most.
  • Engineering station OS observed at rollout: Windows XP SP2 and Windows Server 2003.

The defects fall into two disjoint domains: engineering-environment (ES) failures during compile, download, or project open, and runtime (RT) defects on the panel after a successful project transfer. The runtime defects are dominated by display-refresh issues; control functions (tag write-back, alarm acknowledgement, recipe handling) continue to operate normally. This separation is the engineering basis for the conservative migration policy described later.

Runtime Symptom Catalog

The following symptoms were confirmed in field deployments and, in some cases, reproduced across multiple MP 277 units running parallel instances of the same project. Engineers should treat the list as a minimum regression suite for any panel that has been compiled and downloaded with WinCC flexible 2007 prior to HF2.

Symptom 1 — Button Color Does Not Reflect Linked Bit

A button configured with a tag-driven appearance change (for example, a "Start" button turning green when the bStartPermit bit is set in the PLC) does not update its color in the runtime visualization. The same logic, when duplicated into a freshly created second MP 277 project, behaves correctly. The defect is intermittent: the first download may render correctly, and a subsequent recompile of an unrelated screen breaks the binding without touching the button.

Likely cause: A stale internal binding cache for the appearance property of the affected button. A recompile of the project does not always invalidate this cache, particularly when the recompile is triggered by an edit on a different screen.

Affected property: Appearance and BackgroundColor driven by a dynamic dialog or a direct tag connection. The defect is also observed on the Flashing property when the trigger is a bit toggle.

Symptom 2 — Text Label Properties Drift

Static text labels randomly switch to BOLD or have their font size altered at runtime. The change is not authored in the project; the ES shows the label with the original formatting. Power cycling the panel (full power-off, not warm restart) restores the expected formatting, but the defect can recur on the next state change.

Likely cause: Faulty font-cache invalidation between the ES export and the RT loader. Fonts embedded in the project versus fonts present in the panel's image are reconciled incorrectly on some recompile paths. The panel falls back to a default font set on cache miss, and the default set includes a BOLD variant that the project does not reference.

Mitigation heuristic: Cycle power rather than warm restart; verify the panel's Fonts directory matches the ES project font list using the panel's backup/restore interface.

Symptom 3 — I/O Field Does Not Display Linked Value

I/O fields bound to a tag (input, output, or both) intermittently display the configured default value rather than the live tag value. Deleting and recreating the field resolves the issue for an unpredictable interval — sometimes hours, sometimes minutes. Operators who trust the displayed value without cross-checking the PLC can drive the process into an error state.

Likely cause: Update-rate throttling combined with property shadowing. The I/O field's process-value property falls back to its design-time default when the update request times out under panel CPU load. The defect is more frequent on panels with high alarm activity or large recipe transactions in progress.

Risk classification: High. Unlike Symptoms 1 and 2, this defect can produce a silent process error. Operators must be trained to verify the displayed value against a redundant source (for example, a hard-wired pilot light) when the panel value is used as the primary control input.

Symptom 4 — Recompile Influences Unmodified Objects

A change to a single object, followed by a recompile and download, alters the runtime behavior of objects that were not edited. The change set the engineer did not touch can become visually or functionally different after each transfer. The defect is non-deterministic: a recompile after the same edit may produce a different set of regressions on a different day.

Likely cause: Non-deterministic ordering of object serialization in the project's internal database. Objects written earlier in the compile pass overwrite shared style or template references for objects serialized later. The defect is most reproducible on projects with heavy use of faceplates, library objects, and global stylesheets.

Why this is the worst symptom: It eliminates the assumption that a localized change has a localized effect, and it makes post-download verification proportional to the full project size, not the edit scope. A 30-screen project requires a 30-screen verification pass after every recompile, even for a one-character typo fix.

Development Environment Failure Modes

Defects in the engineering software (the ES itself) are reported with the same frequency as the runtime defects and include:

Failure Manifestation Mitigation
ES crash on save WinCC flexible closes without error or with a generic Windows error Enable auto-recovery, save to a fresh directory, install HF2
Error dialog with empty text Generic "Error" dialog with no message body, no error code Capture screen, check %APPDATA%\Siemens\WinCC flexible 2007\Logs
Project corruption on download Project file fails to open or produces ghost objects on next open Restore from the most recent .hmi archive, run Project > Clean Up
Slow project open with large libraries Open time exceeds 5 minutes for projects > 4 MB Disable unused libraries, increase RAM to 4 GB minimum
Compile produces warnings not present in 2005 New warning class for unused tags and orphaned connections Review tag list, mark deprecated tags for removal

The empty-text error dialog is particularly difficult to diagnose because it carries no machine-readable text. Field practice is to photograph the dialog, note the project name, panel target, and last action, and attach all four to the Siemens support request via the Siemens Industry Online Support portal.

Hotfix HF2 Deployment Procedure

Hotfix HF2 is the cumulative update released by Siemens to address the most critical items above. Treat the hotfix as mandatory on any project shipping on WinCC flexible 2007 prior to its release. The procedure below assumes the standard Windows installer flow used by Siemens at the time of HF2.

Prerequisites

  • Valid WinCC flexible 2007 license. No new license key is required for the hotfix itself.
  • Administrative rights on the engineering station.
  • Backup of all open projects and the %APPDATA%\Siemens\WinCC flexible 2007\ directory tree.
  • 500 MB free disk space for the installer staging area.
  • Verified access to the Siemens update server or the offline HF2 media supplied by the local Siemens representative.

Installation Steps

  1. Close all instances of WinCC flexible 2007, including any panels in transfer mode.
  2. Stop the WinCC flexible runtime services and the configuration agent from the Windows Services console (exact service names vary by installation; identify them by their executable path under Programs\Siemens).
  3. Run the HF2 installer with elevated privileges. Accept the EULA and select Repair if the installation is already present, Install if WinCC flexible 2007 has never been patched.
  4. Restart the engineering station. Do not skip this step; the COM registration is updated only on a full reboot.
  5. Launch WinCC flexible 2007 and verify the version string in Help > About shows the HF2 build identifier.
  6. Open each production project, run Project > Clean Up, recompile, and download to the target panel.

Rollback Procedure

If HF2 introduces a regression not present in the unpatched build, the rollback is a clean uninstall of WinCC flexible 2007 followed by a base install from the original media, then restoration of the %APPDATA%\Siemens\WinCC flexible 2007\ directory from the pre-HF2 backup. Plan a 90-minute window for the rollback; the COM re-registration is the long pole. Do not attempt to uninstall HF2 in place; a partial uninstall leaves the ES in an unrecoverable state and requires a full OS re-image.

Workarounds Prior to HF2 Installation

For installations where HF2 cannot be applied immediately (validation window pending, customer approval pending, or restricted change-control window), the following workarounds have proven effective in field deployments:

  • Force a full power cycle (not warm restart) on the panel after each download. This clears the runtime font and binding caches that drive Symptoms 1, 2, and 3.
  • Recreate affected objects rather than editing in place. I/O fields and buttons created with the same properties in a new instance have a higher probability of binding correctly.
  • Isolate dynamic properties to dedicated faceplates. Centralizing the appearance logic in a faceplate object reduces the surface area for the binding cache to drift.
  • Disable auto-apply of project font changes in Options > Settings > Visualization. Manually re-selecting the font forces a regeneration of the embedded font set.
  • Maintain a "known good" project baseline. After any successful download, archive the project directory and the panel's runtime image. A known-good pair reduces recovery time when a download produces a corrupted runtime.
  • Run a post-download verification pass that includes every screen, not just the edited screens. The Symptom 4 failure mode means the regression surface is the entire project.

PLC-Side Considerations

Although the defect is on the HMI side, the engineering response should include a verification pass on the PLC side, because the panel's intermittent display of stale values (Symptom 3) can mask PLC-side issues that the operator is then unable to see.

  • Tag accessibility: Confirm that every tag referenced by the panel is reachable via the configured connection (PROFINET, MPI, PROFIBUS) and that the access point on the PLC side is not being rate-limited by an unrelated communication load.
  • Update rate: For tags that drive operator-facing I/O fields, configure the acquisition cycle on the PLC side to a value consistent with the panel's update rate. A mismatch can cause the panel to request faster than the PLC delivers, which is a contributing factor to Symptom 3.
  • Symbol table hygiene: Rename or remove tags in the PLC symbol table only after a full project recompile on the ES side. The 2007 ES does not always detect a deleted tag in the symbol table, and the resulting bind to a non-existent tag can produce the same intermittent display as Symptom 3.
  • S7-300/S7-400 vs S7-1200: S7-300 and S7-400 connections typically use MPI/PROFIBUS; S7-1200 is PROFINET-only. Verify the connection type configured in the ES matches the actual PLC hardware; a mismatch produces a silent bind failure that mimics the display defect.

Network and Transfer Considerations

The transfer path between the ES and the panel is a frequent source of intermittent faults that are misdiagnosed as WinCC flexible 2007 defects. Before assuming the panel is the failure point, verify the following:

  • Transfer cable integrity: For MPI/PROFIBUS transfers, replace the cable and confirm termination. For PROFINET, confirm the switch port is not exhibiting errors (CRC, Fragments, Late Collisions counters on the managed switch).
  • IP addressing: If the panel and the ES are on different subnets, confirm the routing and that no firewall is blocking the WinCC flexible transfer port. S7 communication uses TCP 102; the dynamic port range used for project transfer must also be open on intermediate firewalls.
  • Concurrent transfers: Disable any background transfer jobs (recipe uploads, alarm log dumps) before initiating a project download. Concurrent transfers can corrupt the project file in transit and produce the same symptom as a corrupted project on disk.

Upgrade Decision Flow

Project on WinCC flex 2005? Stay on 2005 In-service, stable Move to 2007 + HF2 New project only Driver: new panel type e.g., MP 377 Driver: customer version Mandates current ES Full project verification

The decision flow above summarizes the recommended path for a project currently running on WinCC flexible 2005 with a panel type also supported by 2007. Projects that require a panel type not supported by 2005 must take the 2007 + HF2 branch; the rest should follow the 2005 branch unless a customer-driven version policy overrides the recommendation.

Migration Decision: 2005 vs 2007

For projects already in service on WinCC flexible 2005, the migration to 2007 should be evaluated against the following matrix. The decision is rarely driven by new functionality; it is driven by hardware support, panel availability, and customer-mandated version policy.

Factor Stay on 2005 Move to 2007 + HF2
Active development Yes, if 2005 supports all required panels Yes, if new panel type (e.g., MP 377) is required
Customer version policy Mandates 2005 Mandates current version
Engineer familiarity High on 2005 Mixed; requires HF2 verification step
Risk tolerance Low (2005 is stable) Medium (2007 + HF2 is acceptable for new projects only)
Legacy panel support Yes, including OP 77, TP 177 Yes, but verify with HF2
Audit / validation cost None (no change) Moderate (full re-verification due to Symptom 4)

The conservative recommendation is to stay on 2005 for in-service projects and adopt 2007 + HF2 only for new projects that require panel types unsupported in 2005 or for projects that must demonstrate use of the current Siemens release. This conservative position aligns with the field practice observed during the HF2 rollout window.

Verification Procedure After Patch

A formal verification must be executed after HF2 installation, after any project edit, and after any panel image restore. The verification is more thorough than the typical 2005-era spot check because of Symptom 4.

Pre-Transfer Checks

  • [ ] ES version string in Help > About shows HF2 build
  • [ ] Project compiles with zero errors and zero new warnings versus the 2005 baseline
  • [ ] All referenced fonts are embedded in the project (no runtime font substitution)
  • [ ] All tag connections are valid against the target PLC's symbol table

Post-Transfer Checks (on the panel)

  • [ ] Full power cycle performed before verification
  • [ ] Every screen opened at least once
  • [ ] Every tag-bound object (button, I/O field, bar, gauge) updated at least once
  • [ ] No BOLD or font-size drift on static text labels
  • [ ] No uncommanded color change on buttons
  • [ ] All configured alarms trigger and acknowledge
  • [ ] All faceplates instantiate cleanly

A panel that passes this verification in one shift may still exhibit a defect in the next shift. Schedule a follow-up verification at 24 hours and at 7 days for any panel deployed in a regulated process. Keep the verification log attached to the project archive; this log is the basis for the GAMP-style validation evidence required in pharmaceutical and food-and-beverage deployments.

Risk and Severity Matrix

Defect Probability (per 1000 panel-hours) Severity Detectability Risk Priority
Button color does not update Medium Low (cosmetic) High (visible) Low
Text label BOLD drift Medium Low (cosmetic) High (visible) Low
I/O field default value Medium High (operator reads wrong value) Medium High
Recompile influences unmodified objects High High (process-affecting) Low (no automated check) High
ES crash on save High Medium (engineering time) High (visible) Medium
Project corruption on download Low High (data loss) High (visible) Medium

The two High-risk items (I/O field default and recompile drift) are the strongest arguments for the conservative migration policy. The I/O field defect in particular can produce a silent process error if the operator trusts the displayed value without verification.

Engineering Practice Recommendations

Beyond the immediate defect response, the following practices reduce exposure to a repeat of this class of failure on any WinCC flexible release:

  • Pin the ES version in version control. Do not allow engineering stations to auto-update; require a controlled promotion from a staging ES to a production ES.
  • Maintain a panel image per project version. When a download occurs, archive the panel's runtime image alongside the project file. A corrupted runtime can be replaced from the archive in minutes rather than hours.
  • Run the verification checklist above as a CI gate. For projects under continuous engineering change, the post-transfer verification can be partially automated using the panel's built-in test interface or a scripted OPC-DA simulator driving the tag set.
  • Subscribe to Siemens product notifications. Hotfix HF2 was the second hotfix in the release; the first was acknowledged to integrators via direct email rather than public release notes, and projects that relied on the public notification feed missed it.
  • Document panel reset procedures in the operator manual. A panel that exhibits display drift may be reset by a controlled power cycle; documenting this reduces the chance that an operator will perform an uncontrolled reset that loses event logs.

Glossary

ES
Engineering System; the development environment (WinCC flexible 2007 ES in this context).
RT
Runtime; the software image executing on the HMI panel.
HF2
Hotfix 2; the cumulative update for WinCC flexible 2007.
Faceplate
A reusable visualization object instantiated multiple times with different tag connections.
SP
Service Pack; a planned release of new features and fixes, distinct from a hotfix.
PROFINET
Ethernet-based industrial protocol used by S7-1200 and most modern S7-300/400 panels.

Should I migrate a stable WinCC flexible 2005 project to 2007?

No, not without a driver. 2005 remains the more reliable baseline for in-service projects. Move to 2007 only if a new panel type is required, or if the customer's version policy mandates the current release, in which case apply HF2 and run the full verification checklist before commissioning.

What is Hotfix HF2 for WinCC flexible 2007?

HF2 is the second cumulative hotfix released by Siemens for WinCC flexible 2007, targeting display refresh, dynamic property binding, and project corruption defects. It is installed over the base 2007 release and does not require a new license key, and the HF2 build identifier appears in Help > About once installed.

How do I know if my installation has HF2?

Open WinCC flexible 2007 and navigate to Help > About. The build identifier in the About dialog must show the HF2 suffix. If the suffix is absent, the hotfix was not applied or was rolled back; re-run the installer in Repair mode and reboot the engineering station before continuing.

My MP 277 button does not change color when the linked bit toggles. What is the first action?

Perform a full power cycle on the panel (not a warm restart). If the defect persists, open the affected screen in the ES, delete the button, recreate it with identical properties, recompile, and download. If the defect still persists, the project requires HF2 or the dynamic property should be moved to a faceplate to bypass the binding-cache defect.

After applying HF2, do I need to reverify the entire project or only the changed screens?

The full project. Symptom 4 (recompile influences unmodified objects) requires that every screen and every dynamic object be reverified after any recompile, not only the screens that were edited. Allocate verification time proportional to the full project size, and schedule a 24-hour and a 7-day follow-up verification on regulated-process panels.

Back to blog