WinCC V7.5 SP1 Graphics Color Not Refreshing After Migration

Problem Overview

After migrating a WinCC V7.0 SP3 project through the chain V7.0 SP3 → V7.2 → V7.4 → V7.5 SP1, runtime graphics intermittently fail to update their fill, line, or background colors when the source tag value changes. The phenomenon is inconsistent:

• Some picture windows reflect tag-driven color changes immediately.
• Other picture windows stay frozen on the originally rendered color until the operator clicks through several buttons or the picture is opened/closed multiple times.
• The same internal tag, when bound on a different picture, refreshes correctly.
• The Windows 10 Pro host itself is otherwise stable; only the WinCC runtime picture cache appears affected.

The behavior is documented across Siemens' WinCC V7.5 SP1 update notes and is generally tied to graphic runtime libraries, the DCF (Data Coupling File), and OS-version-specific GDI+ rendering paths introduced when migrating off Windows 7 / Windows Server 2008 R2 era hosts.

Affected Versions and Platforms

Root Cause Analysis

The color-not-refreshing symptom is not a single bug but a convergence of three runtime layers. Treat the diagnosis as a layered check rather than a single swap.

1. Picture Cache and Re-draw Scheduler (CSIG runtime)

WinCC stores each compiled picture as a *.PDL plus a cached representation used by CCAlgRt.exe and CCEsgRt.exe. Under V7.5 SP1 baseline, the picture cache was rebuilt against a different GDI+ rendering path than V7.0 SP3 used. When a tag triggers an event, the scheduler re-evaluates the configured dynamic dialog (color expression) on a per-object basis. If the object's redraw flag is dropped during migration, the color is recomputed only on full picture open.

2. DCF File Corruption or Version Mismatch

The DCF file (default location <Project>\<Project>.dcf) is the central registry of tag connections, structure tags, and picture-to-tag bindings. During multi-hop migration (V7.0 SP3 → V7.2 → V7.4 → V7.5 SP1), partial conversions of structure tags can leave orphaned bindings. The runtime reports no error; it simply stops firing color-change events for the orphaned bindings.

3. Operating System GDI+ Stack

Windows 10 Pro (build 1809 and later) shipped an updated GDI+ rendering pipeline. WinCC V7.5 SP1 Update 1 added explicit compatibility shims; Update 2 extended them to color attribute paths. Without these shims, certain Direct2D-accelerated layers swallow the redraw event for grouped objects.

Solution Path — Primary Fix

The confirmed field fix is to install WinCC V7.5 SP1 Update 2 (or a later cumulative update) on both the engineering station (ES) and every runtime station (RT) that loads the migrated project.

Prerequisites

• Local administrator rights on the WinCC station.
• WinCC V7.5 SP1 already installed and licensed.
• All WinCC processes stopped: WinCCExplorer.exe, CCEsgRt.exe, CCAlgRt.exe, CCArchiveMgr.exe, CCMsgMgr.exe.
• Project backup of <Project>\<Project>.mcp and the full GraCS\ directory.

Step-by-Step — Apply Update 2

1. Download the update package from the official Siemens support portal entry "Updates for WinCC V7.5 SP1 and WinCC V7.5 SP1 ASIA".
2. Stop the WinCC service:

   net stop "S7WINCCBXRTMS" >nul 2>&1
   net stop "CCMsgMgr" >nul 2>&1
   net stop "CCEsgRt" >nul 2>&1
   net stop "CCAlgRt" >nul 2>&1
   

3. Extract the update (do not run from a network share if the installer flags UAC).
4. Launch Setup.exe from the extracted folder. Accept the license and let the installer detect the existing V7.5 SP1 installation.
5. When prompted, choose Update installation. Do not select "Repair" unless the existing installation is broken; a repair will re-register all DLLs and lengthen downtime without fixing the color cache issue.
6. Restart the OS if the installer requests it. On Windows 10 Pro a restart is mandatory for the GDI+ shim DLLs.
7. Reboot, then re-open the migrated project in WinCC Explorer and start runtime.

Solution Path — Secondary Fix: DCF File Reset

If the symptom persists after Update 2 (or when running offline without internet access to fetch the update), reset the DCF file. This rebuilds every tag-to-picture binding from the current project database.

1. Close WinCC Explorer and stop all WinCC runtime processes.
2. Navigate to the project folder (default C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<Project>\).
3. Locate <Project>.dcf. Rename it to <Project>.dcf.bak for rollback safety.
4. Open WinCC Explorer. The system will detect the missing DCF and prompt to regenerate it. Confirm.
5. For every channel (SIMATIC S7, OPC, Modbus, etc.), verify the logical connection name and driver version are intact in the Tag Management editor.
6. Re-compile all OS pictures: right-click Graphics Designer → Compile OS → All pictures. Watch the output log for unresolved tag references.
7. Start runtime and validate color changes on at least three pictures that were previously frozen.

Solution Path — Tertiary: Per-Picture Compensation

When neither Update 2 nor a DCF reset fully restores behavior on every picture, the issue is typically scoped to the picture file itself. Two compensating techniques are valid in V7.5 SP1:

Technique A — Force a Dynamic Refresh via Attribute

On the affected object, open Properties → Colors → Background Color → Dynamic. Switch the trigger from "On change" to "On change with refresh" (or add a secondary trigger bound to a 1-second internal timer tag). This adds an explicit redraw request even when the picture cache has dropped the original event.

Technique B — Re-link the Color Expression

1. Open the picture in Graphics Designer.
2. Right-click the affected object → Configuration → Dynamic Wizard or the direct Color property dialog.
3. Note the current expression. Delete the dynamic and re-create it with the identical expression. This forces the designer to regenerate the binding inside the cached *.PDL.
4. Save, re-compile the picture, and re-test in runtime.

Prevention Checklist Before Migration

Verification Procedure

After applying any of the solutions above, validate that color refresh is restored before returning the station to production:

1. Open WinCC Explorer and start runtime on the migrated project.
2. Open a picture that previously exhibited the freeze.
3. From the WinCC tag simulator or the connected PLC, toggle a tag that drives a fill color on the picture between two distinct values (for example 0 → 100).
4. Confirm the color updates within one picture refresh cycle (≤ 1 second on a healthy RT). No operator click should be required.
5. Repeat the test on at least three other pictures that use different trigger sources: direct tag, structure tag element, and computed expression.
6. Cycle the entire runtime: stop WinCC, wait 10 seconds, restart. Re-run steps 2–4 to confirm the fix survives a cold start.
7. Inspect the WinCC diagnostic file <Project>\Diagnostics\<Project>_<ComputerName>_<timestamp>.log for any ColorCache, PDL, or DCF warnings.

Fault Code Mapping

While the symptom itself does not raise a discrete alarm, the diagnostic log entries that point to this class of issue are:

Troubleshooting Matrix

Operational Notes

• Always apply WinCC patches on engineering and runtime stations from the same installer image. Mismatched update levels between ES and RT can re-introduce DCF drift.
• If the project was migrated across three major versions, schedule a one-time full project recompile (OS Project Editor → Compile OS) after the update is in place. The recompile flushes legacy cached bindings from GraCS\.
• On Windows 10 Pro, disable third-party GDI accelerators (e.g., display driver overlays) during runtime troubleshooting. They mask the symptom and can prevent the fix from appearing to work.
• For multi-user projects, ensure the SIMATIC HMI user group is granted write access to the project root, otherwise DCF regeneration silently fails with the message logged as a generic warning.

FAQ